【故障公告】k8s 開船記：增加控制艙（control-plane）造成的翻船

春節期間我們更換了 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 集群操作引發全站全站故障，由此給您帶來很大的麻煩，請您諒解，

標籤：其他

上一篇：【基礎】性能測驗，從0到實戰（手把手教，非常實用）

下一篇：inter Course Certificate