一、集群方面

1、 pod在部分节点无法启动
1> cni0的网段与网络插件为node分配的 subnet地址段不同导致pod启动失败

报错信息: failed to set bridge addr: “cni0” already has an IP address different from 10.42.0.10/16
排查思路: 登录pod所在节点查看cni0和k8s为node分配的subnet网段是否一致
常见原因: 服务器节点网络插件文件丢失、
解决办法:
第一种: 删除该节点的cni 0网桥,重建节点cni 0网桥, 网络插件会重新创建cni 网桥, 建议先把节点设置为不可调度,并驱逐已有pod

ip link set cni0 down
brctl delbr cni0

第二种: 修改现有cni0的IP段修改与节点subnet网段保持一致

2 > node节点加入新集群前没有清理原有集群cni网桥信息, 导致该节点pod一直是creating状态

报错信息: networkPlugin cni failed to set up pod “nginx-test” network: failed to set bridge addr: “cni0” already has an IP address different from 10.42.0.10/16
解决办法: 删除该节点的cni 0网桥,重建节点cni 0网桥, 建议先驱逐pod

rm -rf /var/lib/cni/
rm -rf /etc/cni/
ifconfig cni0 down
ip link delete cni0
3 > 使用storageclass,创建pod, 由于被调度的node节点没有安装对应客户端导致pv无法创建, pod一直creating

报错信息: timeout expired waiting for volumes to attach/mount for pod “volume-test-xxxxx” / “fail” . list of unattached/unmounted volumes=[test-xxx]
排查方法: describe pvc
解决方法: 登录到对应节点安装相应客户端,比如ceph类型storageclass安装ceph-common, nfs类型storageclass安装nfs-common

4 > 物理节点docker使用的磁盘使用率100%

报错信息: no space left on device
排查方法: describe pod, 登录节点查看实际使用率, 查看节点内的大文件
解决方法:
第一种: 清理文件
常见的问题是由于容器日志大小和数量没有限制导致容器日志占满磁盘, 或者是没有被使用的容器镜像占用磁盘空间

ls -lh $(find /var/lib/docker/containers/ -name *-json.log)|grep G

cat /dev/null /var/lib/docker/containers/container-id/container-id-json.log
直接删除并不会释放磁盘使用率,原因是进程在使用这个文件,磁盘空间不会被释放

或者在/etc/docker/daemon.json内添加以下配置,限制容器日志大小和数量, 需要重启docker
"log-opts": {"max-size":"500m", "max-file":"3"}

第二种: 扩容硬盘或者修改容器目录

5 > limints资源配置太小导致pod一直被删除重建

报错信息: running exec setns process for init caused “signal: killed”": unknown
排查方法: describe pod
解决方法: 增加limits的资源, 或者排查pod资源使用率高的原因合理分配资源

2、 pod状态pending

1> 节点资源不满足limits的配置,比如cpu、memory、gpu;
报错信息: 0/4 nodes are available: 2 Insufficient cpu, 3 Insufficient memory.
排查方法: describe pod, 登录节点查看实际使用率
解决方法: 减少limits的资源; 增加node节点资源配置; nodeSelector原因可以根据实际情况修改pod的nodeSelector或者给node打上对应的label

2> pod无法容忍某些node的污点,导致pod处于pending状态
排查方法: describe pod, describe node
解决方法: pod容忍污点、node去掉污点, 修改配置调度到其他节点

3>pod配置nodeSelector, affinity
排查方法: describe pod, describe node
解决方法: pod取消nodeSelector; node打上pod需要的lable; 亲和性相关问题修改亲和性配置,或者修改集群配置满足亲和性配置
affinity包括
nodeAffinity: 节点亲和性
podAffinity: Pod 亲和性
podAntiAffinity: Pod 反亲和性

4>scaduler状态异常

3、 pod状态ImagePullBackOff

1>节点访问定义的共有docker仓库镜像超时
排查方法: describe pod, 在对应节点pull
解决办法:
01、dockerhub仓库配置registry-mirrors,
02、其他公共仓库比如gcr下载到本地配置imagePullPolicy: IfNotPresent, 或者传入到本地镜像仓库配置hosts解析,也可以修改yaml内镜像仓库地址
03、香港或者其他网络环境比较好的机器上配置代理仓库

2>https类型 resitry，没有给节点添加 ca 证书或者配置仓库可信, 以下两种方法都需要重启docker, 建议在/etc/docker/daemon.json加入live-restore字段
解决办法:
01、非https仓库需要在/etc/docker/daemon.json中添加insecure-registries字段
02、自签https证书需要在节点的/etc/docker/certs.d/registry:port/ca.crt添加证书

3> 私有镜像仓库认证失败
解决办法:
01、使用正常仓库授权用户创建secret, yaml中配置imagePullSecret
02、修改仓库访问权限为共有

4> 同时启动的服务较多,kubelet和docker默认下载并发不能满足需求
解决办法:
01、增加下载并发数量
kubelet内添加–serialize-image-pulls参数
/etc/docker/daemon.json内添加max-concurrent-downloads参数

02、仓库或者网络瓶颈
集群网络瓶颈: 增大入口带宽, 或者使用代理仓库预下载到本地代理仓库
仓库瓶颈: 增大仓库出口带宽, 或者使用代理仓库或者使用Dragonfly 等缓存方式分发镜像

5> 下载镜像不存在
排查方法: describe pod 或者docker pull 镜像
解决办法: 确认是否是镜像地址或者tag写错, 改为正常的就可以了

4、 pod状态 ImageInspectError

原因: 镜像文件损坏了，可以尝试删除损坏的镜像重新拉取

5、 pod状态CrashLoopBackOff

原因: 状态说明pod之前是启动了，又异常退出了
01>容器进程主动退出:
原因: 启动参数不满足程序要求或者依赖外部服务不能正常调用, 或者是业务程序本身bug
解决办法: 修改pod启动参数为sleep 这种方式, 进入pod 手动指定启动命令看是否正常
02>系统 OOM, Pod 中容器退出状态码是 137
原因: 节点预留资源不合理, 或者节点上运行了非k8s集群的服务
解决办法: 保证 节点预留资源合理的情况下增加节点
03>cgroup OOM
原因: pod资源使用率超过limits限制 , describe pod可以看到OOMKilled，说明容器实际占用的内存超过 limit 了
解决办法: 增加limits内cpu和内存等资源配额
04>服务启动实际较长, 健康检查时间较短
原因: 应用因为资源或者网络等原因导致启动较慢, 而健康检查的时间较短pod未真正运行就被重启
解决办法: 增加健康检查的时间和时间间隔
字段:
initialDelaySeconds(首次健康检查时间)
periodSeconds (检查时间间隔)

6、 pod状态error

排查思路: describe pod 或者kubectl logs
原因: Pod 启动过程中发生了错误
01> 依赖的 ConfigMap、Secret 或者 PV 等不存在
02>请求的资源超过了管理员设置的限制，比如超过了 LimitRange
03>违反集群的安全策略，比如违反了 PodSecurityPolicy 等
04>容器无权操作集群内的资源，比如开启 RBAC 后，需要为 ServiceAccount 配置角色绑定

7、 pod状态Terminating

排查思路: describe pod
原因1: docker 的数据目录所在磁盘被写满, kubelet 删除容器没反应,
排查思路: describe pod
报错信息: Killing container with id docker://apigateway:Need to kill Pod
解决办法: 登录pod所在节点, 清理docker数据目录内文件,比如docker日志文件等, 如果docker数据目录是系统盘, 建议驱逐节点上的pod, 重启节点

原因2: 存在 “i” 文件属性
排查思路: describe pod
临时解决办法: 登录pod所在node执行 chattr -i /var/lib/docker/overlay2/xxxx

8、 pod状态Unknown

本质原因: 通常是节点失联，kubelet没有上报状态给 apiserver, controller-manager 认为节点失联并将其状态置为 Unknown

常见原因: kubelet 服务挂了、节点高负载导致无法上报 、节点宕机、节点被关机、网络不通

9、 pod状态Evicted

常见原因: 节点处于资源压力, 一般是内存或者磁盘压力比较大
排查思路: describe pod

10、pod 状态ContainerCreating

排查思路: describe pod
报错信息：

Multi-Attach error for volume "pvc-xxxxxx" Volume is already used by pod(s)

原因： rbd image仍然有watcher存在，导致其他node不能正常mount(map) image
解决办法：

kubectl  describe pv pvc-xxx｜grep RBDImage:
rbd -p poolxxx status RBDImage:id
获取到watcher信息登陆到对应节点进行rbd umap，如果节点故障直接关机即可，重新map需要等待一段时间