kubernetes错误 pod故障总结

万能解决办法： 重启大法好（生产环境三思而后行）

• 重启容器
• 重启kubelet
• 重启systemd
• 重启机器

一般来说，无论 Pod 处于什么异常状态，都可以执行以下命令来查看 Pod 的状态

kubectl get pod <pod-name> -o yaml 查看 Pod 的配置是否正确
kubectl describe pod <pod-name> 查看 Pod 的事件
kubectl logs <pod-name> [-c <container-name>] 查看容器日志

这些事件和日志通常都会有助于排查 Pod 发生的问题。

Pod 一直处于 Pending 状态

Pending。这个状态意味着，Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。但是，这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如，调度不成功
可以通过 kubectl describe pod 命令查看到当前 Pod 的事件，进而判断为什么没有调度。可能的原因包括

资源不足，集群内所有的 Node 都不满足该 Pod 请求的 CPU、内存、GPU 等资源
HostPort 已被占用，通常推荐使用 Service 对外开放服务端口

Pod 一直处于 Waiting 或 ContainerCreating 状态

首先还是通过 kubectl describe pod 命令查看到当前 Pod 的事件。可能的原因包括

1、镜像拉取失败，比如
配置了错误的镜像
Kubelet 无法访问镜像（国内环境访问 gcr.io 需要特殊处理）
私有镜像的密钥配置错误
镜像太大，拉取超时（可以适当调整 kubelet 的 --image-pull-progress-deadline 和 --runtime-request-timeout 选项）

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

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

4、Failed create pod sandbox，查看kubelet日志，原因可能是
磁盘坏道（input/output error）

Pod 处于 ImagePullBackOff 状态

这通常是镜像名称配置错误或者私有镜像的密钥配置错误导致。这种情况可以使用 docker pull 来验证镜像是否可以正常拉取。

如果是私有镜像，需要首先创建一个 docker-registry 类型的 Secret

kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL

然后在容器中引用这个 Secret

spec:
  containers:
  - name: private-reg-container
    image: <your-private-image>
  imagePullSecrets:
  - name: my-secret

Pod 一直处于 CrashLoopBackOff 状态

CrashLoopBackOff 状态说明容器曾经启动了，但又异常退出了。此时可以先查看一下容器的日志

kubectl logs
kubectl logs --previous
这里可以发现一些容器退出的原因，比如

容器进程退出
健康检查失败退出
此时如果还未发现线索，还可以到容器内执行命令来进一步查看退出原因

kubectl exec cassandra – cat /var/log/cassandra/system.log
如果还是没有线索，那就需要 SSH 登录该 Pod 所在的 Node 上，查看 Kubelet 或者 Docker 的日志进一步排查了

查询 Node
kubectl get pod -o wide

Pod 处于 Error 状态

通常处于 Error 状态说明 Pod 启动过程中发生了错误。常见的原因包括

依赖的 ConfigMap、Secret 或者 PV 等不存在
请求的资源超过了管理员设置的限制，比如超过了 LimitRange 等
违反集群的安全策略，比如违反了 PodSecurityPolicy 等
容器无权操作集群内的资源，比如开启 RBAC 后，需要为 ServiceAccount 配置角色绑定

Pod 处于 Terminating 或 Unknown 状态

从 v1.5 开始，Kubernetes 不会因为 Node 失联而删除其上正在运行的 Pod，而是将其标记为 Terminating 或 Unknown 状态。想要删除这些状态的 Pod 有三种方法：

从集群中删除该 Node。使用公有云时，kube-controller-manager 会在 VM 删除后自动删除对应的 Node。而在物理机部署的集群中，需要管理员手动删除 Node（如 kubectl delete node 。
Node 恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态，进而再决定删除或者继续运行这些 Pod。
用户强制删除。用户可以执行 kubectl delete pods --grace-period=0 --force 强制删除 Pod。除非明确知道 Pod 的确处于停止状态（比如 Node 所在 VM 或物理机已经关机），否则不建议使用该方法。特别是 StatefulSet 管理的 Pod，强制删除容易导致脑裂或者数据丢失等问题。
Pod 行为异常
这里所说的行为异常是指 Pod 没有按预期的行为执行，比如没有运行 podSpec 里面设置的命令行参数。这一般是 podSpec yaml 文件内容有误，可以尝试使用 --validate 参数重建容器，比如

kubectl delete pod mypod
kubectl create --validate -f mypod.yaml
也可以查看创建后的 podSpec 是否是对的，比如

kubectl get pod mypod -o yaml
修改静态 Pod 的 Manifest 后未自动重建
Kubelet 使用 inotify 机制检测 /etc/kubernetes/manifests 目录（可通过 Kubelet 的 --pod-manifest-path 选项指定）中静态 Pod 的变化，并在文件发生变化后重新创建相应的 Pod。但有时也会发生修改静态 Pod 的 Manifest 后未自动创建新 Pod 的情景，此时一个简单的修复方法是重启 Kubelet。

https://zhuanlan.zhihu.com/p/34332367

Unknown。这是一个异常状态，意味着 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver，这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。

kubectl get csr | wc -l不断增加，如下

[root@master] ~$ kubectl get csr
NAME        AGE       REQUESTOR           CONDITION
csr-4b26s   2h        kubelet-bootstrap   Approved,Issued
csr-635v6   36m       kubelet-bootstrap   Pending
csr-cq3p1   2h        kubelet-bootstrap   Pending
csr-frhbk   10m       kubelet-bootstrap   Pending
csr-hzck7   2h        kubelet-bootstrap   Pending
csr-jp64n   1h        kubelet-bootstrap   Pending
csr-v5l07   1h        kubelet-bootstrap   Pending

参考https://github.com/opsnull/follow-me-install-kubernetes-cluster/issues/42，查看日志如下，可以看出是kubelet不断的重启造成的

[root@master] ~$ journalctl -u kubelet
-- Logs begin at Sat 2018-11-10 21:02:11 CST, end at Fri 2019-01-11 19:26:44 CST. --
Jan 11 16:39:41 master.hanli.com systemd[1]: Started Kubernetes Kubelet Server.
Jan 11 16:39:41 master.hanli.com systemd[1]: Starting Kubernetes Kubelet Server...
Jan 11 16:39:41 master.hanli.com systemd[1]: kubelet.service: main process exited, code=exited, status=200/CHDIR
Jan 11 16:39:41 master.hanli.com systemd[1]: Unit kubelet.service entered failed state.
Jan 11 16:39:41 master.hanli.com systemd[1]: kubelet.service failed.
Jan 11 16:39:41 master.hanli.com systemd[1]: kubelet.service holdoff time over, scheduling restart.
Jan 11 16:39:41 master.hanli.com systemd[1]: Started Kubernetes Kubelet Server.
Jan 11 16:39:41 master.hanli.com systemd[1]: Starting Kubernetes Kubelet Server...
Jan 11 16:39:41 master.hanli.com systemd[1]: kubelet.service: main process exited, code=exited, status=200/CHDIR
Jan 11 16:39:41 master.hanli.com systemd[1]: Unit kubelet.service entered failed state.
Jan 11 16:39:41 master.hanli.com systemd[1]: kubelet.service failed.
Jan 11 16:39:41 master.hanli.com systemd[1]: kubelet.service holdoff time over, scheduling restart.
Jan 11 16:39:41 master.hanli.com systemd[1]: Started Kubernetes Kubelet Server.
Jan 11 16:39:41 master.hanli.com systemd[1]: Starting Kubernetes Kubelet Server...

解决：
1、先停止node上的kubelet

ansible kubernetes -m shell -a  "systemctl stop kubelet"

• 1

2、删除后面创建的csr（根据时间判断）

[root@master] ~$ kubectl delete csr csr-635v6
certificatesigningrequest "csr-635v6" deleted
[root@master] ~$ kubectl delete csr csr-frhbk
certificatesigningrequest "csr-frhbk" deleted
[root@master] ~$ kubectl delete csr csr-jp64n
certificatesigningrequest "csr-jp64n" deleted
[root@master] ~$ kubectl delete csr csr-v5l07
certificatesigningrequest "csr-v5l07" deleted

2、failed to create kubelet: misconfiguration: kubelet cgroup driver: “cgroupfs” is different from docker cgroup driver: “systemd”

参考：https://www.jianshu.com/p/02dc13d2f651

报错原因：kubelet的cgroup driver和docker 的cgroup driver不一样

查看docker的cgroup driver

docker info

解决：vim /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
#添加如下配置

Environment=“KUBELET_CGROUP_ARGS=–cgroup-driver=cgroupfs”

3、pod一直处于ContainerCreating状态

kubectl get pod -o wide发现没有没有ip，describe没有events，不知道什么原因。最后重启节点上的kubelet解决了问题，但是根本原因还不太清楚。

4、安装flannel时无限重启，状态为：CrashLoopBackOff

[root@master1] ~$ kubectl get pods --all-namespaces -o wide
NAMESPACE     NAME                                        READY   STATUS              RESTARTS   AGE     IP                NODE                NOMINATED NODE   READINESS GATES
kube-system   coredns-86c58d9df4-26rbt                    0/1     ContainerCreating   0          15h     <none>            master2.hanli.com   <none>           <none>
kube-system   coredns-86c58d9df4-xksf4                    0/1     ContainerCreating   0          15h     <none>            master2.hanli.com   <none>           <none>
kube-system   kube-apiserver-master1.hanli.com            1/1     Running             0          15h     192.168.255.131   master1.hanli.com   <none>           <none>
kube-system   kube-apiserver-master2.hanli.com            1/1     Running             0          14h     192.168.255.132   master2.hanli.com   <none>           <none>
kube-system   kube-apiserver-master3.hanli.com            1/1     Running             0          14h     192.168.255.133   master3.hanli.com   <none>           <none>
kube-system   kube-controller-manager-master1.hanli.com   1/1     Running             1          14h     192.168.255.131   master1.hanli.com   <none>           <none>
kube-system   kube-controller-manager-master2.hanli.com   1/1     Running             0          14h     192.168.255.132   master2.hanli.com   <none>           <none>
kube-system   kube-controller-manager-master3.hanli.com   1/1     Running             1          14h     192.168.255.133   master3.hanli.com   <none>           <none>
kube-system   kube-flannel-ds-amd64-556dd                 0/1     CrashLoopBackOff    4          6m42s   192.168.255.133   master3.hanli.com   <none>           <none>
kube-system   kube-flannel-ds-amd64-9hkzz                 0/1     CrashLoopBackOff    5          6m44s   192.168.255.132   master2.hanli.com   <none>           <none>
kube-system   kube-flannel-ds-amd64-f7jmm                 0/1     CrashLoopBackOff    5          6m43s   192.168.255.121   slave1.hanli.com    <none>           <none>
kube-system   kube-flannel-ds-amd64-fhfc7                 0/1     CrashLoopBackOff    5          6m46s   192.168.255.122   slave2.hanli.com    <none>           <none>
kube-system   kube-flannel-ds-amd64-rk464                 0/1     CrashLoopBackOff    5          6m44s   192.168.255.131   master1.hanli.com   <none>           <none>
kube-system   kube-proxy-dbhll                            1/1     Running             0          14h     192.168.255.121   slave1.hanli.com    <none>           <none>
kube-system   kube-proxy-hr94l                            1/1     Running             0          14h     192.168.255.122   slave2.hanli.com    <none>           <none>
kube-system   kube-proxy-qxd99                            1/1     Running             0          14h     192.168.255.133   master3.hanli.com   <none>           <none>
kube-system   kube-proxy-tx7zb                            1/1     Running             0          15h     192.168.255.131   master1.hanli.com   <none>           <none>
kube-system   kube-proxy-x5fqx                            1/1     Running             0          14h     192.168.255.132   master2.hanli.com   <none>           <none>
kube-system   kube-scheduler-master1.hanli.com            1/1     Running             1          15h     192.168.255.131   master1.hanli.com   <none>           <none>
kube-system   kube-scheduler-master2.hanli.com            1/1     Running             0          14h     192.168.255.132   master2.hanli.com   <none>           <none>
kube-system   kube-scheduler-master3.hanli.com            1/1     Running             0          14h     192.168.255.133   master3.hanli.com   <none>           <none>

查看描述kubectl describe pod xxx -n kube-system和日志 kubectl logs xxx -n kube-system来排错。发现所有节点的日志都一样，如下：

[root@master1] ~$ kubectl  logs  kube-flannel-ds-amd64-f7jmm -n kube-system
I0610 03:08:53.075251       1 main.go:475] Determining IP address of default interface
I0610 03:08:53.075694       1 main.go:488] Using interface with name ens33 and address 192.168.255.121
I0610 03:08:53.075707       1 main.go:505] Defaulting external address to interface address (192.168.255.121)
E0610 03:09:14.084203       1 main.go:232] Failed to create SubnetManager: error retrieving pod spec for 'kube-system/kube-flannel-ds-amd64-f7jmm': Get https://10.96.0.1:443/api/v1/namespaces/kube-system/pods/kube-flannel-ds-amd64-f7jmm: dial tcp 10.96.0.1:443: getsockopt: connection refused

连接被拒绝，怀疑和权限有关系。再看下kubelet的日志journalctl -r -u kubelet -o cat：发现有如下日志

secret.go:194] Couldn't get secret kube-system/flannel-token-hb2s7: secret "flannel-token-hb2s7" not found

怀疑原因可能是我安装flannel与前面初始化节点的时间超过2个小时了，token过期了，我kubeadm reset重置之后再次初始化然后再安装flannel，就好了。

pod无法创建，一直处于ContainerCreating，报错信息如下：

kj describe pod service-84d66b9fb6-sx9z4，如下

Warning  FailedCreatePodSandBox  8m (x12 over 9m)     kubelet, node7     Failed create pod sandbox.
  Normal   SandboxChanged          4m (x79 over 9m)     kubelet, node7     Pod sandbox changed, it will be killed and re-created.

在node7上查看kubelet日志，关键信息如下：

ccd8-htvj2": Error response from daemon: grpc: the connection is unavailable

参考：https://www.jianshu.com/p/3222f720d7a4
https://zhuanlan.zhihu.com/p/39307117

重启docker后pod从ContainerCreating转为running。
但是过了几分钟后，pod又变成CrashLoopBackOff 了

[root@master1 ~]# kj get pod |grep service
service-84d66b9fb6-sx9z4                0/1       ContainerCreating      0          32m

[root@master1 ~]# kj get pod |grep service
service-84d66b9fb6-sx9z4                1/1       Running                1          36m


[root@master1 ~]# kj get pod |grep service
service-84d66b9fb6-sx9z4                0/1       CrashLoopBackOff       6          48m

describe如下

  Warning  BackOff                 5s (x54 over 15m)    kubelet, node7     Back-off restarting failed container

kubelet日志：

69270 remote_runtime.go:92] RunPodSandbox from runtime service failed: rpc error: code = Unknown desc = fai

 k8s注册节点出现kube-flannel-ds服务状态Init:0/1

 

https://www.cnblogs.com/liuyi778/p/12771259.html