當前位置:編程學習大全網 - 源碼下載 - k8s The connection to the server was refused 問題解決記錄

k8s The connection to the server was refused 問題解決記錄

最近公司的 k8s 集群出現了壹個問題:在執行任何 kubectl 命令時都會出現以下錯誤,本文就記錄壹下該問題的溯源過程以及解決方式,希望對大家有幫助:

相信很多朋友都遇到過這個問題, 6443 是 k8s APIServer 的默認端口,出現訪問被拒絕肯定是 kubelet 有問題或者被防火墻攔截了,這裏先看壹下這個端口上的 kubelet 是不是還或者:

運行之後什麽都沒有返回,也就是說 APIServer 完全沒有提供服務 ,那我們就去查看壹下 kubelet 的日誌,大家都知道使用 kubeadm 搭建的 k8s集群裏,APIServer 都是在 docker 裏運行的,這裏我們先找到對應的容器,記得加 -a ,因為該容器可能已經處於非正常狀態了:

這裏能看到兩個容器,可以看到 容器的狀態已經是 Exited 了 ,註意下面的 pause 容器,這個只是用來引導 APIServer 的,並不是服務的實際運行容器,所以看不到日誌,所以查看日誌時不要輸錯容器 id 了。接下來查看 APIServer 的日誌:

從最後壹行可以看到,是 APIServer 在嘗試創建存儲時出現了問題,導致無法正確啟動服務,由於 k8s 是使用 etcd 作為存儲的,所以我們再來查看 etcd 的日誌。

註意,我這裏 etcd 也是運行在 docker 裏的,如果妳是直接以 service 的形式運行的話需要使用 systemctl status etcd 來查看日誌,下面是 docker 的 etcd 日誌查看:

可以看到 etcd 壹直在循環輸出上面的錯誤日誌直到超時退出,從裏面可以提取到壹條關鍵錯誤,就是 error "tls: failed to verify client's certificate: x509: certificate has expired or is not yet valid 。這個錯誤對於經常維護 k8s 集群的朋友可能很熟悉了,又是證書到期了。

這個集群有三臺 master,分別是 171 、 181 和 191 ,可以從錯誤信息前看到是在請求 181 時出現了證書驗證失敗的問題,我們登陸 181 機器來驗證錯誤:

經過排查,發現 k8s 的相關證書都沒事,但是 etcd 的證書都到期了。關於 k8s 需要的證書可以看這篇文章,接下來我們就來解決問題:

Kubeadm安裝的K8S集群1年證書過期問題的解決思路

註意,由於 k8s 版本問題,這壹部分的內容可能和妳的不太壹樣,我所使用的版本如下:

如果版本相差過大的話請進行百度,相關的解決方案還是挺多的,下面解決方案請先配合 -h 使用, 註意:以下操作會導致服務停止,請謹慎執行

備份原始文件

重新生成證書

重新生成證書需要集群初始化時的配置文件,我的配置文件 kubeadm.yaml 如下:

其中 192.168.100.170 是 VIP, 171 、 181 、 191 分別對應 master1 、 master2 、 master3 主機。接下來使用配置文件重新簽發證書,每個管理節點都要執行:

重新生成配置文件

這個命令也需要每個管理節點都執行壹次,被重新生成的配置文件包括下列幾個:

重啟管理節點的 k8s

重啟 etcd,apiserver,controller-manager,scheduler 容器,壹般情況下 kubectl 都可以正常使用了,記得 kubectl get nodes 查看節點的狀態。

重新生成工作節點的配置文件

如果上壹步查看的工作節點的狀態還是為 NotReady 的話,就需要重新進行生成,如果妳根證書也更換了的話就會導致這個問題,工作節點的證書也會失效,直接備份並移除下面的證書並重啟 kubelet 即可:

如果不行的話就直接把管理節點的 /etc/kubernetes/pki/ca.crt 復制到對應工作節點的相同目錄下然後再次啟動 kubelet。等待三分鐘左右應該就可以在管理節點上看到該工作節點的狀態變為 Ready 。

k8s 的證書只有壹年的設置確定有點坑,雖然為了讓使用者更新到最新版本的本意是好的。如果妳現在 k8s 集群還是正常但是並沒有執行過證書更新操作的話,請及時查看妳的證書到期時間,等到證書到期就為時已晚了。

  • 上一篇:基礎代謝計算公式
  • 下一篇:遊戲繁轉簡軟件使用方法
  • copyright 2024編程學習大全網