Kubernetes部署失败如何排查_K8s常见错误分析

4次阅读

kubernetes部署失败80%可三步定位:先看Pod状态、再查事件(kubectl describe pod)、最后读日志(含–previous)。CrashLoopBackOff需查上轮崩溃日志;ImagePullBackOff重点验镜像名、凭据、网络;Pending则查资源、标签、污点、配额。

Kubernetes部署失败如何排查_K8s常见错误分析

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 名称大小写敏感,regcredRegCred 是两个东西
  • 检查 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 cpunode(s) had taint {node-role.kubernetes.io/master:NoSchedule} 就直接对症下药
  • 别只看 kubectl top node,还要查节点真实可分配资源:kubectl describe node 里找 AllocatableNon-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 资源访问链一路往下捋。

text=ZqhQzanResources