k8s中pod常见的启动和运行错误

启动错误如下：

• imagePullBackoff
• imagelnspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

运行错误如下：

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

以下为常见错误的解决方法

ImagePullBackOff
可能原因为kubernetes无法获取到某个pod的镜像
共有三个可能原因：

• 镜像名称无效，像镜像名称拼写错误，或者image不存在
• 为image制定了无效的标签
• 检索的image属于私有registry，并且kubernetes没有凭据可以访问它

前两种情况可以更正image名称和标签来解决
第三种情况，需要将私有registry的访问凭据通过Secrert添加到kubernetes中并且在pod中引用它

CrashLoopBackOff
当容器无法启动时，kubernetes显示的错误状态为CrashLoopBackOff
通常在以下情况无法启动：

• 应用程序存在错误，导致无法启动
• 没有正确配置容器
• Liveness探针失败多次

此时应该尝试从容器中查看日志明确失败原因
如果容器重新启动太快看不到日志，使用如下命令：

kubectl logs <pod-name> --previous

这个命令可以打印前一个容器的错误信息

RunContainerError
当容器无法启动时，或者是容器内的应用程序启动之前，可能会出现此错误
该问题通常是由于配置错误

• 通常挂载不存在的卷，例如ConfigMap或Secrets
• 将只读卷安装为可读写

应该使用kubectl describe pod命令收集和分析错误

处于Pending状态的Pod
当创建pod时，pod会保持Pending状态
此时，如果你的调度程序运行良好，可能为如下原因：

• 集群没有足够的资源来运行pod
• 当前命名空间具有ResourceQuota对象，创建pod将使命名空间超过配额
• 该pod绑定到一个处于pending状态的PersistentVolumeClaim

此时应该使用kubectl describe命令输出事件的部分内容：

kubectl describe pod <pod name>

对于因ResourceQuotas而导致的错误，可以使用以下方法检查集群的日志

kubectl get events --sort-by=.metadata.creationTimestamp

处于未就绪状态的Pod
如果pod正在运行但未就绪（not ready），则表示Readiness就绪探针失败
当就绪探针失败时，pod并未连接到服务，并且没有流量转发到实例
就绪探针失败时应用程序的特定错误，因此你应该检查kubectl describe中的事件部分来寻找错误