mirror of https://github.com/easzlab/kubeasz.git
update docs for 3.0.0
parent
7dd8fd9fbb
commit
789c3f7597
|
@ -1,16 +0,0 @@
|
|||
# 修改AIO 部署的IP
|
||||
前两天在项目[ISSUES #201](https://github.com/easzlab/kubeasz/issues/201)看到有人提:`在虚拟机A装了allinone,并搭建一套开发环境,我想通过copy A出来一套B然后交给别人测试`,觉得这个场景蛮有用,就写了这个文档和对应的脚本,希望对各位有帮助,也可以熟悉kubeasz的安装逻辑。
|
||||
|
||||
首先,因为kubeasz创建的集群都是TLS双向认证的,所以修改host ip地址比想象中要复杂很多。具体步骤可以参考[脚本](../../tools/change_ip_aio.yml)中的注释内容。
|
||||
|
||||
- 本操作指南仅适用于测试交流
|
||||
|
||||
## 操作步骤
|
||||
前提 :一个运行正常的allinone部署在虚机,关机后复制给别人使用,新虚机开机后如果需要修改IP,请执行如下步骤:
|
||||
|
||||
- 1.修改ansible hosts文件:`sed -i 's/$OLD_IP/$NEW_IP/g' /etc/ansible/hosts`
|
||||
- 2.配置ssh免密码登录:`ssh-copy-id $NEW_IP` 按提示完成
|
||||
- 3.检查下修改是否成功,并且能够成功执行 `ansible all -m ping`
|
||||
- 4.以上步骤完成后,执行 `ansible-playbook /etc/ansible/tools/change_ip_aio.yml`
|
||||
|
||||
执行成功即可,请自己验证原先集群中各应用是否正常。
|
|
@ -1,31 +0,0 @@
|
|||
# 替换k8s集群的网络插件
|
||||
|
||||
有时候我们在测试环境的k8s集群中希望试用多种网络插件(calico/flannel/kube-router),又不希望每测试一次就全部清除集群然后重建,那么可能这个文档适合你。
|
||||
- WARNNING:重新安装k8s网络插件会短暂中断已有运行在k8s上的服务
|
||||
- 请在熟悉kubeasz的安装流程和k8s网络插件安装流程的基础上谨慎操作
|
||||
- 如果k8s集群已经运行庞大业务pod,重装网络插件时会引起所有pod的删除、重建,短时间内将给apiserver带来压力,可能引起master节点夯住
|
||||
- 确保没有裸pod 运行(因为最后需要删除所有pod 重建,裸pod 不会重建),即所有pod 都是由 deploy/daemonset/statefulset 等创建;
|
||||
|
||||
## 替换流程
|
||||
|
||||
kubeasz使用标准cni方式安装k8s集群的网络插件;cni负载创建容器网卡和IP分配(IPAM),不同的网络插件(calico,flannel等)创建容器网卡和IP分配方式不一样,所以在替换网络插件时候需要现有pod全部删除,然后自动按照新网络插件的方式重建pod网络;请参考[k8s网络插件章节](../setup/06-install_network_plugin.md)。
|
||||
|
||||
### 替换操作
|
||||
|
||||
替换网络插件操作很简单,只要两步:
|
||||
- 1.修改ansible hosts文件指定新网络插件
|
||||
- 2.执行替换脚本 `ansible-playbook /etc/ansible/tools/change_k8s_network.yml`
|
||||
|
||||
对照脚本`change_k8s_network.yml` 讲解下大致流程为:
|
||||
a.根据实际运行情况,删除现有网络组件的daemonset pod
|
||||
b.如果现有组件是kube-router 需要进行一些额外清理
|
||||
c.暂停node相关服务,后面才可以进一步清理iptables等
|
||||
d.执行旧网络插件相关清理
|
||||
e.重新开启node相关服务
|
||||
f.安装新网络插件
|
||||
g.删除所有运行pod,然后等待自动重建
|
||||
|
||||
## 验证新网络插件
|
||||
|
||||
参照[calico](../setup/network-plugin/calico.md) [cilium](../setup/network-plugin/cilium.md) [flannel](../setup/network-plugin/flannel.md) [kube-router](../setup/network-plugin/kube-router.md)
|
||||
|
|
@ -0,0 +1,117 @@
|
|||
# 管理客户端kubeconfig
|
||||
|
||||
默认 k8s集群安装成功后生成客户端kubeconfig,它拥有集群管理的所有权限(不要将这个admin权限、50年期限的kubeconfig流露出去);而我们经常需要将限定权限、限定期限的kubeconfig 分发给普通用户;利用cfssl签发自定义用户证书和k8s灵活的rbac权限绑定机制,ezctl 工具封装了这个功能。
|
||||
|
||||
## 使用帮助
|
||||
|
||||
```
|
||||
ezctl help kcfg-adm
|
||||
Usage: ezctl kcfg-adm <cluster> <args>
|
||||
available <args>:
|
||||
-A to add a client kubeconfig with a newly created user
|
||||
-D to delete a client kubeconfig with the existed user
|
||||
-L to list all of the users
|
||||
-e to set expiry of the user certs in hours (ex. 24h, 8h, 240h)
|
||||
-t to set a user-type (admin or view)
|
||||
-u to set a user-name prefix
|
||||
|
||||
examples: ./ezctl kcfg-adm test-k8s -L
|
||||
./ezctl kcfg-adm default -A -e 240h -t admin -u jack
|
||||
./ezctl kcfg-adm default -D -u jim-202101162141
|
||||
```
|
||||
|
||||
## 使用举例
|
||||
|
||||
- 1.查看集群k8s-01当前自定义kubeconfig
|
||||
|
||||
```
|
||||
ezctl kcfg-adm k8s-01 -L
|
||||
2021-01-24 16:32:43 INFO list-kcfg k8s-01
|
||||
2021-01-24 16:32:43 INFO list-kcfg in cluster:k8s-01
|
||||
|
||||
USER TYPE EXPIRY(+8h if in Asia/Shanghai)
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
2021-01-24 16:32:43 INFO list-kcfg k8s-01 success
|
||||
```
|
||||
初始情况下列表为空
|
||||
|
||||
- 2.增加集群k8s-01一个自定义用户kubeconfig,用户名user01,期限24h,只读权限
|
||||
|
||||
```
|
||||
ezctl kcfg-adm k8s-01 -A -u user01 -e 24h -t view
|
||||
2021-01-24 17:32:33 INFO add-kcfg k8s-01
|
||||
2021-01-24 17:32:33 INFO add-kcfg in cluster:k8s-01 with user:user01-202101241732
|
||||
|
||||
PLAY [localhost] *****************************************************************************************************
|
||||
|
||||
...(此处省略输出)
|
||||
|
||||
TASK [deploy : debug] ************************************************************************************************
|
||||
ok: [localhost] => {
|
||||
"msg": "查看user01-202101241732自定义kubeconfig:/etc/kubeasz/clusters/k8s-01/ssl/users/user01-202101241732.kubeconfig"
|
||||
}
|
||||
|
||||
PLAY RECAP ***********************************************************************************************************
|
||||
localhost : ok=12 changed=10 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
|
||||
|
||||
2021-01-24 17:32:41 INFO add-kcfg k8s-01 success
|
||||
```
|
||||
生成的kubeconfig位于 /etc/kubeasz/clusters/k8s-01/ssl/users/user01-202101241732.kubeconfig
|
||||
|
||||
- 3.再增加一个用户user02,期限240h,admin权限
|
||||
|
||||
```
|
||||
ezctl kcfg-adm k8s-01 -A -u user02 -e 240h -t admin
|
||||
2021-01-24 18:38:47 INFO add-kcfg k8s-01
|
||||
2021-01-24 18:38:47 INFO add-kcfg in cluster:k8s-01 with user:user02-202101241838
|
||||
|
||||
PLAY [localhost] *****************************************************************************************************
|
||||
|
||||
...(此处省略输出)
|
||||
|
||||
TASK [deploy : debug] ************************************************************************************************
|
||||
ok: [localhost] => {
|
||||
"msg": "查看user02-202101241838自定义kubeconfig:/etc/kubeasz/clusters/k8s-01/ssl/users/user02-202101241838.kubeconfig"
|
||||
}
|
||||
|
||||
PLAY RECAP ***********************************************************************************************************
|
||||
localhost : ok=12 changed=9 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
|
||||
|
||||
2021-01-24 18:38:55 INFO add-kcfg k8s-01 success
|
||||
```
|
||||
|
||||
- 4.再次查看集群k8s-01当前自定义kubeconfig
|
||||
|
||||
```
|
||||
ezctl kcfg-adm k8s-01 -L
|
||||
2021-01-24 18:40:30 INFO list-kcfg k8s-01
|
||||
2021-01-24 18:40:30 INFO list-kcfg in cluster:k8s-01
|
||||
|
||||
USER TYPE EXPIRY(+8h if in Asia/Shanghai)
|
||||
---------------------------------------------------------------------------------
|
||||
user02-202101241838 cluster-admin 2021-02-03T10:34:00Z
|
||||
user01-202101241732 view 2021-01-25T09:28:00Z
|
||||
|
||||
2021-01-24 18:40:31 INFO list-kcfg k8s-01 success
|
||||
```
|
||||
|
||||
- 5.删除user01-202101241732 权限
|
||||
|
||||
``` bash
|
||||
ezctl kcfg-adm k8s-01 -D -u user01-202101241732
|
||||
2021-01-24 21:41:50 INFO del-kcfg k8s-01
|
||||
2021-01-24 21:41:50 INFO del-kcfg in cluster:k8s-01 with user:user01-202101241732
|
||||
clusterrolebinding.rbac.authorization.k8s.io "crb-user01-202101241732" deleted
|
||||
2021-01-24 21:41:50 INFO del-kcfg k8s-01 success
|
||||
|
||||
ezctl kcfg-adm k8s-01 -L
|
||||
2021-01-24 21:42:02 INFO list-kcfg k8s-01
|
||||
2021-01-24 21:42:02 INFO list-kcfg in cluster:k8s-01
|
||||
|
||||
USER TYPE EXPIRY(+8h if in Asia/Shanghai)
|
||||
---------------------------------------------------------------------------------
|
||||
user02-202101241838 cluster-admin 2021-02-03T10:34:00Z
|
||||
|
||||
2021-01-24 21:42:02 INFO list-kcfg k8s-01 success
|
||||
```
|
|
@ -4,9 +4,7 @@
|
|||
- [管理 MASTER 节点](op-master.md)
|
||||
- [管理 ETCD 节点](op-etcd.md)
|
||||
- [升级 K8S 版本](upgrade.md)
|
||||
- [修改AIO部署的系统IP](change_ip_allinone.md)
|
||||
- [替换集群使用的网络插件](change_k8s_network.md)
|
||||
- [集群备份与恢复](cluster_restore.md)
|
||||
- [设置只读权限 kubeconfig](readonly_kubectl.md)
|
||||
- [管理分发用户 kubeconfig](kcfg-adm.md)
|
||||
- [修改 APISERVER 证书](ch_apiserver_cert.md)
|
||||
- [配置负载转发 ingress nodeport](loadballance_ingress_nodeport.md)
|
||||
|
|
|
@ -1,69 +0,0 @@
|
|||
# 配置 kubectl 只读访问权限
|
||||
|
||||
默认 k8s 集群安装后配置的 kubectl 客户端拥有所有的管理权限,而有时候我们需要把只读权限分发给普通开发人员,本文档将创建一个只读权限的kubectl 配置文档 kubeconfig。
|
||||
|
||||
## 创建
|
||||
|
||||
- 备份下原先 admin 权限的 kubeconfig 文件:`mv ~/.kube ~/.kubeadmin`
|
||||
- 执行 `ansible-playbook /etc/ansible/01.prepare.yml -t create_kctl_cfg -e USER_NAME=read`,成功后查看~/.kube/config 即为只读权限
|
||||
|
||||
## 讲解
|
||||
|
||||
创建主要包括三个步骤:
|
||||
|
||||
- 创建 group:read rbac 权限
|
||||
- 创建 read 用户证书和私钥
|
||||
- 创建 kubeconfig
|
||||
|
||||
### read rbac 权限
|
||||
|
||||
所有权限控制魔法在`k8s`中由`rbac`实现,所谓`read`权限类似于集群自带的`clusterrole view`,具体查看:
|
||||
|
||||
`kubectl get clusterrole view -o yaml`
|
||||
|
||||
`read`权限配置`roles/deploy/files/read-group-rbac.yaml`是在`clusterrole view`基础上增加了若干读权限(Nodes/Persistent Volume Claims)
|
||||
|
||||
### read 用户证书
|
||||
|
||||
准备 read 证书请求:`read-csr.json`
|
||||
|
||||
``` bash
|
||||
{
|
||||
"CN": "read",
|
||||
"hosts": [],
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names": [
|
||||
{
|
||||
"C": "CN",
|
||||
"ST": "HangZhou",
|
||||
"L": "XS",
|
||||
"O": "group:read",
|
||||
"OU": "System"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
- 注意: O `group:read`,kube-apiserver 收到该证书后将请求的 Group 设置为`group:read`;之前步骤创建的 ClusterRoleBinding `read-clusterrole-binding`将 Group `group:read`与 ClusterRole `read-clusterrole`绑定,从而实现只读权限。
|
||||
|
||||
### read kubeconfig
|
||||
|
||||
kubeconfig 为与apiserver交互使用的认证配置文件,如脚本步骤需要:
|
||||
|
||||
- 设置集群参数,指定CA证书和apiserver地址
|
||||
- 设置客户端认证参数,指定使用read证书和私钥
|
||||
- 设置上下文参数,指定使用cluster集群和用户read
|
||||
- 设置指定默认上下文
|
||||
|
||||
创建完成后生成默认配置文件为 `~/.kube/config`
|
||||
|
||||
## 恢复 admin 权限
|
||||
|
||||
- 可以恢复之前备份的`~/.kubeadmin`文件:`mv ~/.kube ~/.kuberead && mv ~/.kubeadmin ~/.kube`
|
||||
|
||||
## 参考
|
||||
|
||||
- [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
|
||||
- [A Read Only Kubernetes Dashboard](https://blog.cowger.us/2018/07/03/a-read-only-kubernetes-dashboard.html)
|
|
@ -18,6 +18,12 @@
|
|||
|master节点|2|高可用集群至少2个master节点|
|
||||
|node节点|3|运行应用负载的节点,可根据需要提升机器配置/增加节点数|
|
||||
|
||||
机器配置:
|
||||
- master节点:4c/8g内存/50g硬盘
|
||||
- worker节点:建议8c/32g内存/200g硬盘以上
|
||||
|
||||
注意:默认配置下容器/kubelet会占用/var的磁盘空间,如果磁盘分区特殊,可以设置config.yml中的容器/kubelet数据目录:`CONTAINERD_STORAGE_DIR` `DOCKER_STORAGE_DIR` `KUBELET_ROOT_DIR`
|
||||
|
||||
在 kubeasz 2x 版本,多节点高可用集群安装可以使用2种方式
|
||||
|
||||
- 1.先部署单节点集群 [AllinOne部署](quickStart.md),然后通过 [节点添加](../op/op-index.md) 扩容成高可用集群
|
||||
|
@ -29,7 +35,7 @@
|
|||
|
||||
### 1.基础系统配置
|
||||
|
||||
+ 推荐内存2G/硬盘30G以上
|
||||
+ 2c/4g内存/40g硬盘(该配置仅测试用)
|
||||
+ 最小化安装`Ubuntu 16.04 server`或者`CentOS 7 Minimal`
|
||||
+ 配置基础网络、更新源、SSH登录等
|
||||
|
||||
|
|
|
@ -83,12 +83,6 @@ WantedBy=multi-user.target
|
|||
+ `--initial-cluster-state` 值为 `new` 时,`--name` 的参数值必须位于 `--initial-cluster` 列表中
|
||||
+ `--snapshot-count` `--auto-compaction-retention` 一些性能优化参数,请查阅etcd项目
|
||||
|
||||
### 启动etcd服务
|
||||
|
||||
``` bash
|
||||
systemctl daemon-reload && systemctl enable etcd && systemctl start etcd
|
||||
```
|
||||
|
||||
### 验证etcd集群状态
|
||||
|
||||
+ systemctl status etcd 查看服务状态
|
||||
|
|
|
@ -54,30 +54,24 @@ roles/docker/templates/daemon.json.j2
|
|||
"log-driver": "json-file",
|
||||
"log-level": "warn",
|
||||
"log-opts": {
|
||||
"max-size": "15m",
|
||||
"max-file": "3"
|
||||
"max-size": "50m",
|
||||
"max-file": "1"
|
||||
},
|
||||
"storage-driver": "overlay2"
|
||||
}
|
||||
```
|
||||
- data-root 配置容器数据目录,默认/var/lib/docker,在集群安装时要规划磁盘空间使用
|
||||
- registry-mirrors 配置国内镜像仓库加速
|
||||
- live-restore 可以重启docker daemon ,而不重启容器
|
||||
- log-opts 容器日志相关参数,设置单个容器日志超过50M则进行回卷,回卷的副本数超过1个就进行清理
|
||||
|
||||
|
||||
从国内下载docker官方仓库镜像非常缓慢,所以对于k8s集群来说配置镜像加速非常重要,配置 `/etc/docker/daemon.json`
|
||||
|
||||
这将在后续部署calico下载 calico/node镜像和kubedns/heapster/dashboard镜像时起到加速效果。
|
||||
|
||||
由于K8S的官方镜像存放在`gcr.io`仓库,因此这个镜像加速对K8S的官方镜像没有效果;好在`Docker Hub`上有很多K8S镜像的转存,而`Docker Hub`上的镜像可以加速。这里推荐两个K8S镜像的`Docker Hub`项目,几乎能找到所有K8S相关的镜像,而且更新及时,感谢维护者的辛勤付出!
|
||||
|
||||
+ [mirrorgooglecontainers](https://hub.docker.com/u/mirrorgooglecontainers/)
|
||||
+ [anjia0532](https://hub.docker.com/u/anjia0532/), [项目github地址](https://github.com/anjia0532/gcr.io_mirror)
|
||||
|
||||
当然对于企业内部应用的docker镜像,想要在K8S平台运行的话,特别是结合开发`CI/CD` 流程,肯定是需要部署私有镜像仓库的,参阅[harbor文档](../guide/harbor.md)。
|
||||
|
||||
另外,daemon.json配置中也配置了docker 容器日志相关参数,设置单个容器日志超过10M则进行回卷,回卷的副本数超过3个就进行清理。
|
||||
对于企业内部应用的docker镜像,想要在K8S平台运行的话,特别是结合开发`CI/CD` 流程,需要部署私有镜像仓库,参阅[harbor文档](../guide/harbor.md)。
|
||||
|
||||
### 清理 iptables
|
||||
|
||||
因为后续`calico`网络、`kube-proxy`等将大量使用 iptables规则,安装前清空所有`iptables`策略规则;常见发行版`Ubuntu`的 `ufw` 和 `CentOS`的 `firewalld`等基于`iptables`的防火墙最好直接卸载,避免不必要的冲突。
|
||||
因为`calico`网络、`kube-proxy`等将大量使用 iptables规则,安装前清空所有`iptables`策略规则;常见发行版`Ubuntu`的 `ufw` 和 `CentOS`的 `firewalld`等基于`iptables`的防火墙最好直接卸载,避免不必要的冲突。
|
||||
|
||||
WARNNING: 如果有自定义的iptables规则也会被一并清除,如果一定要使用自定义规则,可以集群安装完成后在应用规则
|
||||
|
||||
``` bash
|
||||
iptables -F && iptables -X \
|
||||
|
@ -87,15 +81,9 @@ iptables -F && iptables -X \
|
|||
```
|
||||
+ calico 网络支持 `network-policy`,使用的`calico-kube-controllers` 会使用到`iptables` 所有的四个表 `filter` `nat` `raw` `mangle`,所以一并清理
|
||||
|
||||
### 启动 docker
|
||||
|
||||
``` bash
|
||||
systemctl daemon-reload && systemctl enable docker && systemctl start docker
|
||||
```
|
||||
|
||||
### 可选-安装docker查询镜像 tag的小工具
|
||||
|
||||
docker官方目前没有提供在命令行直接查询某个镜像的tag信息的方式,网上找来一个脚本工具,使用很方便。
|
||||
docker官方没有提供在命令行直接查询某个镜像的tag信息的方式,可以使用一个工具脚本:
|
||||
|
||||
``` bash
|
||||
$ docker-tag library/ubuntu
|
||||
|
@ -106,40 +94,13 @@ $ docker-tag library/ubuntu
|
|||
"trusty"
|
||||
"trusty-20171117"
|
||||
"xenial"
|
||||
"xenial-20171114"
|
||||
"zesty"
|
||||
"zesty-20171114"
|
||||
$ docker-tag mirrorgooglecontainers/kubernetes-dashboard-amd64
|
||||
"v0.1.0"
|
||||
"v1.0.0"
|
||||
"v1.0.0-beta1"
|
||||
"v1.0.1"
|
||||
"v1.1.0-beta1"
|
||||
"v1.1.0-beta2"
|
||||
"v1.1.0-beta3"
|
||||
"v1.7.0"
|
||||
"v1.7.1"
|
||||
"v1.8.0"
|
||||
...
|
||||
```
|
||||
+ 需要先apt安装轻量JSON处理程序 `jq`
|
||||
+ 然后下载脚本即可使用
|
||||
+ 脚本很简单,就一行命令如下
|
||||
|
||||
``` bash
|
||||
#!/bin/bash
|
||||
curl -s -S "https://registry.hub.docker.com/v2/repositories/$@/tags/" | jq '."results"[]["name"]' |sort
|
||||
```
|
||||
+ 对于 CentOS7 安装 `jq` 稍微费力一点,需要启用 `EPEL` 源
|
||||
|
||||
``` bash
|
||||
wget http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
|
||||
rpm -ivh epel-release-latest-7.noarch.rpm
|
||||
yum install jq
|
||||
```
|
||||
|
||||
### 验证
|
||||
|
||||
运行`ansible-playbook 03.docker.yml` 成功后可以验证
|
||||
安装成功后验证如下:
|
||||
|
||||
``` bash
|
||||
systemctl status docker # 服务状态
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
## 04-安装kube_master节点
|
||||
# 04-安装kube_master节点
|
||||
|
||||
部署master节点主要包含三个组件`apiserver` `scheduler` `controller-manager`,其中:
|
||||
|
||||
|
@ -11,26 +11,13 @@
|
|||
- 根据调度策略为这些Pod分配节点
|
||||
- controller-manager由一系列的控制器组成,它通过apiserver监控整个集群的状态,并确保集群处于预期的工作状态
|
||||
|
||||
master节点的高可用主要就是实现apiserver组件的高可用,后面我们会看到每个 node 节点会启用 4 层负载均衡来请求 apiserver 服务。
|
||||
## 高可用机制
|
||||
|
||||
``` text
|
||||
roles/kube-master/
|
||||
├── defaults
|
||||
│ └── main.yml
|
||||
├── tasks
|
||||
│ └── main.yml
|
||||
└── templates
|
||||
├── aggregator-proxy-csr.json.j2
|
||||
├── basic-auth.csv.j2
|
||||
├── basic-auth-rbac.yaml.j2
|
||||
├── kube-apiserver.service.j2
|
||||
├── kube-apiserver-v1.8.service.j2
|
||||
├── kube-controller-manager.service.j2
|
||||
├── kubernetes-csr.json.j2
|
||||
└── kube-scheduler.service.j2
|
||||
```
|
||||
- apiserver 无状态服务,可以通过外部负责均衡实现高可用,如项目采用的两种高可用架构:HA-1x (#584)和 HA-2x (#585)
|
||||
- controller-manager 组件启动时会进行类似选举(leader);当多副本存在时,如果原先leader挂掉,那么会选举出新的leader,从而保证高可用;
|
||||
- scheduler 类似选举机制
|
||||
|
||||
请在另外窗口打开[roles/kube-master/tasks/main.yml](../../roles/kube-master/tasks/main.yml) 文件,对照看以下讲解内容。
|
||||
## 安装流程
|
||||
|
||||
### 创建 kubernetes 证书签名请求
|
||||
|
||||
|
@ -42,7 +29,9 @@ roles/kube-master/
|
|||
{% if groups['ex_lb']|length > 0 %}
|
||||
"{{ hostvars[groups['ex_lb'][0]]['EX_APISERVER_VIP'] }}",
|
||||
{% endif %}
|
||||
"{{ inventory_hostname }}",
|
||||
{% for host in groups['kube_master'] %}
|
||||
"{{ host }}",
|
||||
{% endfor %}
|
||||
"{{ CLUSTER_KUBERNETES_SVC_IP }}",
|
||||
{% for host in MASTER_CERT_HOSTS %}
|
||||
"{{ host }}",
|
||||
|
@ -68,17 +57,11 @@ roles/kube-master/
|
|||
]
|
||||
}
|
||||
```
|
||||
- kubernetes 证书既是服务器证书,同时apiserver又作为客户端证书去访问etcd 集群;作为服务器证书需要设置hosts 指定使用该证书的IP 或域名列表,需要注意的是:
|
||||
- kubernetes apiserver 使用对等证书,创建时hosts字段需要配置:
|
||||
- 如果配置 ex_lb,需要把 EX_APISERVER_VIP 也配置进去
|
||||
- 如果需要外部访问 apiserver,需要在 defaults/main.yml 配置 MASTER_CERT_HOSTS
|
||||
- 如果需要外部访问 apiserver,可选在config.yml配置 MASTER_CERT_HOSTS
|
||||
- `kubectl get svc` 将看到集群中由api-server 创建的默认服务 `kubernetes`,因此也要把 `kubernetes` 服务名和各个服务域名也添加进去
|
||||
|
||||
### 【可选】创建基础用户名/密码认证配置
|
||||
|
||||
若未创建任何基础认证配置,K8S集群部署完毕后访问dashboard将会提示`401`错误。
|
||||
|
||||
当前如需创建基础认证,需单独修改`roles/kube-master/defaults/main.yml`文件,将`BASIC_AUTH_ENABLE`改为`yes`,并相应配置用户名`BASIC_AUTH_USER`(默认用户名为`admin`)及密码`BASIC_AUTH_PASS`。
|
||||
|
||||
### 创建apiserver的服务配置文件
|
||||
|
||||
``` bash
|
||||
|
@ -89,33 +72,28 @@ After=network.target
|
|||
|
||||
[Service]
|
||||
ExecStart={{ bin_dir }}/kube-apiserver \
|
||||
--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook \
|
||||
--bind-address={{ inventory_hostname }} \
|
||||
--insecure-bind-address=127.0.0.1 \
|
||||
--authorization-mode=Node,RBAC \
|
||||
--kubelet-https=true \
|
||||
--kubelet-client-certificate={{ ca_dir }}/admin.pem \
|
||||
--kubelet-client-key={{ ca_dir }}/admin-key.pem \
|
||||
--advertise-address={{ inventory_hostname }} \
|
||||
--allow-privileged=true \
|
||||
--anonymous-auth=false \
|
||||
--token-auth-file={{ ca_dir }}/basic-auth.csv \
|
||||
--service-cluster-ip-range={{ SERVICE_CIDR }} \
|
||||
--service-node-port-range={{ NODE_PORT_RANGE }} \
|
||||
--tls-cert-file={{ ca_dir }}/kubernetes.pem \
|
||||
--tls-private-key-file={{ ca_dir }}/kubernetes-key.pem \
|
||||
--api-audiences=api,istio-ca \
|
||||
--authorization-mode=Node,RBAC \
|
||||
--bind-address={{ inventory_hostname }} \
|
||||
--client-ca-file={{ ca_dir }}/ca.pem \
|
||||
--service-account-key-file={{ ca_dir }}/ca-key.pem \
|
||||
--endpoint-reconciler-type=lease \
|
||||
--etcd-cafile={{ ca_dir }}/ca.pem \
|
||||
--etcd-certfile={{ ca_dir }}/kubernetes.pem \
|
||||
--etcd-keyfile={{ ca_dir }}/kubernetes-key.pem \
|
||||
--etcd-servers={{ ETCD_ENDPOINTS }} \
|
||||
--enable-swagger-ui=true \
|
||||
--endpoint-reconciler-type=lease \
|
||||
--allow-privileged=true \
|
||||
--audit-log-maxage=30 \
|
||||
--audit-log-maxbackup=3 \
|
||||
--audit-log-maxsize=100 \
|
||||
--audit-log-path=/var/lib/audit.log \
|
||||
--event-ttl=1h \
|
||||
--kubelet-certificate-authority={{ ca_dir }}/ca.pem \
|
||||
--kubelet-client-certificate={{ ca_dir }}/kubernetes.pem \
|
||||
--kubelet-client-key={{ ca_dir }}/kubernetes-key.pem \
|
||||
--service-account-issuer=kubernetes.default.svc \
|
||||
--service-account-signing-key-file={{ ca_dir }}/ca-key.pem \
|
||||
--service-account-key-file={{ ca_dir }}/ca.pem \
|
||||
--service-cluster-ip-range={{ SERVICE_CIDR }} \
|
||||
--service-node-port-range={{ NODE_PORT_RANGE }} \
|
||||
--tls-cert-file={{ ca_dir }}/kubernetes.pem \
|
||||
--tls-private-key-file={{ ca_dir }}/kubernetes-key.pem \
|
||||
--requestheader-client-ca-file={{ ca_dir }}/ca.pem \
|
||||
--requestheader-allowed-names= \
|
||||
--requestheader-extra-headers-prefix=X-Remote-Extra- \
|
||||
|
@ -124,9 +102,8 @@ ExecStart={{ bin_dir }}/kube-apiserver \
|
|||
--proxy-client-cert-file={{ ca_dir }}/aggregator-proxy.pem \
|
||||
--proxy-client-key-file={{ ca_dir }}/aggregator-proxy-key.pem \
|
||||
--enable-aggregator-routing=true \
|
||||
--runtime-config=batch/v2alpha1=true \
|
||||
--v=2
|
||||
Restart=on-failure
|
||||
Restart=always
|
||||
RestartSec=5
|
||||
Type=notify
|
||||
LimitNOFILE=65536
|
||||
|
@ -135,7 +112,6 @@ LimitNOFILE=65536
|
|||
WantedBy=multi-user.target
|
||||
```
|
||||
+ Kubernetes 对 API 访问需要依次经过认证、授权和准入控制(admission controll),认证解决用户是谁的问题,授权解决用户能做什么的问题,Admission Control则是资源管理方面的作用。
|
||||
+ 支持同时提供https(默认监听在6443端口)和http API(默认监听在127.0.0.1的8080端口),其中http API是非安全接口,不做任何认证授权机制,kube-scheduler、kube-controller-manager 一般和 kube-apiserver 部署在同一台机器上,它们使用非安全端口和 kube-apiserver通信; 其他集群外部就使用HTTPS访问 apiserver
|
||||
+ 关于authorization-mode=Node,RBAC v1.7+支持Node授权,配合NodeRestriction准入控制来限制kubelet仅可访问node、endpoint、pod、service以及secret、configmap、PV和PVC等相关的资源;需要注意的是v1.7中Node 授权是默认开启的,v1.8中需要显式配置开启,否则 Node无法正常工作
|
||||
+ 缺省情况下 kubernetes 对象保存在 etcd /registry 路径下,可以通过 --etcd-prefix 参数进行调整
|
||||
+ 详细参数配置请参考`kube-apiserver --help`,关于认证、授权和准入控制请[阅读](https://github.com/feiskyer/kubernetes-handbook/blob/master/components/apiserver.md)
|
||||
|
@ -150,28 +126,27 @@ Documentation=https://github.com/GoogleCloudPlatform/kubernetes
|
|||
|
||||
[Service]
|
||||
ExecStart={{ bin_dir }}/kube-controller-manager \
|
||||
--address=127.0.0.1 \
|
||||
--master=http://127.0.0.1:8080 \
|
||||
--bind-address={{ inventory_hostname }} \
|
||||
--allocate-node-cidrs=true \
|
||||
--service-cluster-ip-range={{ SERVICE_CIDR }} \
|
||||
--cluster-cidr={{ CLUSTER_CIDR }} \
|
||||
--cluster-name=kubernetes \
|
||||
--cluster-signing-cert-file={{ ca_dir }}/ca.pem \
|
||||
--cluster-signing-key-file={{ ca_dir }}/ca-key.pem \
|
||||
--service-account-private-key-file={{ ca_dir }}/ca-key.pem \
|
||||
--root-ca-file={{ ca_dir }}/ca.pem \
|
||||
--horizontal-pod-autoscaler-use-rest-clients=true \
|
||||
--kubeconfig=/etc/kubernetes/kube-controller-manager.kubeconfig \
|
||||
--leader-elect=true \
|
||||
--node-cidr-mask-size={{ NODE_CIDR_LEN }} \
|
||||
--root-ca-file={{ ca_dir }}/ca.pem \
|
||||
--service-account-private-key-file={{ ca_dir }}/ca-key.pem \
|
||||
--service-cluster-ip-range={{ SERVICE_CIDR }} \
|
||||
--use-service-account-credentials=true \
|
||||
--v=2
|
||||
Restart=on-failure
|
||||
Restart=always
|
||||
RestartSec=5
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
+ --address 值必须为 127.0.0.1,因为当前 kube-apiserver 期望 scheduler 和 controller-manager 在同一台机器
|
||||
+ --master=http://127.0.0.1:8080 使用非安全 8080 端口与 kube-apiserver 通信
|
||||
+ --cluster-cidr 指定 Cluster 中 Pod 的 CIDR 范围,该网段在各 Node 间必须路由可达(calico 实现)
|
||||
+ --cluster-cidr 指定 Cluster 中 Pod 的 CIDR 范围,该网段在各 Node 间必须路由可达(flannel/calico 等网络插件实现)
|
||||
+ --service-cluster-ip-range 参数指定 Cluster 中 Service 的CIDR范围,必须和 kube-apiserver 中的参数一致
|
||||
+ --cluster-signing-* 指定的证书和私钥文件用来签名为 TLS BootStrap 创建的证书和私钥
|
||||
+ --root-ca-file 用来对 kube-apiserver 证书进行校验,指定该参数后,才会在Pod 容器的 ServiceAccount 中放置该 CA 证书文件
|
||||
|
@ -186,19 +161,17 @@ Documentation=https://github.com/GoogleCloudPlatform/kubernetes
|
|||
|
||||
[Service]
|
||||
ExecStart={{ bin_dir }}/kube-scheduler \
|
||||
--address=127.0.0.1 \
|
||||
--master=http://127.0.0.1:8080 \
|
||||
--bind-address={{ inventory_hostname }} \
|
||||
--kubeconfig=/etc/kubernetes/kube-scheduler.kubeconfig \
|
||||
--leader-elect=true \
|
||||
--v=2
|
||||
Restart=on-failure
|
||||
Restart=always
|
||||
RestartSec=5
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```
|
||||
|
||||
+ --address 同样值必须为 127.0.0.1
|
||||
+ --master=http://127.0.0.1:8080 使用非安全 8080 端口与 kube-apiserver 通信
|
||||
+ --leader-elect=true 部署多台机器组成的 master 集群时选举产生一个处于工作状态的 kube-controller-manager 进程
|
||||
|
||||
### 在master 节点安装 node 服务: kubelet kube-proxy
|
||||
|
|
|
@ -2,38 +2,11 @@
|
|||
|
||||
`kube_node` 是集群中运行工作负载的节点,前置条件需要先部署好`kube_master`节点,它需要部署如下组件:
|
||||
|
||||
+ docker:运行容器
|
||||
+ kubelet: kube_node上最主要的组件
|
||||
+ kube-proxy: 发布应用服务与负载均衡
|
||||
+ haproxy:用于请求转发到多个 apiserver,详见[HA-2x 架构](00-planning_and_overall_intro.md#ha-architecture)
|
||||
+ calico: 配置容器网络 (或者其他网络组件)
|
||||
|
||||
``` bash
|
||||
roles/kube-node/
|
||||
├── defaults
|
||||
│ └── main.yml # 变量配置文件
|
||||
├── tasks
|
||||
│ ├── main.yml # 主执行文件
|
||||
│ ├── node_lb.yml # haproxy 安装文件
|
||||
│ └── offline.yml # 离线安装 haproxy
|
||||
└── templates
|
||||
├── cni-default.conf.j2 # 默认cni插件配置模板
|
||||
├── haproxy.cfg.j2 # haproxy 配置模板
|
||||
├── haproxy.service.j2 # haproxy 服务模板
|
||||
├── kubelet-config.yaml.j2 # kubelet 独立配置文件
|
||||
├── kubelet-csr.json.j2 # 证书请求模板
|
||||
├── kubelet.service.j2 # kubelet 服务模板
|
||||
└── kube-proxy.service.j2 # kube-proxy 服务模板
|
||||
```
|
||||
|
||||
请在另外窗口打开`roles/kube-node/tasks/main.yml`文件,对照看以下讲解内容。
|
||||
|
||||
### 变量配置文件
|
||||
|
||||
详见 roles/kube-node/defaults/main.yml,举例以下3个变量配置说明
|
||||
- 变量`KUBE_APISERVER`,根据不同的节点情况,它有三种取值方式
|
||||
- 变量`MASTER_CHG`,变更 master 节点时会根据它来重新配置 haproxy
|
||||
|
||||
### 创建cni 基础网络插件配置文件
|
||||
|
||||
因为后续需要用 `DaemonSet Pod`方式运行k8s网络插件,所以kubelet.server服务必须开启cni相关参数,并且提供cni网络配置文件
|
||||
|
|
|
@ -1,30 +1,35 @@
|
|||
# 个性化集群参数配置
|
||||
|
||||
对于刚接触项目者,如"快速指南"说明,只需要:
|
||||
`kubeasz`创建集群主要在以下两个地方进行配置:(假设集群名xxxx)
|
||||
|
||||
- **1** 个配置:`/etc/ansible/hosts`
|
||||
- **1** 键安装:`ansible-playbook /etc/ansible/90.setup.yml`
|
||||
- clusters/xxxx/hosts 文件(模板在example/hosts.multi-node):集群主要节点定义和主要参数配置、全局变量
|
||||
- clusters/xxxx/config.yml(模板在examples/config.yml):其他参数配置或者部分组件附加参数
|
||||
|
||||
具体来讲 `kubeasz`创建集群主要在以下两个地方进行配置:
|
||||
## clusters/xxxx/hosts (ansible hosts)
|
||||
|
||||
- ansible hosts 文件(模板在examples目录):集群主要节点定义和主要参数配置、全局变量
|
||||
- roles/xxx/defaults/main.yml 文件:其他参数配置或者部分组件附加参数
|
||||
|
||||
## ansible hosts
|
||||
|
||||
项目在[快速指南](quickStart.md)或者[集群规划与安装概览](00-planning_and_overall_intro.md)已经介绍过,主要包括集群节点定义和集群范围的主要参数配置;目前提供四种集群部署模板。
|
||||
如[集群规划与安装概览](00-planning_and_overall_intro.md)中介绍,主要包括集群节点定义和集群范围的主要参数配置
|
||||
|
||||
- 尽量保持配置简单灵活
|
||||
- 尽量保持配置项稳定
|
||||
|
||||
## roles/xxx/defaults/main.yml
|
||||
常用设置项:
|
||||
|
||||
- 修改容器运行时: CONTAINER_RUNTIME="containerd"
|
||||
- 修改集群网络插件:CLUSTER_NETWORK="calico"
|
||||
- 修改容器网络地址:CLUSTER_CIDR="192.168.0.0/16"
|
||||
- 修改NodePort范围:NODE_PORT_RANGE="30000-32767"
|
||||
|
||||
## clusters/xxxx/config.yml
|
||||
|
||||
主要包括集群某个具体组件的个性化配置,具体组件的配置项可能会不断增加;
|
||||
|
||||
- 可以在不做任何配置更改情况下使用默认值创建集群
|
||||
- 可以根据实际需要配置 k8s 集群,常用举例
|
||||
- 配置 lb 节点负载均衡算法:修改 roles/ex-lb/defaults/main.yml 变量 BALANCE_ALG: "roundrobin"
|
||||
- 配置 docker 国内镜像加速站点:修改 roles/docker/defaults/main.yml 相关变量
|
||||
- 配置 apiserver 支持公网域名:修改 roles/kube-master/defaults/main.yml 相关变量
|
||||
- 配置 flannel 使用镜像版本:修改 roles/flannel/defaults/main.yml 相关变量
|
||||
- 配置选择不同 addon 组件:修改roles/cluster-addon/defaults/main.yml
|
||||
- 配置使用离线安装系统包:INSTALL_SOURCE: "offline" (需要ezdown -P 下载离线系统软件)
|
||||
- 配置集群节点安全加固:OS_HARDEN: true
|
||||
- 配置CA证书以及其签发证书的有效期
|
||||
- 配置 docker 国内镜像加速:ENABLE_MIRROR_REGISTRY: true
|
||||
- 配置 docker 容器存储目录:DOCKER_STORAGE_DIR: "/var/lib/docker"
|
||||
- 配置 apiserver 支持公网域名:MASTER_CERT_HOSTS
|
||||
- 配置 cluster-addon 组件安装
|
||||
- ...
|
||||
|
|
|
@ -6,9 +6,31 @@
|
|||
- 客户端 circtl 使用指南 https://github.com/containerd/cri/blob/master/docs/crictl.md
|
||||
- man 文档 https://github.com/containerd/containerd/tree/master/docs/man
|
||||
|
||||
目前 containerd 官方文档还在整理中,但是作为集成在 kubernetes 集群里面使用,阅读以上的文档也就够了。
|
||||
|
||||
## kubeasz 集成安装 containerd
|
||||
|
||||
- 按照 example 例子,在 ansible hosts 设置全局变量 `CONTAINER_RUNTIME="containerd"`
|
||||
- 执行 `ansible-playbook 90.setup.yml` 或 `ezctl setup` 即可
|
||||
- 安装前修改配置文件,在clusters/xxxx/hosts 中修改全局变量 `CONTAINER_RUNTIME="containerd"`
|
||||
- 其他正常执行安装即可:分步安装`ezctl setup xxxx 03`,一键安装`ezctl setup xxxx all`
|
||||
|
||||
## 命令对比
|
||||
|
||||
|命令 |docker |crictl(推荐) |ctr |
|
||||
|:- |:- |:- |:- |
|
||||
|查看容器列表 |docker ps |crictl ps |ctr -n k8s.io c ls |
|
||||
|查看容器详情 |docker inspect |crictl inspect |ctr -n k8s.io c info |
|
||||
|查看容器日志 |docker logs |crictl logs |无 |
|
||||
|容器内执行命令 |docker exec |crictl exec |无 |
|
||||
|挂载容器 |docker attach |crictl attach |无 |
|
||||
|容器资源使用 |docker stats |crictl stats |无 |
|
||||
|创建容器 |docker create |crictl create |ctr -n k8s.io c create |
|
||||
|启动容器 |docker start |crictl start |ctr -n k8s.io run |
|
||||
|停止容器 |docker stop |crictl stop |无 |
|
||||
|删除容器 |docker rm |crictl rm |ctr -n k8s.io c del |
|
||||
|查看镜像列表 |docker images |crictl images |ctr -n k8s.io i ls |
|
||||
|查看镜像详情 |docker inspect |crictl inspecti|无 |
|
||||
|拉取镜像 |docker pull |crictl pull |ctr -n k8s.io i pull |
|
||||
|推送镜像 |docker push |无 |ctr -n k8s.io i push |
|
||||
|删除镜像 |docker rmi |crictl rmi |ctr -n k8s.io i rm |
|
||||
|查看Pod列表 |无 |crictl pods |无 |
|
||||
|查看Pod详情 |无 |crictl inspectp|无 |
|
||||
|启动Pod |无 |crictl runp |无 |
|
||||
|停止Pod |无 |crictl stopp |无 |
|
||||
|
|
|
@ -16,8 +16,8 @@
|
|||
"log-driver": "json-file",
|
||||
"log-level": "warn",
|
||||
"log-opts": {
|
||||
"max-size": "15m",
|
||||
"max-file": "3"
|
||||
"max-size": "50m",
|
||||
"max-file": "1"
|
||||
},
|
||||
"storage-driver": "overlay2"
|
||||
}
|
||||
|
|
|
@ -69,7 +69,7 @@ podPidsLimit: -1
|
|||
port: 10250
|
||||
# disable readOnlyPort
|
||||
readOnlyPort: 0
|
||||
{% if ansible_distribution_release == "bionic" %}
|
||||
{% if ansible_distribution == "Ubuntu" and ansible_distribution_major_version|int > 16 %}
|
||||
resolvConf: /run/systemd/resolve/resolv.conf
|
||||
{% else %}
|
||||
resolvConf: /etc/resolv.conf
|
||||
|
|
Loading…
Reference in New Issue