kubernetes错误 pod故障总结
万能解决办法： 重启大法好（生产环境三思而后行）
- 重启容器
- 重启kubelet
- 重启systemd
- 重启机器
一般来说，无论 Pod 处于什么异常状态，都可以执行以下命令来查看 Pod 的状态
kubectl get pod -o yaml 查看 Pod 的配置是否正确
kubectl describe pod 查看 Pod 的事件
kubectl logs [-c ] 查看容器日志
这些事件和日志通常都会有助于排查 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:
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 master2.hanli.com
kube-system coredns-86c58d9df4-xksf4 0/1 ContainerCreating 0 15h master2.hanli.com
kube-system kube-apiserver-master1.hanli.com 1/1 Running 0 15h 192.168.255.131 master1.hanli.com
kube-system kube-apiserver-master2.hanli.com 1/1 Running 0 14h 192.168.255.132 master2.hanli.com
kube-system kube-apiserver-master3.hanli.com 1/1 Running 0 14h 192.168.255.133 master3.hanli.com
kube-system kube-controller-manager-master1.hanli.com 1/1 Running 1 14h 192.168.255.131 master1.hanli.com
kube-system kube-controller-manager-master2.hanli.com 1/1 Running 0 14h 192.168.255.132 master2.hanli.com
kube-system kube-controller-manager-master3.hanli.com 1/1 Running 1 14h 192.168.255.133 master3.hanli.com
kube-system kube-flannel-ds-amd64-556dd 0/1 CrashLoopBackOff 4 6m42s 192.168.255.133 master3.hanli.com
kube-system kube-flannel-ds-amd64-9hkzz 0/1 CrashLoopBackOff 5 6m44s 192.168.255.132 master2.hanli.com
kube-system kube-flannel-ds-amd64-f7jmm 0/1 CrashLoopBackOff 5 6m43s 192.168.255.121 slave1.hanli.com
kube-system kube-flannel-ds-amd64-fhfc7 0/1 CrashLoopBackOff 5 6m46s 192.168.255.122 slave2.hanli.com
kube-system kube-flannel-ds-amd64-rk464 0/1 CrashLoopBackOff 5 6m44s 192.168.255.131 master1.hanli.com
kube-system kube-proxy-dbhll 1/1 Running 0 14h 192.168.255.121 slave1.hanli.com
kube-system kube-proxy-hr94l 1/1 Running 0 14h 192.168.255.122 slave2.hanli.com
kube-system kube-proxy-qxd99 1/1 Running 0 14h 192.168.255.133 master3.hanli.com
kube-system kube-proxy-tx7zb 1/1 Running 0 15h 192.168.255.131 master1.hanli.com
kube-system kube-proxy-x5fqx 1/1 Running 0 14h 192.168.255.132 master2.hanli.com
kube-system kube-scheduler-master1.hanli.com 1/1 Running 1 15h 192.168.255.131 master1.hanli.com
kube-system kube-scheduler-master2.hanli.com 1/1 Running 0 14h 192.168.255.132 master2.hanli.com
kube-system kube-scheduler-master3.hanli.com 1/1 Running 0 14h 192.168.255.133 master3.hanli.com
查看描述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 = faik8s注册节点出现kube-flannel-ds服务状态Init:0/1
https://www.cnblogs.com/liuyi778/p/12771259.html