春节期间我们更换了 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, runkubeadm init phase upload-certs --upload-certson 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 集群操作引发全站全站故障，由此给您带来很大的麻烦，请您谅解。