【云原生之K8s】 K8s之pod排障思路
目录
一、排障基本命令
二、Pod处于Pending状态
三、Pod 一直处于 Waiting 或 ContainerCreating 状态
四、Pod 处于 ImagePullBackOff 状态
五、Pod 一直处于 CrashLoopBackOff 状态
六、Pod 处于 Error 状态
七、集群处于NotReady状态
一、排障基本命令
一般来说pod处于异常状态，都可以执行以下命令查看pod状态
kubectl get pod -o yaml #查看pod配置
kubcctl get pod -o wide #查看pod运行节点等信息
kubectl describe pod #查看pod事件
kubectl logs #查看pod日志
二、Pod处于Pending状态
pending说明pod还没调度到某个Node上面
可以通过以下命令查看
kubectl describe pod
可能原因：
1，资源不足，集群内所有的 Node 都不满足该 Pod 请求的CPU、内存或者临时存储空间等资源。解决方法是降低资源使用率，可以删除不用的Pod或者添加新的Node节点
kubectl describe node #可以查看node资源情况
2，HostPort 端口已被占用，通常推荐使用 Service 对外开放服务端口
3，不满足 nodeSelector
如果Pod包含nodeSelector 指定了节点需要包含的 label，调度器将只会考虑将 Pod 调度到包含这些 label的Node上，如果没有 Node 有这些 label或者有这些 label的 Node 其它条件不满足也将会无法调度
4，不满足 affinity
nodeAffinity: 节点亲和性，可以看成是增强版的 nodeSelector，用于限制 Pod 只允许被调度到某一部分 Node
podAffinity: Pod亲和性，用于将一些有关联的Pod调度到同一个地方，可以是指同一个节点或同一个可用区的节点等
podAntiAffinity: Pod反亲和性，用于避免将某一类Pod调度到同一个地方避免单点故障，比如将集群 DNS 服务的 Pod 副本都调度到不同节点，避免一个节点挂了造成整个集群DNS解析失败，使得业务中断
5，节点没有开启
三、Pod 一直处于 Waiting 或 ContainerCreating 状态
首先还是通过以下命令查看：
kubectl describe pod可能原因：
① 镜像拉取失败，比如配置了镜像错误、Kubelet 无法访问镜像、私有镜像的密钥配置错误、镜像太大，拉取超时等
② CNI 网络错误，一般需要检查 CNI 网络插件的配置，比如无法配置 Pod 、无法分配 IP 地址
③ 容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数
四、Pod 处于 ImagePullBackOff 状态
这通常是镜像名称配置错误等导致镜像无法拉取。使用 docker pull 来验证镜像是否可以正常拉取。
Pod 处于 Terminating 或 Unknown 状态
Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod，而是将其标记为 Terminating 或 Unknown 状态想要删除这些状态的 Pod 有三种方法
1，从集群中删除该Node。使用公有云时，kube-controller-manager 会在 VM 删除后自动删除对应的 Node。
而在物理机部署的集群中，需要管理员手动删除 Node（如 kubectl delete node 。2，Node恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态，进而再决定删除或者继续运行这些 Pod。
3，用户强制删除。用户可以执行 kubectl delete pods --grace-period=0 --force 强制删除 Pod。除非明确知道 Pod
的确处于停止状态（比如 Node 所在 VM 或物理机已经关机），否则不建议使用该方法。特别是StatefulSet 管理的 Pod，强制删除容易导致脑裂或者数据丢失等问题4，处于 Terminating 状态的 Pod 在 Kubelet 恢复正常运行后一般会自动删除。但有时也会出现无法删除的情况，并且通过
kubectl delete pods --grace-period=0 --force 也无法强制删除。此时一般是由于 finalizers 导致的，通过kubectl edit 将 finalizers 删除即可解决。5，有时会发生修改静态 Pod 的 Manifest 后未自动创建新 Pod 的情景，此时一个简单的修复方法是重启 Kubelet
五、Pod 一直处于 CrashLoopBackOff 状态
CrashLoopBackOff 状态说明容器曾经启动了，但又异常退出了。此时 Pod 的 Restart (重启次数) 通常是大于 0 的，可以先查看一下容器的日志
可能是： 容器进程退出，健康检查失败退出等
方法有：
kubectl get pod -o yaml
kubectl describe pod
kubectl logs
kubectl exec -it bash #进去容器查看
kubectl get pod -o wide #查看pod运行在哪个node上，去查看node系统日志
六、Pod 处于 Error 状态
Error 状态说明 Pod 启动过程中发生了错误
可能原因：
1，依赖的 ConfigMap、Secret 或者 PV 等不存在
2，请求的资源超过了管理员设置的限制，比如超过了 LimitRange 等
3，容器无权操作集群内的资源，比如开启 RBAC 后，需要为 ServiceAccount 配置角色绑定
Pod 处于 Terminating 或 Unknown 状态
Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod，而是将其标记为 Terminating 或 Unknown 状态想要删除这些状态的 Pod 有三种方法：
1，从集群中删除该Node。使用公有云时，kube-controller-manager 会在 VM 删除后自动删除对应的 Node。而在物理机部署的集群中，需要管理员手动删除 Node（如 kubectl delete node 。
2，Node恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态，进而再决定删除或者继续运行这些 Pod。
3，用户强制删除。用户可以执行 kubectl delete pods --grace-period=0 --force 强制删除 Pod。除非明确知道 Pod 的
确处于停止状态（比如 Node 所在 VM 或物理机已经关机），否则不建议使用该方法。特别是StatefulSet 管理的 Pod，强制删除容易导致
脑裂或者数据丢失等问题4，处于 Terminating 状态的 Pod 在 Kubelet 恢复正常运行后一般会自动删除。但有时也会出现无法删除的情况，并且通过
kubectl delete pods --grace-period=0 --force 也无法强制删除。此时一般是由于 finalizers 导致的，
通过 kubectl edit 将 finalizers 删除即可解决。
5，有时会发生修改静态 Pod 的 Manifest 后未自动创建新 Pod 的情景，此时一个简单的修复方法是重启 Kubelet
七、集群处于NotReady状态
kubectl get nodes #查看node的状态，确认其本身是否Ready
kubectl describe node
kubectl logs -n kube-system #查看k8s组件⽇志
journalctl -l -u kubelet #查看kubelet⽇志
Node 处于 NotReady 状态，⼤部分是由于 PLEG（Pod Lifecycle Event Generator）问题导致
的 社区 issue ⽬前还处于未解决状态
常⻅的问题及修复⽅法为：
1，Kubelet 未启动或者异常挂起：重新启动Kubelet
2，CNI ⽹络插件未部署：部署CNI插件
3，Docker ：重启Docker
4，磁盘空间不⾜：清理磁盘空间，⽐如镜像、⽂件等