K8S線上集群怎樣排查Node節(jié)點(diǎn)NotReady異常狀態(tài)

今天就跟大家聊聊有關(guān)K8S線上集群怎樣排查Node節(jié)點(diǎn)NotReady異常狀態(tài)，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

一，文章簡述

k8s 線上集群中 Node 節(jié)點(diǎn)狀態(tài)變成 NotReady 狀態(tài)，導(dǎo)致整個(gè) Node 節(jié)點(diǎn)中容器停止服務(wù)后的問題排查。

文章中所描述的是本人在項(xiàng)目中線上環(huán)境實(shí)際解決的，那除了如何解決該問題，更重要的是如何去排查這個(gè)問題的起因。

關(guān)于 Node 節(jié)點(diǎn)不可用的 NotReady 狀態(tài)，當(dāng)時(shí)也是花了挺久的時(shí)間去排查的。

二，Pod 狀態(tài)

在分析 NotReady 狀態(tài)之前，我們首先需要了解在 k8s 中 Pod 的狀態(tài)都有哪些。并且每個(gè)狀態(tài)都表示什么含義，不同狀態(tài)是很直觀的顯示出當(dāng)前 Pod 所處的創(chuàng)建信息。

為了避免大家對(duì) Node 和 Pod 的概念混淆，先簡單描述下兩者之間的關(guān)系（引用一張 K8S 官方圖）。

從圖中很直觀的顯示出最外面就是 Node 節(jié)點(diǎn)，而一個(gè) Node 節(jié)點(diǎn)中是可以運(yùn)行多個(gè) Pod 容器，再深入一層就是每個(gè) Pod 容器可以運(yùn)行多個(gè)實(shí)例 App 容器。

因此關(guān)于本篇文章所闡述的 Node 節(jié)點(diǎn)不可用，就會(huì)直接導(dǎo)致 Node 節(jié)點(diǎn)中所有的容器不可用。

毫無疑問，Node 節(jié)點(diǎn)是否健康，直接影響該節(jié)點(diǎn)下所有的實(shí)例容器的健康狀態(tài)，直至影響整個(gè) K8S 集群。

那么如何解決并排查 Node 節(jié)點(diǎn)的健康狀態(tài)？不急，我們先來聊聊關(guān)于關(guān)于 Pod 的生命周期狀態(tài)。

• Pending：該階段表示已經(jīng)被 Kubernetes 所接受，但是容器還沒有被創(chuàng)建，正在被 kube 進(jìn)行資源調(diào)度。

• 1：圖中數(shù)字 1 是表示在被 kube 資源調(diào)度成功后，開始進(jìn)行容器的創(chuàng)建，但是在這個(gè)階段是會(huì)出現(xiàn)容器創(chuàng)建失敗的現(xiàn)象

• Waiting或ContainerCreating：這兩個(gè)原因就在于容器創(chuàng)建過程中鏡像拉取失敗，或者網(wǎng)絡(luò)錯(cuò)誤容器的狀態(tài)就會(huì)發(fā)生轉(zhuǎn)變。

• Running：該階段表示容器已經(jīng)正常運(yùn)行。

• Failed：Pod 中的容器是以非 0 狀態(tài)（非正常）狀態(tài)退出的。

• 2：階段 2 可能出現(xiàn)的狀態(tài)為CrashLoopBackOff，表示容器正常啟動(dòng)但是存在異常退出。

• Succeeded：Pod 容器成功終止，并且不會(huì)再在重啟。

上面的狀態(tài)只是 Pod 生命周期中比較常見的狀態(tài)，還有一些狀態(tài)沒有列舉出來。

這。。。狀態(tài)有點(diǎn)多。休息 3 秒鐘

不過話又說回來，Pod 的狀態(tài)和 Node 狀態(tài)是一回事嗎？嗯。。。其實(shí)并不完全是一回事。

但是當(dāng)容器服務(wù)不可用時(shí)，首先通過 Pod 的狀態(tài)去排查是非常重要的。那么問題來了，如果 Node 節(jié)點(diǎn)服務(wù)不可用，Pod 還能訪問嗎？

答案是：不能。

因此排查Pod的健康狀態(tài)的意義就在于，是什么原因會(huì)導(dǎo)致Node節(jié)點(diǎn)服務(wù)不可用，因此這是一項(xiàng)非常重要的排查指標(biāo)。

三，業(yè)務(wù)回顧

由于本人的工作是和物聯(lián)網(wǎng)相關(guān)的，暫且我們假設(shè) 4 臺(tái)服務(wù)器（假設(shè)不考慮服務(wù)器本身性能問題，如果是這個(gè)原因那最好是升級(jí)服務(wù)器），其中一臺(tái)做 K8S-Master 搭建，另外 3 臺(tái)機(jī)器做 Worker 工作節(jié)點(diǎn)。

每個(gè) worker 就是一個(gè) Node 節(jié)點(diǎn)，現(xiàn)在需要在 Node 節(jié)點(diǎn)上去啟動(dòng)鏡像，一切正常 Node 就是 ready 狀態(tài)。

但是過了一段時(shí)間后，就成這樣了

這就是我們要說的 Node 節(jié)點(diǎn)變成 NotReady 狀態(tài)。

四，問題刨析

這跑著跑著就變成 NotReady 了，啥是 NotReady？

這都運(yùn)行一段時(shí)間了，你告訴我還沒準(zhǔn)備好？

好吧，那就看看為什么還沒準(zhǔn)備好。

4.1 問題分析

再回到我們前面說到問題，就是 Node 節(jié)點(diǎn)變成 NotReady 狀態(tài)后，Pod 容器是否還成正常運(yùn)行。

圖中用紅框標(biāo)示的就是在節(jié)點(diǎn)edgenode上，此時(shí) Pod 狀態(tài)已經(jīng)顯示為Terminating，表示 Pod 已經(jīng)終止服務(wù)。

接下來我們就分析下 Node 節(jié)點(diǎn)為什么不可用。

（1）首先從服務(wù)器物理環(huán)境排查，使用命令df -m查看磁盤的使用情況

或者直接使用命令free查看

磁盤并沒有溢出，也就是說物理空間足夠。

（2）接著我們?cè)俨榭聪?CPU 的使用率，命令為：top -c （大寫P可倒序）

CPU 的使用率也是在范圍內(nèi)，不管是在物理磁盤空間還是 CPU 性能，都沒有什么異常。那 Node 節(jié)點(diǎn)怎么就不可用了呢？而且服務(wù)器也是正常運(yùn)行中。

這似乎就有點(diǎn)為難了，這可咋整？

（3）不慌，還有一項(xiàng)可以作為排查的依據(jù)，那就是使用 kube 命令 describe 命令查看 Node 節(jié)點(diǎn)的詳細(xì)日志。完整命令為：

kubectl describe node <節(jié)點(diǎn)名稱>，那么圖中 Node 節(jié)點(diǎn)如圖：

哎呀，好像在這個(gè)日志里面看到了一些信息描述，首先我們先看第一句：Kubelet stoped posting node status，大致的意思是 Kubelet 停止發(fā)送 node 狀態(tài)了，再接著Kubelet never posted node status意思為再也收不到 node 狀態(tài)了。

查看下 Kubelet 是否在正常運(yùn)行，是使用命令：systemctl status kubelet，如果狀態(tài)為 Failed，那么是需要重啟下的。但如果是正常運(yùn)行，請(qǐng)繼續(xù)向下看。

分析一下好像有點(diǎn)眉目了，Kubelet 為什么要發(fā)送 node 節(jié)點(diǎn)的狀態(tài)呢？這就拋出了關(guān)于 Pod 的另一個(gè)知識(shí)點(diǎn)，請(qǐng)耐心向下看。

五，Pod 健康檢測(cè) PLEG

根據(jù)我們最后面分析的情形，似乎是 node 狀態(tài)再也沒有收到上報(bào)，導(dǎo)致 node 節(jié)點(diǎn)不可用，這就引申出關(guān)于 Pod 的生命健康周期。

PLEG全稱為：Pod Lifecycle Event Generator：Pod 生命周期事件生成器。

簡單理解就是根據(jù) Pod 事件級(jí)別來調(diào)整容器運(yùn)行時(shí)的狀態(tài)，并將其寫入 Pod 緩存中，來保持 Pod 的最新狀態(tài)。

在上述圖中，看出是 Kubelet 在檢測(cè) Pod 的健康狀態(tài)。Kubelet 是每個(gè)節(jié)點(diǎn)上的一個(gè)守護(hù)進(jìn)程，Kubelet 會(huì)定期去檢測(cè) Pod 的健康信息，先看一張官方圖。

PLEG去檢測(cè)運(yùn)行容器的狀態(tài)，而 kubelet 是通過輪詢機(jī)制去檢測(cè)的。

分析到這里，似乎有點(diǎn)方向了，導(dǎo)致 Node 節(jié)點(diǎn)變成 NotReady 狀態(tài)是和 Pod 的健康狀態(tài)檢測(cè)有關(guān)系，正是因?yàn)槌^默認(rèn)時(shí)間了，K8S 集群將 Node 節(jié)點(diǎn)停止服務(wù)了。

那為什么會(huì)沒有收到健康狀態(tài)上報(bào)呢？我們先查看下在 K8S 中默認(rèn)檢測(cè)的時(shí)間是多少。

在集群服務(wù)器是上，進(jìn)入目錄：/etc/kubernetes/manifests/kube-controller-manager.yaml，查看參數(shù)：

–node-monitor-grace-period=40s（node驅(qū)逐時(shí)間）

–node-monitor-period=5s（輪詢間隔時(shí)間）

上面兩項(xiàng)參數(shù)表示每隔 5 秒 kubelet 去檢測(cè) Pod 的健康狀態(tài)，如果在 40 秒后依然沒有檢測(cè)到 Pod 的健康狀態(tài)便將其置為 NotReady 狀態(tài)，5 分鐘后就將節(jié)點(diǎn)下所有的 Pod 進(jìn)行驅(qū)逐。

官方文檔中對(duì) Pod 驅(qū)逐策略進(jìn)行了簡單的描述，https://kubernetes.io/zh/docs/concepts/scheduling-eviction/eviction-policy/

kubelet 輪詢檢測(cè) Pod 的狀態(tài)其實(shí)是一種很消耗性能的操作，尤其隨著 Pod 容器的數(shù)量增加，對(duì)性能是一種嚴(yán)重的消耗。

在 GitHub 上的一位小哥對(duì)此也表示有自己的看法，原文鏈接為：

https://github.com/fabric8io/kansible/blob/master/vendor/k8s.io/kubernetes/docs/proposals/pod-lifecycle-event-generator.md

到這里我們分析的也差不多了，得到的結(jié)論為：

• Pod 數(shù)量的增加導(dǎo)致 Kubelet 輪詢對(duì)服務(wù)器的壓力增大，CPU 資源緊張

• Kubelet 輪詢?nèi)z測(cè) Pod 的狀態(tài)，就勢(shì)必受網(wǎng)絡(luò)的影響

• Node 節(jié)點(diǎn)物理硬件資源限制，無法承載較多的容器

而由于本人當(dāng)時(shí)硬件的限制，及網(wǎng)絡(luò)環(huán)境較差的前提下，所以只改了上面了兩項(xiàng)參數(shù)配置，延長 Kubelet 去輪詢檢測(cè) Pod 的健康狀態(tài)。實(shí)際效果也確實(shí)得到了改善。

// 需要重啟docker
sudo systemctl restart docker

// 需要重啟kubelet
sudo systemctl restart kubelet

但是如果條件允許的情況下，個(gè)人建議最好是從硬件方面優(yōu)化。

• 提高 Node 節(jié)點(diǎn)的物理資源

• 優(yōu)化 K8S 網(wǎng)絡(luò)環(huán)境

六，K8S 常用命令

最后分享一些常用的 K8S 命令

1，查詢?nèi)?pod（命名空間）

kubectl get pods -n <namespaces>

2，查詢?nèi)?node 節(jié)點(diǎn)

kubectl get nodes

3，查看 pod 詳細(xì)信息和日志

kubectl describe pod <podname> -n <namespaces>

kubectl logs -f <podname> -n <namespaces>

4，查看 pod-yaml 文件

kubectl get pod <podname> -n <namespaces> -o yaml

5，通過標(biāo)簽查詢 pod

kubectl get pod -l app=<labelname> -n <namespaces>

6，查詢 pod 具體某一條信息

kubectl -n <namespaces> get pods|grep <podname>|awk '{print $3}'

7，刪除 pod（或通過標(biāo)簽 -l app=）

kubectl delete pod <podname> -n <namespaces>

8，刪除 deployment

kubectl delete deployment <deploymentname> -n <namespaces>

9，強(qiáng)制刪除 pod

kubectl delete pod <podname> -n <namespaces> --force --grace-period=0

10，進(jìn)入 pod 容器

kubectl exec -it <podname> -n <namespaces> -- sh

11，給 node 打標(biāo)簽

kubectl label node <nodename> app=label

12，查看某一個(gè) node 標(biāo)簽

kubectl get node -l "<labelname>"

13，查看全部 node 標(biāo)簽

kubectl get node --show-labels=true

看完上述內(nèi)容，你們對(duì)K8S線上集群怎樣排查Node節(jié)點(diǎn)NotReady異常狀態(tài)有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。