Kubernetes Pod故障归类与排查方法

Pod概念

Pod是kubernetes集群中最小的部署和管理的基本单元，协同寻址，协同调度。
Pod是一个或多个容器的集合，是一个或一组服务（进程）的抽象集合。
Pod中可以共享网络和存储（可以简单理解为一个逻辑上的虚拟机，但并不是虚拟机）。
Pod被创建后用一个UID来唯一标识，当Pod生命周期结束，被一个等价Pod替代时UID将重新生成。

Kubernetes Pod中最常用Docker容器运行，当然Pod也能支持其他的容器运行，比如rkt、podman等。

Kubernetes集群中的Pod可被用于以下两个主要用途：

运行单个容器的Pod。“每个Pod 一个容器”模型是最常见的Kubernetes用例；在这种情况下，可以将Pod看作单个容器的包装器，并且Kubernetes直接管理Pod，而不是容器。
运行多个协同工作的容器的Pod。Pod可能封装由多个紧密耦合且需要共享资源的共处容器组成的应用程序。这些位于同一位置的容器可能形成单个内聚的服务单元，一个容器将文件从共享卷提供给公众，而另一个单独的“挂斗”容器则刷新或更新这些文件。Pod将这些容器和存储资源打包为一个可管理的实体。

Pod控制器

控制器可以为您创建和管理多个Pod，管理副本和上线，并在集群范围内提供自修复能力。例如，如果一个节点失败，控制器可以在不同的节点上调度一样的替身来自动替换Pod。

包含一个或多个Pod的控制器一些示例包括：

Deployment kubernetes中最常见的控制器。用于运行无状态应用
Statefulset 用于运行有状态应用
DaemonSet 作用就像是计算机中的守护进程，它能够运行集群存储、日志收集和监控等【守护进程】

控制器通常使用您提供的Pod模块来创建它负责的Pod。

Pod故障归类

Pod状态一直处于Pending
Pod状态一直处于Waiting
Pod状态一直处于ContainerCreating
Pod状态处于ImagePullBackOff
Pod状态处于CrashLoopBackOff
Pod状态处于Error
Pod状态一直处于Terminating
Pod状态处于Unknown

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、镜像拉取失败，比如镜像地址配置错误、拉取不了国外镜像源（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来验证镜像是否可以正常拉取。

如果私有镜像密钥配置错误或没有配置，按下面检查：

1、查询docker-registry类型的Secret

# 查看 docker-registry Secret
$ kubectl get secrets my-secret -o yaml | grep 'dockerconfigjson:' | awk '{print $NF}' | base64 -d

2、创建docker-registry类型的Secret

# 首先创建一个 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
# 然后在 Deployment 中引用这个 Secret
spec:
  containers:
  - name: private-reg-container
    image: <your-private-image>
  imagePullSecrets:
  - name: my-secret

Pod 一直处于CrashLoopBackOff状态

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

通过命令 kubectl logs 和 kubectl logs --previous 可以发下一些容器退出的原因，比如：容器进程退出、健康检查失败退出；此时如果还未发现线索，还而已到容器内执行命令（kubectl exec cassandra - cat /var.log/cassandra/system.log）来进一步查看退出原因；如果还是没有线索，那就需要SSH登录该Pod所在的Node上，查看Kubelet或者Docker的日志进一步排查。

Pod 处于 Error 状态

通常处于Error状态说明Pod启动过程中发生了错误。常见的原因：依赖的ConfigMap、Secret或PV等不存在；请求的资源超过了管理员设置的限制，比如超过了LimitRange等；违反集群的安全策略，比如违反了PodSecurityPolicy等；容器无法操作集群内的资源，比如开启RDAC后，需要为ServiceAccount配置角色绑定。

Pod 处于Terminating或Unknown状态

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

1、从集群中删除Node。使用公有云时，kube-controller-manager会在VM删除后自动删除对应的Node。而在物理机部署的集群中，需要管理员手动删除Node（kubectl delete node）。

2、Node恢复正常。kubelet会重新跟kube-apiserver通信确认这些Pod的期待状态，进而再决定删除或者继续运行这些Pod。用户强制删除，用户可以执行（kubectl delete pods pod-name --grace-period=0 --force）强制删除Pod。除非明确知道Pod的确处于停止状态（比如Node所在VM或物理机已经关机），否则不建议使用该方法。特别是StatefulSet 管理的Pod，强制删除容易导致脑裂或数据丢失等问题。

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

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

参考链接