K8s部署失败排查与常见错误解决

Kubernetes部署失败往往并非神秘难题，而是集中在Pod启动环节的几类高频问题：CrashLoopBackOff多因配置错误或依赖失败导致容器秒崩，需用--previous查看上轮日志定位真实原因；ImagePullBackOff本质是节点拉镜像受阻，关键在验证镜像名、私有仓库凭据（大小写敏感、Base64正确性）及网络连通性；Pending状态则暴露调度瓶颈，须结合describe事件、节点可分配资源和命名空间配额综合判断；而Service不通、Endpoint为空，九成源于标签不匹配或NetworkPolicy拦截。真正高效的排查不是盲目重试或删yaml，而是严格遵循“看状态→查事件→读日志”三步法，再顺藤摸瓜审视ConfigMap、RBAC、滚动更新等隐性依赖——80%的故障，其实三分钟内就能精准定位。

Kubernetes部署失败，90%以上都卡在Pod启动环节——不是镜像拉不下来，就是容器一启就崩，或者压根没被调度出去。别急着重试或删yaml，先看状态、查事件、读日志，三步就能定位80%的问题。

CrashLoopBackOff：应用一跑就崩，怎么快速定位？

这个状态说明容器反复启动→崩溃→重启，根本没活过几秒。关键不是“为什么崩”，而是“崩之前干了什么”。

• 先用 kubectl logs -n --previous 查上一轮崩溃的日志（当前容器可能已退出，--previous 才能看到真实错误）
• 常见真凶：configmap 挂载路径错导致配置文件缺失、secret 未注入导致数据库密码为空、环境变量名拼写错误（比如 DATABASE_URL 写成 DB_URL）、健康探针路径不存在（readinessProbe.httpGet.path: /healthz 但应用只暴露 /health）
• 别信应用日志里的“成功启动”——有些框架会先打一行启动日志，再因依赖初始化失败而退出，一定要看到最后一行错误堆栈

ImagePullBackOff：镜像明明存在，却说“找不到”

不是仓库里没有镜像，而是K8s节点根本没权限或没连上。重点查三件事：名字、凭据、网络。

• 在节点上手动执行 docker pull 或 crictl pull ，复现失败过程——能拉成功？那问题出在Pod定义；拉失败？看报错是 unauthorized 还是 timeout
• 私有仓库必须配 imagePullSecrets，且 Secret 必须和 Pod 在同一命名空间；Secret 名称大小写敏感，regcred 和 RegCred 是两个东西
• 检查 Secret 内容是否 Base64 编码正确：echo | base64 -d 应输出合法的 { "auths": { "xxx": { "auth": "..." } } }，否则 kubectl describe pod 里会显示 Failed to pull image "...": rpc error: code = Unknown desc = Error response from daemon: Get ...: unauthorized

Pending 状态不动：资源不够？还是被拦住了？

Pod 卡在 Pending，说明调度器连绑定都没完成。它不怪应用，只看资源、标签、污点、配额四样东西。

• 运行 kubectl describe pod -n ，紧盯 Events 区域——出现 Insufficient cpu 或 node(s) had taint {node-role.kubernetes.io/master:NoSchedule} 就直接对症下药
• 别只看 kubectl top node，还要查节点真实可分配资源：kubectl describe node 里找 Allocatable 和 Non-terminated Pods 占用，有些节点看似空闲，但已被 DaemonSet 或系统组件占满
• 命名空间级资源配额（ResourceQuota）常被忽略：kubectl get resourcequota -n ，如果显示 used 接近 hard，即使集群有空资源，Pod 也会被拒

Endpoint 为空、Service 不通：服务发现断在哪？

Deployment 起来了，Pod Running，但 kubectl get endpoints 返回空，说明 Service 根本没找到后端——八成是标签没对上。

• 对比两处标签：Pod 的 metadata.labels（如 app: guestbook） 和 Service 的 spec.selector（必须完全一致，包括键名和值）
• 注意 Deployment 模板里 spec.template.metadata.labels 才决定 Pod 标签，不是 Deployment 自身的 labels
• 如果用了 matchLabels + matchExpressions 复合选择器，漏掉任一条件都会导致 Endpoint 为空；简单起见，生产环境优先用纯 matchLabels
• NetworkPolicy 也可能静默拦截：kubectl get networkpolicy -A，尤其当集群默认拒绝所有入站流量时，哪怕标签全对，流量也到不了 Pod

最易被忽略的点：很多问题表面是“部署失败”，实际是滚动更新卡在旧副本没终止、ConfigMap 更新后 volume 挂载没刷新、或 RBAC 权限只给了 ClusterRole 没绑 RoleBinding——排查时别只盯着 Pod，得顺着 ServiceAccount → RoleBinding → Role → API 资源访问链一路往下捋。

今天关于《K8s部署失败排查与常见错误解决》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！