Kubelet異常處理
問題原因
通常是Kubelet進程異常、運行時異常、Kubelet配置有誤等原因導致。
問題現象
Kubelet狀態為inactive。
解決方案
1、執行 systemctl restart kubelet 命令重啟Kubelet。重啟Kubelet不會影響運行中的容器。
2、Kubelet重啟后，登錄節點執行 systemctl status kubelet命令，再次查看kubelet狀態是否恢復正常。
3、若Kubelet重啟后狀態仍異常，請登錄節點執行 journalctl -u kubelet 命令查看Kubelet日志。
若日志中有明確的異常信息，請根據異常關鍵字進行排查。
若確認是Kubelet配置異常，請執行如下命令修改Kubelet配置。
vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf #修改Kubelet配置。
systemctl daemon-reload;systemctl restart kubelet #重新加載配置并重啟Kubelet。Dockerd異常處理-RuntimeOffline
問題原因
通常是Dockerd配置異常、進程負載異常、節點負載異常等原因導致。
問題現象
1、Dockerd狀態為inactive。
2、Dockerd狀態為active(running)，但未正常工作，導致節點異常。通常有docker ps、docker exec等命令執行失敗的現象。
3、節點狀態中RuntimeOffline為True。
解決方案
1、執行如下命令重啟Dockerd。
systemctl restart docker2、Dockerd重啟后，登錄節點執行以下命令，再次查看Dockerd狀態是否恢復正常。
systemctl status docker3、若Dockerd重啟后狀態仍異常，請登錄節點執行以下命令查看Dockerd日志。
journalctl -u dockerContainerd異常處理-RuntimeOffline
問題原因
通常是Containerd配置異常、進程負載異常、節點負載異常等原因導致。
問題現象
1、Containerd狀態為inactive。
2、節點狀態中RuntimeOffline為True。
解決方案
1、執行如下命令重啟Containerd。
systemctl restart containerd2、Containerd重啟后，登錄節點執行以下命令，再次查看Containerd狀態是否恢復正常。
systemctl status containerd3、若Containerd重啟后狀態仍異常，請登錄節點執行以下命令查看Containerd日志。
journalctl -u containerd節點PLEG異常-PLEG is not healthy
問題原因
Pod生命周期事件生成器PLEG（Pod Lifecycle Event Generator）會記錄Pod生命周期中的各種事件，如容器的啟動、終止等。PLEG is not healthy異常通常是由于節點上的運行時進程異常或者節點Systemd版本缺陷導致。
問題現象
1、節點狀態NotReady。
2、在Kubelet日志中，可看到如下日志。
I0729 11:20:59.245243 9575 kubelet.go:1823] skipping pod synchronization - PLEG is not healthy: pleg was last seen active 3m57.138893648s ago; threshold is 3m0s.解決方案
1、依次重啟節點關鍵組件Dockerd、Contatinerd、Kubelet，重啟后查看節點是否恢復正常。
2、若節點關鍵組件重啟后節點仍未恢復正常，可嘗試重啟異常節點。
節點調度資源不足
問題原因
通常是集群中的節點資源不足導致。
問題現象
當集群中的節點調度資源不足時，會導致Pod調度失敗，出現以下常見錯誤信息：
1、集群CPU資源不足：0/2 nodes are available: 2 Insufficient cpu
2、集群內存資源不足：0/2 nodes are available: 2 Insufficient memory
3、集群臨時存儲不足：0/2 nodes are available: 2 Insufficient ephemeral-storage
其中調度器判定節點資源不足的計算方式為：
1、集群節點CPU資源不足的判定方式：當前Pod請求的CPU資源總量>（節點可分配的CPU資源總量-節點已分配的CPU資源總量）
2、集群節點內存資源不足的判定方式：當前Pod請求的內存資源總量>（節點可分配的內存資源總量-節點已分配的內存資源總量）
3、集群節點臨時存儲不足的判定方式：當前Pod請求的臨時存儲總量>（節點可分配的臨時存儲總量-節點已分配的臨時存儲總量）
如果當前Pod請求的資源總量大于節點可分配的資源總量減去節點已分配的資源總量，Pod就不會調度到當前節點。
執行以下命令，查看節點的資源分配信息：
kubectl describe node [$nodeName]解決方案
當節點調度資源不足時，需降低節點負載，方法如下：
1、刪除或減少不必要的Pod，降低節點的負載。
2、根據自身業務情況，限制Pod的資源配置。
3、在集群中添加新的節點。
4、為節點進行升配。
節點CPU不足
問題原因
通常是節點上的容器占用CPU過多導致節點的CPU不足。
問題現象
當節點CPU不足時，可能會導致節點狀態異常。
解決方案
1、通過節點的監控查看CPU增長曲線，確認異常出現時間點，檢查節點上的進程是否存在CPU占用過高的現象。
2、降低節點的負載。
3、如需重啟節點，可嘗試重啟異常節點。
節點內存不足-MemoryPressure
問題原因
通常是節點上的容器占用內存過多導致節點的內存不足。
問題現象
1、當節點的可用內存低于memory.available配置項時，則節點狀態中MemoryPressure為True，同時該節點上的容器被驅逐。
2、當節點內存不足時，會有以下常見錯誤信息：
2.1 節點狀態中MemoryPressure為True。
2.2 當節點上的容器被驅逐時：
2.2.1 在被驅逐的容器事件中可看到關鍵字The node was low on resource: memory。
2.2.2 在節點事件中可看到關鍵字attempting to reclaim memory。
2.2.3 可能會導致系統OOM異常，當出現系統OOM異常時，節點事件中可看到關鍵字System OOM。
解決方案
1、通過節點的監控查看內存增長曲線，確認異常出現時間點，檢查節點上的進程是否存在內存泄露現象。
2、降低節點的負載。
3、如需重啟節點，可嘗試重啟異常節點。
節點索引節點不足-InodesPressure
問題原因
通常是節點上的容器占用索引節點過多導致節點的索引節點不足。
問題現象
1、當節點的可用索引節點低于inodesFree配置項時，則節點狀態中InodesPressure為True，同時該節點上的容器被驅逐。
2、當節點索引點不足時，通常會有以下常見錯誤信息：
2.1 節點狀態中InodesPressure為True。
2.2 當節點上的容器被驅逐時：
2.2.1 被驅逐的容器事件中可看到關鍵字The node was low on resource: inodes。
2.2.2 節點事件中可看到關鍵字attempting to reclaim inodes。
解決方案
通過節點的監控查看索引節點增長曲線，確認異常出現時間點，檢查節點上的進程是否存在占用索引節點過多現象。
節點磁盤空間不足-DiskPressure
問題原因
通常是節點上的容器占用磁盤過多、鏡像文件過大導致節點的磁盤空間不足。
問題現象
1、當節點的可用磁盤空間低于imagefs.available配置項時，則節點狀態中DiskPressure為True。
2、當可用磁盤空間低于nodefs.available配置項時，則該節點上的容器全部被驅逐。
3、當磁盤空間不足時，通常會有以下常見錯誤信息：
3.1 節點狀態中DiskPressure為True。
3.2 當觸發鏡像回收策略后，磁盤空間仍然不足以達到健康閾值（默認為80%），在節點事件中可看到關鍵字failed to garbage collect required amount of images。
3.3 當節點上的容器被驅逐時：
3.3.1 被驅逐的容器事件中可看到關鍵字The node was low on resource: [DiskPressure]。
3.3.2 節點事件中可看到關鍵字attempting to reclaim ephemeral-storage或attempting to reclaim nodefs。
解決方案
1、通過節點的監控查看磁盤增長曲線，確認異常出現時間點，檢查節點上的進程是否存在占用磁盤空間過多的現象。
2、若有大量文件在磁盤上未清理，請清理文件。
3、根據自身業務情況，限制Pod的ephemeral-storage資源配置。
4、建議使用云存儲產品，盡量避免使用HostPath數據卷。
5、節點磁盤擴容。
6、降低節點的負載。
節點PID不足-NodePIDPressure
問題原因
通常是節點上的容器占用PID過多導致節點的PID不足。
問題現象
當節點的可用PID低于pid.available配置項時，則節點狀態中NodePIDPressure為True，同時該節點上的容器被驅逐。
解決方案
1、執行如下命令，查看節點的最大PID數和節點當前的最大PID。
sysctl kernel.pid_max #查看最大PID數。
ps -eLf|awk '{print $2}' | sort -rn| head -n 1 #查看當前的最大PID。2、執行如下命令，查看占用PID最多的前5個進程。
ps -elT | awk '{print $4}' | sort | uniq -c | sort -k1 -g | tail -53、根據進程號找到對應進程和所屬的Pod，分析占用PID過多的原因并優化對應代碼。
4、降低節點的負載。
5、如需重啟節點，可嘗試重啟異常節點。
