1. Terminating
2. Pending
3. ContainerCreating / Waiting
4. CrashLoopBackOff
5. ImagePullBackOff

Terminating

有时候删去 Pod 一向卡在 Terminating 状况，一向删不掉，能够从以下方面进行排查。

剖析思路
一、首要咱们先了解下pod的删去流程：

• APIServer 收到删去 Pod 的恳求，Pod 被符号删去，处于 Terminating 状况。
• 节点上的 kubelet watch 到了 Pod 被删去，开端毁掉 Pod。
• Kubelet 调用运转时接口，整理相关容器。
• 一切容器毁掉成功，告诉 APIServer。
• APIServer 感知到 Pod 成功毁掉，查看 metadata 是否还有 finalizers，假如有就等候其它控制器整理完，假如没有就直接从 etcd 中删去 Pod 记载。

能够看出来，删去 Pod 流程涉及到的组件包括: APIServer, etcd, kubelet 与容器运转时 (如 docker、containerd)。
已然都能看到 Pod 卡在 Terminating 状况，阐明 APIServer 能正常呼应，也能正常从 etcd 中获取数据，一般不会有什么问题，有问题的当地首要便是节点上的操作。

二、排查思路
查看pod节点是否反常

# 查找 Terminating 的 Pod 及其地点 Node
$ kubectl get pod -o wide | grep Terminating
grafana-5d7ff8cb89-8gdtz                         1/1     Terminating   1          97d    10.10.7.150   172.20.32.15   <none>           <none>

# 查看 Node 是否反常
$ kubectl get node 172.20.32.15
NAME           STATUS      ROLES    AGE    VERSION
172.20.32.15   NotReady    <none>   182d   v1.20.6

# 查看 Node 相关事情
$ kubectl describe node 172.20.32.15

查看内核日志

dmesg
# journalctl -k

存在i文件特点
假如容器的镜像自身或许容器发动后写入的文件存在 "i" 文件特点，此文件就无法被修正删去，而删去 Pod 时会整理容器目录，但里边包括有不行删去的文件，就一向删不了，Pod 状况也将一向坚持 Terminating，kubelet 报错

Sep 27 14:37:21 VM_0_7_centos kubelet[14109]: E0927 14:37:21.922965   14109 remote_runtime.go:250] RemoveContainer "19d837c77a3c294052a99ff9347c520bc8acb7b8b9a9dc9fab281fc09df38257" from runtime service failed: rpc error: code = Unknown desc = failed to remove container "19d837c77a3c294052a99ff9347c520bc8acb7b8b9a9dc9fab281fc09df38257": Error response from daemon: container 19d837c77a3c294052a99ff9347c520bc8acb7b8b9a9dc9fab281fc09df38257: driver "overlay2" failed to remove root filesystem: remove /data/docker/overlay2/b1aea29c590aa9abda79f7cf3976422073fb3652757f0391db88534027546868/diff/usr/bin/bash: operation not permitted
Sep 27 14:37:21 VM_0_7_centos kubelet[14109]: E0927 14:37:21.923027   14109 kuberuntime_gc.go:126] Failed to remove container "19d837c77a3c294052a99ff9347c520bc8acb7b8b9a9dc9fab281fc09df38257": rpc error: code = Unknown desc = failed to remove container "19d837c77a3c294052a99ff9347c520bc8acb7b8b9a9dc9fab281fc09df38257": Error response from daemon: container 19d837c77a3c294052a99ff9347c520bc8acb7b8b9a9dc9fab281fc09df38257: driver "overlay2" failed to remove root filesystem: remove /data/docker/overlay2/b1aea29c590aa9abda79f7cf3976422073fb3652757f0391db88534027546868/diff/usr/bin/bash: operation not permitted

docker 17 的 bug
docker hang 住，没有任何呼应，看 event:

Warning FailedSync 3m (x408 over 1h) kubelet, 10.179.80.31 error determining status: rpc error: code = DeadlineExceeded desc = context deadline exceeded

mount 的目录被其它进程占用
dockerd 报错 device or resource busy:

May 09 09:55:12 VM_0_21_centos dockerd[6540]: time="2020-05-09T09:55:12.774467604+08:00" level=error msg="Handler for DELETE /v1.38/containers/b62c3796ea2ed5a0bd0eeed0e8f041d12e430a99469dd2ced6f94df911e35905 returned error: container b62c3796ea2ed5a0bd0eeed0e8f041d12e430a99469dd2ced6f94df911e35905: driver \"overlay2\" failed to remove root filesystem: remove /data/docker/overlay2/8bde3ec18c5a6915f40dd8adc3b2f296c1e40cc1b2885db4aee0a627ff89ef59/merged: device or resource busy"

查找还有谁在"强占"此目录:
$ grep 8bde3ec18c5a6915f40dd8adc3b2f296c1e40cc1b2885db4aee0a627ff89ef59 /proc/*/mountinfo
/proc/27187/mountinfo:4500 4415 0:898 / /var/lib/docker/overlay2/8bde3ec18c5a6915f40dd8adc3b2f296c1e40cc1b2885db4aee0a627ff89ef59/merged rw,relatime - overlay overlay rw,lowerdir=/data/docker/overlay2/l/DNQH6VPJHFFANI36UDKS262BZK:/data/docker/overlay2/l/OAYZKUKWNH7GPT4K5MFI6B7OE5:/data/docker/overlay2/l/ANQD5O27DRMTZJG7CBHWUA65YT:/data/docker/overlay2/l/G4HYAKVIRVUXB6YOXRTBYUDVB3:/data/docker/overlay2/l/IRGHNAKBHJUOKGLQBFBQTYFCFU:/data/docker/overlay2/l/6QG67JLGKMFXGVB5VCBG2VYWPI:/data/docker/overlay2/l/O3X5VFRX2AO4USEP2ZOVNLL4ZK:/data/docker/overlay2/l/H5Q5QE6DMWWI75ALCIHARBA5CD:/data/docker/overlay2/l/LFISJNWBKSRTYBVBPU6PH3YAAZ:/data/docker/overlay2/l/JSF6H5MHJEC4VVAYOF5PYIMIBQ:/data/docker/overlay2/l/7D2F45I5MF2EHDOARROYPXCWHZ:/data/docker/overlay2/l/OUJDAGNIZXVBKBWNYCAUI5YSGG:/data/docker/overlay2/l/KZLUO6P3DBNHNUH2SNKPTFZOL7:/data/docker/overlay2/l/O2BPSFNCVXTE4ZIWGYSRPKAGU4,upperdir=/data/docker/overlay2/8bde3ec18c5a6915f40dd8adc3b2f296c1e40cc1b2885db4aee0a627ff89ef59/diff,workdir=/data/docker/overlay2/8bde3ec18c5a6915f40dd8adc3b2f296c1e40cc1b2885db4aee0a627ff89ef59/work
/proc/27187/mountinfo:4688 4562 0:898 / /var/lib/docker/overlay2/81c322896bb06149c16786dc33c83108c871bb368691f741a1e3a9bfc0a56ab2/merged/data/docker/overlay2/8bde3ec18c5a6915f40dd8adc3b2f296c1e40cc1b2885db4aee0a627ff89ef59/merged rw,relatime - overlay overlay rw,lowerdir=/data/docker/overlay2/l/DNQH6VPJHFFANI36UDKS262BZK:/data/docker/overlay2/l/OAYZKUKWNH7GPT4K5MFI6B7OE5:/data/docker/overlay2/l/ANQD5O27DRMTZJG7CBHWUA65YT:/data/docker/overlay2/l/G4HYAKVIRVUXB6YOXRTBYUDVB3:/data/docker/overlay2/l/IRGHNAKBHJUOKGLQBFBQTYFCFU:/data/docker/overlay2/l/6QG67JLGKMFXGVB5VCBG2VYWPI:/data/docker/overlay2/l/O3X5VFRX2AO4USEP2ZOVNLL4ZK:/data/docker/overlay2/l/H5Q5QE6DMWWI75ALCIHARBA5CD:/data/docker/overlay2/l/LFISJNWBKSRTYBVBPU6PH3YAAZ:/data/docker/overlay2/l/JSF6H5MHJEC4VVAYOF5PYIMIBQ:/data/docker/overlay2/l/7D2F45I5MF2EHDOARROYPXCWHZ:/data/docker/overlay2/l/OUJDAGNIZXVBKBWNYCAUI5YSGG:/data/docker/overlay2/l/KZLUO6P3DBNHNUH2SNKPTFZOL7:/data/docker/overlay2/l/O2BPSFNCVXTE4ZIWGYSRPKAGU4,upperdir=/data/docker/overlay2/8bde3ec18c5a6915f40dd8adc3b2f296c1e40cc1b2885db4aee0a627ff89ef59/diff,workdir=/data/docker/overlay2/8bde3ec18c5a6915f40dd8adc3b2f296c1e40cc1b2885db4aee0a627ff89ef59/work

找到进程号后查看此进程更多详细信息:
ps -f 27187

Pending

Pod 一向 Pending 一般是调度失利，调度失利的原因一般包括以下内容:
一、节点没有满意资源分配pod

 kubectl describe node <node-name>

二、不满意节点亲和
假如 Pod 包括 affinity（亲和性）的装备，调度器依据调度算法也或许算出没有满意条件的 Node，然后无法调度。affinity 有以下几类:
nodeAffinity: 节点亲和性，能够看成是增强版的 nodeSelector，用于约束 Pod 只允许被调度到某一部分 Node。
podAffinity: Pod亲和性，用于将一些有相关的 Pod 调度到同一个当地，同一个当地能够是指同一个节点或同一个可用区的节点等。
podAntiAffinity: Pod 反亲和性，用于防止将某一类 Pod 调度到同一个当地防止单点故障，比方将集群 DNS 服务的 Pod 副本都调度到不同节点，防止一个节点挂了形成整个集群 DNS 解析失利，使得事务中止

三、污点
节点假如被打上了污点，Pod 必需求忍受污点才干调度上去:

0/5 nodes are available: 3 node(s) had taints that the pod didn't tolerate, 2 Insufficient memory.

经过 describe node 能够看下 Node 有哪些 Taints:

$ kubectl describe nodes host1
...
Taints:             special=true:NoSchedule
...

假如期望 Pod 能够调度上去，一般解决方法有两个:
1.删去污点

kubectl taint nodes host1 special-

2.给pod加上污点忍受

tolerations:
- key: "special"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"

四、kube-scheduler没有正常运转
查看 maser 上的 kube-scheduler 是否运转正常，反常的话能够测验重启暂时康复。

ContainerCreating-Waiting

一、镜像问题

二、configmap/secret挂载问题

三、limit 设置太小或许单位不对

四、存在同名容器

CrashLoopBackOff

Pod 假如处于 CrashLoopBackOff 状况阐明之前是发动了，仅仅又反常退出了。

一、容器进程自动退出
假如是容器进程自动退出，退出状况码一般在 0-128 之间，除了或许是事务程序 BUG，还有其它许多或许原因。内部程序溃散或许依靠缺失等。

二、体系 OOM
假如是体系oom溢出，容器状况码是137，表明被 SIGKILL 信号杀死，一起内核会报错: Out of memory: Kill process。大概率是节点上布置了其它非 K8S 办理的进程耗费了比较多的内存

三、cgroup OOM
假如是 cgrou OOM 杀掉的进程，从 Pod 事情的下 Reason 能够看到是 OOMKilled，阐明容器实践占用的内存超越 limit 了，一起内核日志会报: Memory cgroup out of memory。 能够依据需求调整下 limit。

四、探针问题，健康查看失利
Liveness 和 Readiness 探针装备不正确，导致容器不断重启。

ImagePullBackOff

一、私有镜像库房认证失利
库房需求认证，装备的 Secret 不存在或许有误都会认证失利，能够先在调度的Node节点中履行docker pull指令，验证镜像是否能够拉取

二、镜像文件损坏
假如 push 的镜像文件损坏了，下载下来也用不了，需求从头 push 镜像文件