人生苦短，我用k8s--------------k8s实战排障思路

K8S是一个开源的，用于管理云平台中多个主机上的容器化应用，Kubernetes的目标是让部署容器化变得简单并且高效

文章目录

• • 1、排障基本命令
  • 2、处于Pending状态
  • 2、Pod 一直处于 Waiting 或 ContainerCreating 状态
  • 3、Pod 处于 ImagePullBackOff 状态
  • 4、Pod 一直处于 CrashLoopBackOff 状态
  • 5、Pod 处于 Error 状态
  • 6、集群处于 NotReady状态

1、排障基本命令

一般来说pod处于异常状态，都可以执行以下命令查看pod状态 kubectl get pod -o yaml #查看pod配置 kubcctl get pod -o wide #查看pod运行节点等信息 kubectl describe pod #查看pod事件 kubectl logs #查看pod日志

2、处于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解析失败，使得业务中断

2、Pod 一直处于 Waiting 或 ContainerCreating 状态

首先还是通过以下命令查看： kubectl describe pod

可能原因：

1，镜像拉取失败，比如配置了镜像错误、Kubelet 无法访问镜像、私有镜像的密钥配置错误、镜像太大，拉取超时等

2，CNI 网络错误，一般需要检查 CNI 网络插件的配置，比如无法配置 Pod 、无法分配 IP 地址

3，容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数

3、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

4、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系统日志

5、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

6、集群处于 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，磁盘空间不⾜：清理磁盘空间，⽐如镜像、⽂件等