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 docker
2、Dockerd重启后，登录节点执行以下命令，再次查看Dockerd状态是否恢复正常。
systemctl status docker
3、若Dockerd重启后状态仍异常，请登录节点执行以下命令查看Dockerd日志。
journalctl -u docker
Containerd异常处理-RuntimeOffline
问题原因
通常是Containerd配置异常、进程负载异常、节点负载异常等原因导致。
问题现象
1、Containerd状态为inactive。
2、节点状态中RuntimeOffline为True。
解决方案
1、执行如下命令重启Containerd。
systemctl restart containerd
2、Containerd重启后，登录节点执行以下命令，再次查看Containerd状态是否恢复正常。
systemctl status containerd
3、若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 -5
3、根据进程号找到对应进程和所属的Pod，分析占用PID过多的原因并优化对应代码。
4、降低节点的负载。
5、如需重启节点，可尝试重启异常节点。
