升级为集群
高可用¶
前面我们课程中的集群是单 master 的集群，对于生产环境风险太大了，非常有必要做一个高可用的集群，这里的高可用主要是针对控制面板来说的，比如 kube-apiserver、etcd、kube-controller-manager、kube-scheduler 这几个组件，其中 kube-controller-manager 于 kube-scheduler 组件是 Kubernetes 集群自己去实现的高可用，当有多个组件存在的时候，会自动选择一个作为 Leader 提供服务，所以不需要我们手动去实现高可用，apiserver 和 etcd 就需要手动去搭建高可用的集群的。高可用的架构有很多，比如典型的 haproxy + keepalived 架构，或者使用 nginx 来做代理实现。我们这里为了说明如何将单 master 升级为高可用的集群，采用相对更简单的 nginx 模式，当然这种模式也有一些缺点，但是足以说明高可用的实现方式了。架构如下图所示：
从上面架构图上可以看出来，我们需要在所有的节点上安装一个 nginx 来代理 apiserver，这里我们准备3个节点作为控制平面节点：ydzs-master、ydzs-master2、ydzs-master3，这里我们默认所有节点都已经正常安装配置好了 Docker：
在开始下面的操作之前，在
所有节点hosts 中配置如下所示的信息：
$ cat /etc/hosts
11 api.k8s.local
170 ydzs-master2
171 ydzs-master3
111 ydzs-master
157 ydzs-node3
159 ydzs-node4
160 ydzs-node5
162 ydzs-node6
122 ydzs-node1
123 ydzs-node2
更新证书¶
由于我们要将集群替换成高可用的集群，那么势必会想到我们会用一个负载均衡器来代理 APIServer，也就是这个负载均衡器访问 APIServer 的时候要能正常访问，所以默认安装的 APIServer 证书就需要更新，因为里面没有包含我们需要的地址，需要保证在 SAN 列表中包含一些额外的名称。
首页我们一个 kubeadm 的配置文件，如果一开始安装集群的时候你就是使用的配置文件，那么我们可以直接更新这个配置文件，但是如果你没有使用配置文件，直接使用的
kubeadm init来安装的集群，那么我们可以从集群中获取 kubeadm 的配置信息来创建一个配置文件，因为 kubeadm 会将其配置写入到 kube-system 命名空间下面一个名为kubeadm-config的 ConfigMap 中。可以直接执行如下所示的命令将该配置导出：
$ kubectl -n kube-system get configmap kubeadm-config -o jsonpath='{.data.ClusterConfiguration}' > kubeadm.yaml
上面的命令会导出一个名为 kubeadm.yaml 的配置文件，内容如下所示：
apiServer:
extraArgs:
authorization-mode: Node,RBAC
timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta2
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controllerManager: {}
dns:
type: CoreDNS
etcd:
local:
dataDir: /var/lib/etcd
imageRepository: registry.aliyuncs.com/k8sxio
kind: ClusterConfiguration
kubernetesVersion: v11
networking:
dnsDomain: cluster.local
podSubnet: 20/16
serviceSubnet: 0/12
scheduler: {}
上面的配置中并没有列出额外的 SAN 信息，我们要添加一个新的数据，需要在
apiServer属性下面添加一个certsSANs的列表。如果你在启动集群的使用就使用的了 kubeadm 的配置文件，可能里面就已经包含 certSANs 列表了，如果没有我们就需要添加它，比如我们这里要添加一个新的域名api.k8s.local以及 ydzs-master2 和 ydzs-master3 这两个主机名和 10.151.30.70、10.151.30.71 这两个新的 IP 地址，那么我们需要在 apiServer 下面添加如下所示的数据：
apiServer:
certSANs:
- api.k8s.local
- ydzs-master
- ydzs-master2
- ydzs-master3
- 111
- 170
- 171
extraArgs:
authorization-mode: Node,RBAC
timeoutForControlPlane: 4m0s
上面我只列出了 apiServer 下面新增的 certSANs 信息，这些信息是包括在标准的 SAN 列表之外的，所以不用担心这里没有添加 kubernetes、kubernetes.default 等等这些信息，因为这些都是标准的 SAN 列表中的。
更新完 kubeadm 配置文件后我们就可以更新证书了，首先我们移动现有的 APIServer 的证书和密钥，因为 kubeadm 检测到他们已经存在于指定的位置，它就不会创建新的了。
$ mv /etc/kubernetes/pki/apiserver.{crt,key} ~
然后直接使用 kubeadm 命令生成一个新的证书：
$ kubeadm init phase certs apiserver --config kubeadm.yaml
W0902 10:05:006627 832 validation.go:28] Cannot validate kubelet config - no validator is available
W0902 10:05:006754 832 validation.go:28] Cannot validate kube-proxy config - no validator is available
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [ydzs-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local api.k8s.local ydzs-master2 ydzs-master3] and IPs [1 1112 111 170 171]
通过上面的命令可以查看到 APIServer 签名的 DNS 和 IP 地址信息，一定要和自己的目标签名信息进行对比，如果缺失了数据就需要在上面的 certSANs 中补齐，重新生成证书。
该命令会使用上面指定的 kubeadm 配置文件为 APIServer 生成一个新的证书和密钥，由于指定的配置文件中包含了 certSANs 列表，那么 kubeadm 会在创建新证书的时候自动添加这些 SANs。
最后一步是重启 APIServer 来接收新的证书，最简单的方法是直接杀死 APIServer 的容器：
$ docker ps | grep kube-apiserver | grep -v pause
7fe227a5dd3c aa63290ccd50 "kube-apiserver --ad…" 14 hours ago Up 14 hours k8s_kube-apiserver_kube-apiserver-ydzs-master_kube-system_6aa38ee2d66b7d9b6660a88700d00581_0
$ docker kill 7fe227a5dd3c
7fe227a5dd3c
容器被杀掉后，kubelet 会自动重启容器，然后容器将接收新的证书，一旦 APIServer 重启后，我们就可以使用新添加的 IP 地址或者主机名来连接它了，比如我们新添加的
api.k8s.local。
验证证书¶
要验证证书是否更新我们可以直接去编辑 kubeconfig 文件中的 APIServer 地址，将其更换为新添加的 IP 地址或者主机名，然后去使用 kubectl 操作集群，查看是否可以正常工作。
当然我们可以使用 openssl 命令去查看生成的证书信息是否包含我们新添加的 SAN 列表数据：
$ openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text
Certificate:
......
Subject: CN=kube-apiserver
......
X509v3 Subject Alternative Name:
DNS:ydzs-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:api.k8s.local, DNS:ydzs-master2, DNS:ydzs-master3, IP Address:1, IP Address:1112, IP Address:111, IP Address:170, IP Address:171
......
如果上面的操作都一切顺利，最后一步是将上面的集群配置信息保存到集群的 kubeadm-config 这个 ConfigMap 中去，这一点非常重要，这样以后当我们使用 kubeadm 来操作集群的时候，相关的数据不会丢失，比如升级的时候还是会带上 certSANs 中的数据进行签名的。
$ kubeadm config upload from-file --config kubeadm.yaml
使用上面的命令保存配置后，我们同样可以用下面的命令来验证是否保存成功了：
$ kubectl -n kube-system get configmap kubeadm-config -o yaml
更新 APIServer 证书的名称在很多场景下都会使用到，比如在控制平面前面添加一个负载均衡器，或者添加新的 DNS 名称或 IP 地址来使用控制平面的端点，所以掌握更新集群证书的方法也是非常有必要的。
为控制平面创建负载均衡器¶
接下来我们为控制平面创建一个负载平衡器。如何设置和配置负载均衡器的具体细节因解决方案不同，但是一般的方案都需要包括下面的功能：
- 使用4层负载平衡器（TCP而不是HTTP / HTTPS）
- 运行健康检查应配置为 SSL，而不是 TCP 运行状况检查
不管用哪一种方式，我们最好创建一个 DNS CNAME 条目以指向您的负载均衡器（强烈建议）。如果您需要更换或重新配置负载均衡解决方案，这将为您提供更多的灵活性，因为 DNS CNAME 保持不变，就不用再次去更新证书了。
我们这里采用的方案是在节点上使用 nginx 来作为一个负载均衡器，下面的操作需要在
所有节点上操作：
$ mkdir -p /etc/kubernetes
$ cat > /etc/kubernetes/nginx.conf << EOF
error_log stderr notice;
worker_processes 2;
worker_rlimit_nofile 130048;
worker_shutdown_timeout 10s;
events {
multi_accept on;
use epoll;
worker_connections 16384;
}
stream {
upstream kube_apiserver {
least_conn;
server ydzs-master:6443;
server ydzs-master2:6443;
server ydzs-master3:6443;
}
server {
listen 8443;
proxy_pass kube_apiserver;
proxy_timeout 10m;
proxy_connect_timeout 1s;
}
}
http {
aio threads;
aio_write on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 5m;
keepalive_requests 100;
reset_timedout_connection on;
server_tokens off;
autoindex off;
server {
listen 8081;
location /healthz {
access_log off;
return 200;
}
location /stub_status {
stub_status on;
access_log off;
}
}
}
EOF
使用上面的配置启动一个 nginx 容器：
$ docker run --restart=always \\
-v /etc/kubernetes/nginx.conf:/etc/nginx/nginx.conf \\
-v /etc/localtime:/etc/localtime:ro \\
--name k8s-ha \\
--net host \\
-d \\
nginx
启动成功后 apiserver 的负载均衡地址就成了
https://api.k8s.local:8443
。然后我们将 kubeconfig 文件中的 apiserver 地址替换成负载均衡器的地址。
# 修改 kubelet 配置
$ vi /etc/kubernetes/kubelet.conf
......
server: https://api.k8s.local:8443
name: kubernetes
......
$ systemctl restart kubelet
# 修改 controller-manager
$ vi /etc/kubernetes/controller-manager.conf
......
server: https://api.k8s.local:8443
name: kubernetes
......
# 重启
$ docker kill $(docker ps | grep kube-controller-manager | \\
grep -v pause | cut -d' ' -f1)
# 修改 scheduler
$ vi /etc/kubernetes/scheduler.conf
......
server: https://api.k8s.local:8443
name: kubernetes
......
# 重启
$ docker kill $(docker ps | grep kube-scheduler | grep -v pause | \\
cut -d' ' -f1)
然后更新 kube-proxy
$ kubectl -n kube-system edit cm kube-proxy
......
kubeconfig.conf: |-
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
server: https://api.k8s.local:8443
name: default
......
当然还有 kubectl 访问集群的
~/.kube/config文件也需要修改。
更新控制面板¶
由于我们现在已经在控制平面的前面添加了一个负载平衡器，因此我们需要使用正确的信息更新此 ConfigMap。（您很快就会将控制平面节点添加到集群中，因此在此ConfigMap中拥有正确的信息很重要。）
首先，使用以下命令从 ConfigMap 中获取当前配置：
$ kubectl -n kube-system get configmap kubeadm-config -o jsonpath='{.data.ClusterConfiguration}' > kubeadm.yaml
然后在当前配置文件里面里面添加
controlPlaneEndpoint属性，用于指定控制面板的负载均衡器的地址。
$ vi kubeadm.yaml
controlPlaneEndpoint: api.k8s.local:8443 # 添加改配置
apiServer:
certSANs:
- api.k8s.local
- ydzs-master
- ydzs-master2
- ydzs-master3
- 111
- 170
- 171
......
编辑完文件后，使用以下命令将其上传回集群：
$ kubeadm config upload from-file --config kubeadm.yaml
然后需要在
kube-public命名空间中更新cluster-info这个 ConfigMap，该命名空间包含一个Kubeconfig 文件，该文件的server:一行指向单个控制平面节点。只需使用
kubectl -n kube-public edit cm cluster-info
更新该 server: 行以指向控制平面的负载均衡器即可。
$ kubectl -n kube-public edit cm cluster-info
......
server: https://api.k8s.local:8443
name: ""
......
$ kubectl cluster-info
Kubernetes master is running at https://api.k8s.local:8443
KubeDNS is running at https://api.k8s.local:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
KubeDNSUpstream is running at https://api.k8s.local:8443/api/v1/namespaces/kube-system/services/kube-dns-upstream:dns/proxy
Metrics-server is running at https://api.k8s.local:8443/api/v1/namespaces/kube-system/services/https:metrics-server:/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
更新完成就可以看到 cluster-info 的信息变成了负载均衡器的地址了。
添加控制平面¶
接下来我们来添加额外的控制平面节点，首先使用如下命令来将集群的证书上传到集群中，供其他控制节点使用：
$ kubeadm init phase upload-certs --upload-certs
I0903 15:13:192467 20533 version.go:251] remote version is much newer: v0; falling back to: stable-17
W0903 15:13:739892 20533 validation.go:28] Cannot validate kube-proxy config - no validator is available
W0903 15:13:739966 20533 validation.go:28] Cannot validate kubelet config - no validator is available
[upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[upload-certs] Using certificate key:
e71ef7ede98e49f5f094b150d604c7ad50f125279180a7320b1b14ef3ccc3a34
上面的命令会生成一个新的证书密钥，但是只有2小时有效期。由于我们现有的集群已经运行一段时间了，所以之前的启动 Token 也已经失效了（Token 的默认生存期为24小时），所以我们也需要创建一个新的 Token 来添加新的控制平面节点：
$ kubeadm token create --print-join-command --config kubeadm.yaml
W0903 15:29:958329 25049 validation.go:28] Cannot validate kube-proxy config - no validator is available
W0903 15:29:958457 25049 validation.go:28] Cannot validate kubelet config - no validator is available
kubeadm join api.k8s.local:8443 --token f27w7m.adelvl3waw9kqdhp --discovery-token-ca-cert-hash sha256:6917cbf7b0e73ecfef77217e9a27e76ef9270aa379c34af30201abd0f1088c34
上面的命令最后给出的提示是添加 node 节点的命令，我们这里要添加控制平面节点就要使用如下所示的命令：
$ kubeadm join <DNS CNAME of load balancer>:<lb port> \\
--token <bootstrap-token> \\
--discovery-token-ca-cert-hash sha256:<CA certificate hash> \\
--control-plane --certificate-key <certificate-key>
获得了上面的添加命令过后，登录到 ydzs-master2 节点进行相关的操作，在 ydzs-master2 节点上安装软件：
$ yum install -y kubeadm-11-0 kubelet-11-0 kubectl-11-0
要加入控制平面，我们可以先拉取相关镜像：
$ kubeadm config images pull --image-repository registry.aliyuncs.com/k8sxio
然后执行上面生成的 join 命令，将参数替换后如下所示：
$ kubeadm join api.k8s.local:8443 \\
--token f27w7m.adelvl3waw9kqdhp \\
--discovery-token-ca-cert-hash sha256:6917cbf7b0e73ecfef77217e9a27e76ef9270aa379c34af30201abd0f1088c34 \\
--control-plane --certificate-key e71ef7ede98e49f5f094b150d604c7ad50f125279180a7320b1b14ef3ccc3a34
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[preflight] Running pre-flight checks before initializing the new control plane instance
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[download-certs] Downloading the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [ydzs-master2 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local api.k8s.local api.k8s.local ydzs-master2 ydzs-master3] and IPs [1 170 111 170 171]
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [ydzs-master2 localhost] and IPs [170 11 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [ydzs-master2 localhost] and IPs [170 11 ::1]
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[certs] Using the existing "sa" key
[kubeconfig] Generating kubeconfig files
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
W0903 15:55:444989 4353 manifests.go:214] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
W0903 15:55:457787 4353 manifests.go:214] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[control-plane] Creating static Pod manifest for "kube-scheduler"
W0903 15:55:459829 4353 manifests.go:214] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[check-etcd] Checking that the etcd cluster is healthy
......
This node has joined the cluster and a new control plane instance was created:
* Certificate signing request was sent to apiserver and approval was received.
* The Kubelet was informed of the new secure connection details.
* Control plane (master) label and taint were applied to the new node.
* The Kubernetes control plane instances scaled up.
* A new etcd member was added to the local/stacked etcd cluster.
To start administering your cluster from this node, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Run 'kubectl get nodes' to see this node join the cluster.
如果在 etcd 里面有残留的废弃节点数据，可以用如下命令删除：
# 列出所有成员
$ ./etcdctl --endpoints=$ENDPOINTS member list
# 删除指定成员
$ ./etcdctl --endpoints=$ENDPOINTS member remove b9057cfdc8ff17ce
到这里可以看到 ydzs-master2 节点就成功加入到了控制平面中，然后根据上面的提示配置 kubeconfig 文件。然后用同样的方式添加 ydzs-master3 节点，都添加成功后，在 ydzs-master3 节点上执行如下所示的命令来验证 etcd 集群使用正常：
$ docker run --rm -it \\
--net host \\
-v /etc/kubernetes:/etc/kubernetes registry.aliyuncs.com/k8sxio/etcd:3-0 etcdctl \\
--cert /etc/kubernetes/pki/etcd/peer.crt \\
--key /etc/kubernetes/pki/etcd/peer.key \\
--cacert /etc/kubernetes/pki/etcd/ca.crt \\
--endpoints https://171:2379 endpoint health --cluster
# endpoint status --write-out=table 查看状态
https://170:2379 is healthy: successfully committed proposal: took = 410192ms
https://171:2379 is healthy: successfully committed proposal: took = 077275ms
https://111:2379 is healthy: successfully committed proposal: took = 282643ms
$ docker run --rm -it --net host -v /etc/kubernetes:/etc/kubernetes registry.aliyuncs.com/k8sxio/etcd:3-0 etcdctl --cert /etc/kubernetes/pki/etcd/peer.crt --key /etc/kubernetes/pki/etcd/peer.key --cacert /etc/kubernetes/pki/etcd/ca.crt --endpoints https://111:2379,https://170:2379,https://171:2379 endpoint status --write-out=table
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| https://111:2379 | 3d1fd8983aed809 | 3 | 52 MB | false | false | 113 | 119502257 | 119502257 | |
| https://170:2379 | af2e11ae8aa72bde | 3 | 52 MB | true | false | 113 | 119502259 | 119502259 | |
| https://171:2379 | e7a7b252880befdf | 3 | 52 MB | false | false | 113 | 119502259 | 119502259 | |
+---------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
正常我们就可以看到 etcd 集群正常了，但是由于控制平台的3个节点是先后安装的，所以前面两个节点的 etcd 中并不包含其他 etcd 节点的信息，所以我们需要同步所有控制平面节点的 etcd 集群配置：
$ cat /etc/kubernetes/manifests/etcd.yaml
......
- --initial-cluster=ydzs-master=https://111:2380,ydzs-master2=https://170:2380,ydzs-master3=https://171:2380
......
最后执行如下所示的命令查看集群是否正常：
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ydzs-master Ready master 299d v11
ydzs-master2 Ready master 34m v11
ydzs-master3 Ready master 10m v11
ydzs-node1 Ready <none> 299d v11
ydzs-node2 Ready <none> 299d v11
ydzs-node3 Ready <none> 297d v11
ydzs-node4 Ready <none> 297d v11
ydzs-node5 Ready <none> 225d v11
ydzs-node6 Ready <none> 225d v11
这里我们就可以看到 ydzs-master、ydzs-master2、ydzs-master3 3个节点变成了 master 节点，我们也就完成了将单 master 升级为多 master 的高可用集群了。