1、背景

　　去年協助某部門在他們測試環境下部署了一套Kubernetes叢集（1Master 4Worker），當時在Kubernetes叢集配置了公司內部的映象倉庫，今年上半年由於公司機房網路環境調整，某部門的伺服器連不上公司映象倉庫了，於是臨時在他們測試環境下部署了一套Harbor映象倉庫，用於接收他們業務構建的容器映象，並將部署Kubernetes叢集用到的映象推送到了新的Harbor映象倉庫裡面，由於部署Kubernetes叢集時還部署了一些附件元件（日誌、監控、微服務治理等），整個Kubernetes叢集工作負載數量較多，所以就沒挨著修改工作負載的映象地址，導致部分工作負載還是配置了公司映象倉庫映象，由於測試環境使用不多，加上附件元件比較穩定，最近半年附件元件對應Pod也沒有重新排程，所以Kubernetes叢集及其元件執行平穩。

　　上週末某部門機房需要斷電進行機房線路加固，週一早晨機房來電後，發現Kubernetes叢集沒有自動恢復，然後他們運維人員聯絡我這邊來幫他們恢復Kubernetes叢集。

2、問題排查及解決

登入Kubernetes叢集發現kube-apiserver一直重啟，導致Kubernetes控制組件一直在重啟，檢視kube-apiserver日誌報不斷在嘗試連線etcd 2379埠錯誤：

W0420 06:27:37.750969       1 clientconn.go:1208] grpc: addrConn.createTransport failed to connect to {https://192.111.1.134:2379  <nil> 0 <nil>}. Err :connection error: desc = "transport: Error while dialing dial tcp 192.111.1.134:2379: connect: connection refused". Reconnecting...

然後，檢視etcd服務日誌，發現報如下錯誤：

 embed: rejected connection from   (error "tls: oversized record received with length 64774", ServerName "")

通過檢視etcd狀態可知etcd服務執行正常：

[root@master-sg-134 ~]# ETCDCTL_API=3 etcdctl --cacert=/etc/ssl/etcd/ssl/ca.pem --cert=/etc/ssl/etcd/ssl/member-master-sg-134.pem --key=/etc/ssl/etcd/ssl/member-master-sg-134-key.pem --endpoints="https://192.111.1.134:2379" endpoint status --write-out=table
+----------------------------+------------------+---------+---------+-----------+-----------+------------+
|          ENDPOINT          |        ID        | VERSION | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX |
+----------------------------+------------------+---------+---------+-----------+-----------+------------+
| https://192.111.1.134:2379 | 98184cb9ad9cec26 |  3.3.12 |   41 MB |      true |        21 |  195592703 |
+----------------------------+------------------+---------+---------+-----------+-----------+------------+
[root@master-sg-134 ~]# ETCDCTL_API=3 etcdctl --cacert=/etc/ssl/etcd/ssl/ca.pem --cert=/etc/ssl/etcd/ssl/member-master-sg-134.pem --key=/etc/ssl/etcd/ssl/member-master-sg-134-key.pem --endpoints="https://192.111.1.134:2379" endpoint health --write-out=table
https://192.111.1.134:2379 is healthy: successfully committed proposal: took = 844.331µs
[root@master-sg-134 ~]# ETCDCTL_API=3 etcdctl --cacert=/etc/ssl/etcd/ssl/ca.pem --cert=/etc/ssl/etcd/ssl/member-master-sg-134.pem --key=/etc/ssl/etcd/ssl/member-master-sg-134-key.pem --endpoints="https://192.111.1.134:2379" member list --write-out=table
+------------------+---------+-------+----------------------------+----------------------------+
|        ID        | STATUS  | NAME  |         PEER ADDRS         |        CLIENT ADDRS        |
+------------------+---------+-------+----------------------------+----------------------------+
| 98184cb9ad9cec26 | started | etcd1 | https://192.111.1.134:2380 | https://192.111.1.134:2379 |
+------------------+---------+-------+----------------------------+----------------------------+
[root@master-sg-134 ~]# 

將etcd資料匯入到etcd_data.json檔案中，通過檢視匯出的etcd_data.json檔案得知Kubernetes叢集資料正常。

ETCDCTL_API=3 etcdctl --cacert=/etc/ssl/etcd/ssl/ca.pem --cert=/etc/ssl/etcd/ssl/member-master-sg-134.pem --key=/etc/ssl/etcd/ssl/member-master-sg-134-key.pem --endpoints="https://192.111.1.134:2379" get / --prefix > etcd_data.json

備份Kubernetes叢集資料目錄：

tar -zcvf etcd-202201205.tar.gz /var/lib/etcd

通過對etcd元件的排查可以得知etcd服務執行正常，通過etcdctl客戶端也能正常連線etcd服務，所以etcd元件是沒問題的。但是，kube-apiserver Pod卻一直重啟報連不上etcd錯誤， /etc/kubernetes/manifests/kube-apiserver.yaml配置檔案裡面關於etcd相關配置也都正常，所以想著重啟一下kube-apiserver這個靜態Pod。

    - --etcd-cafile=/etc/ssl/etcd/ssl/ca.pem
    - --etcd-certfile=/etc/ssl/etcd/ssl/node-master-sg-134.pem
    - --etcd-keyfile=/etc/ssl/etcd/ssl/node-master-sg-134-key.pem
    - --etcd-servers=https://192.111.1.134:2379

由於kube-apiserver是靜態容器，用docker命令直接停止並刪除kube-apiserver相關的容器（pause容器和執行kube-apiserver程序容器）後，kubelet會自動重啟kube-apiserver這個靜態Pod，但是奇怪的是刪除kube-apiserver相關容器後發現kubelet並沒重啟kube-apiserver相關容器。

於是排查kubelet日誌和docker服務引擎日誌，通過docker服務引擎日誌可以看出映象倉庫中沒有libray/pause這個映象。

Dec 05 16:58:20 master-sg-134 dockerd[1403]: time="2022-12-05T16:58:20.610370733+08:00" level=warning msg="Error getting v2 registry: Get https://192.111.1.137:80/v2/: http: server gave HTTP response to HTTPS client"
Dec 05 16:58:20 master-sg-134 dockerd[1403]: time="2022-12-05T16:58:20.650481522+08:00" level=error msg="Not continuing with pull after error: unknown: repository library/pause not found

正常節點有這個映象，不需要去映象倉庫拉取，可能伺服器加電後，運維人員清理伺服器磁碟了。經排查kubelet使用了公司映象倉庫，於是修改kueblet配置將其改成在他們測試環境下部署的Harbor映象倉庫地址，並重啟kubelet服務。

[root@master-sg-134 ~]# cat /var/lib/kubelet/kubeadm-flags.env
KUBELET_KUBEADM_ARGS="--cgroup-driver=cgroupfs --network-plugin=cni --pod-infra-container-image=公司映象倉庫地址/cloudbases/pause:3.2"

重啟kueblet服務後，發下kube-apiserver這個靜態Pod成功啟動了，剩下的Kuberenetes控制面板元件及安裝的附加元件都跟著啟動了，然後處理所有報錯元件的映象地址，改成他們測試環境下部署的Harbor映象倉庫地址，之後整個Kubernetes叢集服務恢復。

 3、總結

遇到元件啟動報錯的情況下，一定要基於它們之間相互依賴關係進行排查，重點檢視元件日誌，基於日誌分析並解決問題。