【故障公告】k8s 开船记：增加控制舱（controlplane）造成的翻船

春节期间我们更换了 kubernetes 生产集群，旧集群的 kubernetes 版本是 1.17.0，新集群版本是 1.23.3，新集群上部署了 dapr，最近准备将更多独立部署的服务器部署到 k8s 集群上，比如 redis, memcached, mongodb。

新集群和旧集群一样都是高可用集群，但新集群开始只用了 1 个 control-plane 节点，今天本来的任务是给新集群再增加 2 个 control-plane 节点，实现高可用。

如何加入 control-plane 节点呢？ k8s 没有直接提供生成 join 命令的命令，下面的命令只能用于加入 worker 节点。

kubeadm token create --print-join-command

之前我们是在创建集群的时候，在执行 kubeadm init 命令之后就操作加入 control-plane 节点，kubeadm init 会生成加入命令

You can now join any number of the control-plane node running the following command on each as root:

  kubeadm join k8s-api:6443 --token ****** \
    --discovery-token-ca-cert-hash ****** \
    --control-plane --certificate-key ******

上面的命令实际上就是 token create --print-join-command 的输出加上 --control-plane 与 --certificate-key，但之前使用的 certificate-key 已经过期。

开始我们用下面的命令生成 certificate-key 加入集群

kubeadm certs certificate-key

但加入失败，报错信息如下

[download-certs] Downloading the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
error execution phase control-plane-prepare/download-certs: error downloading certs: error downloading the secret: Secret "kubeadm-certs" was not found in the "kube-system" Namespace. This Secret might have expired. Please, run kubeadm init phase upload-certs --upload-certs on a control plane to generate a new one

于是改用 upload-certs 命令

$ kubeadm init phase upload-certs --upload-certs
[upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[upload-certs] Using certificate key:
*****

将 upload-certs 命令生成的 certificate-key 用于 kubeadm join 命令，这个 key 果然可以，但是在加入过程中卡在了下面的地方

[etcd] Announced new etcd member joining to the existing etcd cluster
[etcd] Creating static Pod manifest for "etcd"
[etcd] Waiting for the new etcd member to join the cluster. This can take up to 40s
[kubelet-check] Initial timeout of 40s passed.

本以为新 control-plane 节点加入不了不会影响现有集群的正常运行，但一个残酷的现实突然而至 —— 已有且仅有的那台 control-plane 上 api-server 容器突然无法启动了，syslog 中的其中一条错误信息如下

"Unable to authenticate the request due to an error" err="Post "https://k8s-api:6443/apis/authentication.k8s.io/v1/tokenreviews": dial tcp 10.0.9.171:6443: connect: connection refused"

这时虽然 api-server 不能正常工作，但 worker 节点上的 pod 都正常运行，应用暂时没有受影响。

面对这样如履薄冰的场景，我们首先想到的是先恢复旧集群，将负载切换到旧集群，然后从容地处理新集群的问题，但故障如此会开玩笑，旧集群的 api-server 竟然也无法正常启动。

CONTAINER ID        IMAGE                                       COMMAND                  CREATED             STATUS           
0f30ff71a13d        0cae8d5cc64c                                "kube-apiserver --ad…"   5 seconds ago       Up 3 seconds  

命运会作弄人，故障也学会了。

面对如履薄冰与故障的作弄，我们做出了一个铤而走险的决定 —— 更新所有证书，之前成功操作过，但当时集群中没有负载。

用下面的命令三下五除二地完成了证书更新

$ cd /etc/kubernetes/pki/
$ mv {apiserver.crt,apiserver-etcd-client.key,apiserver-kubelet-client.crt,front-proxy-ca.crt,front-proxy-client.crt,front-proxy-client.key,front-proxy-ca.key,apiserver-kubelet-client.key,apiserver.key,apiserver-etcd-client.crt} ~/
$ kubeadm init phase certs all --control-plane-endpoint "k8s-api:6443"
$ cd /etc/kubernetes/
$ mv {admin.conf,controller-manager.conf,kubelet.conf,scheduler.conf} ~/
$ kubeadm init phase kubeconfig all --control-plane-endpoint "k8s-api:6443"

接下来就是重启 control-plane 节点服务器使用更新的证书。

重启的结局却是 —— 满园尽是502

走险失败后立即进入紧急抢险，用当前 control-plane 节点今天凌晨的快照创建镜像，用镜像重置整个系统。

重置后的 control-plane 节点成功启动后，从 control-plane 节点上看集群应该恢复了正常，worker 节点都处于 ready 状态，绝大多数 pod 都处于 running 状态，但是 pod 中的应用却不能正常工作，比如连不上其他服务、ingress 规则失效等。

开始以为要将所有 worker node 退出并重新加入集群才能恢复，但是在第1个 worker node 上操作退出时却卡在下面的地方

$ kubeadm reset
[reset] Unmounting mounted directories in "/var/lib/kubelet"

后来想到重启所有 worker node 试试，果然是任何时候重启大招不能忘，重启后很快一切恢复正常。

非常抱歉，今天 19:10~19:50 期间由于 k8s 集群操作引发全站全站故障，由此给您带来很大的麻烦，请您谅解。