7 月 Kubernetes 排障 Top 10最常踩的坑与最快的解法一、一个月 47 张工单背后的共同模式七月团队共处理 Kubernetes 相关排障工单 47 张平均每天超过 1.5 张。对 47 张工单做归类后发现Top 10 问题占据了总量的 83%。每个问题的共性是根因往往不是 Kubernetes 本身的 Bug而是配置不当、资源边界理解不足、或者对控制器行为预期偏差。以下按频率降序排列每一类问题都给出最直接的排查路径和修复方案。基础设施领域的排障不需要走弯路——知道往哪个方向看问题就解决了一半。二、排障全景Top 10 问题的归类与分布问题一ImagePullBackOff 与镜像拉取失败14 张频率最高的问题七月中 30% 的工单与此相关。最常见的三个根因Secret 中 Docker config 过期40%、镜像仓库网络不可达35%、imagePullPolicy 为 Always 但本地已有镜像的节点重启后反复拉取25%。排查链路固定先kubectl describe pod看 Events 中的具体错误信息是认证失败还是连接超时。如果事件显示unauthorized: authentication required直接检查对应 namespace 下的 imagePullSecret 是否和当前仓库凭据一致。如果是dial tcp: i/o timeout从 Pod 所在节点上用 curl 测试到镜像仓库的网络连通性特别注意私有仓库是否在 Pod 安全组白名单内。对于经常被忽略的imagePullPolicy: Always问题当一个常用基础镜像的节点重启后即使本地缓存还在Always 策略也会强制重新拉取。如果此时镜像仓库正好挂掉所有节点上的 Pod 会集体启动失败。建议对稳定版本的基础镜像使用IfNotPresent。问题二OOMKilled 与资源 Limit 不合理11 张23% 的工单是 OOM 导致的 Pod 重启。典型案例Java 服务设置了limits.memory: 2Gi但 JVM 堆设了-Xmx2g加上堆外内存和 Metaspace实际内存峰值超过 3Gi。Cgroup 在达到 2Gi 时直接 KillPod 陷入反复启动-被杀循环。排查这类问题需要三步首先确认kubectl describe pod中的Last State是OOMKilled其次检查应用本身的内存配置是否与 K8s Limit 对齐——Java 看 JVM 参数Go 看 GOMEMLIMITPython 看 worker 数量最后用 Prometheus 查看container_memory_working_set_bytes的实际峰值修正 Limit 值。修复策略不是简单把 Limit 调大。正确做法是先设置一个合理的 request如实际稳定运行时的 1.2 倍Limit 设为 request 的 1.5-2 倍。同时启用automountServiceAccountToken: false减少不必要的 Sidecar 内存开销。问题三CrashLoopBackOff 启动探针误配9 张19% 的工单是探针配置导致。三种常见误配startupProbe 缺失导致 readiness 延迟不够应用启动需要 30s但 readiness 的initialDelaySeconds只给了 5s。结果 Pod 一直处于 Running 但 Not ReadyService 不会分流量但 K8s 认为 Pod 重启了。livenessProbe 过于激进periodSeconds: 5failureThreshold: 2意味着只要应用有 10s 卡顿就被 Kill。在 GC 密集型应用或数据库连接池初始化的场景下频繁误杀。exec 探针本身消耗资源用exec执行 heavy 检查脚本每秒一次CPU 被探针吃掉了 30%。修正方案永远先配 startupProbefailureThreshold: 30, periodSeconds: 2给应用充足的启动时间livenessProbe 设置保守的periodSeconds: 30加failureThreshold: 5ready 检查用 HTTP GET 代替 exec减少 CPU 开销。问题四Pending 状态与节点资源不足7 张Pod 一直 Pending 且 Events 显示0/10 nodes are available: 2 Insufficient cpu, 3 Insufficient memory, 5 node(s) had taint。这里的关键是不要只看资源总量要看 request 而非 limit 的调度决策。排查用kubectl describe nodes | grep -A 5 Allocated resources看实际分配的 request把 Pod 的 request 调小和 Limit 解耦通常是比扩容节点更快的解法。另外 nodeAffinity 和 taint/toleration 也是常见的 Pending 原因kubectl get nodes -o json | jq .items[].spec.taints能快速检查。问题五DNS 解析超时与服务发现6 张七月份有一半的 DNS 问题集中在 Alpine 镜像的 musl libc DNS 行为差异上。Alpine 的 musl 默认不走 search domain 的 ndots 逻辑K8s 默认的 ndots:5 配置在 Alpine 环境中会产生大量不必要的 DNS 查询。解法在 Pod spec 中显式设置dnsConfig.options.ndots: 2同时对高频调用的内部服务使用 clusterIP 的 FQDN 而非短域名。问题六PV/PVC 挂载失败5 张主要是 CSI driver 版本和 K8s 版本不兼容。七月有两个集群升级 K8s 到 1.29 后旧的 AWS EBS CSI Driver 1.22 无法正常工作。排障时重点关注kubectl describe pvc的 Events 中是否有 Provisioner 相关的错误日志。问题七Service Endpoint 不更新4 张当 Pod 的 Label 变更但 Service 的 Endpoint 没有同步更新时通常是 endpoint controller 卡住。排查方法kubectl get endpoints确认 endpoint 数量和 Pod 数量是否一致不一致时检查 kube-controller-manager 日志。问题八HPA 伸缩不生效4 张大多是metrics-server不可用或者自定义指标 adapter 配置错误。20% 的情况是 HPA 的minReplicas和maxReplicas设置相同导致伸缩被禁用。检查链路kubectl get hpa→kubectl describe hpa→ 看是否显示unable to get metrics。问题九节点 NotReady 与 Kubelet 异常3 张节点 NotReady 后 Pod 会被打上node.kubernetes.io/unreachable的 toleration 倒计时。问题在于默认的tolerationSeconds: 300往往太长——300 秒的业务中断不可接受。对核心服务建议自定义 toleration将驱逐时间缩短到 60 秒。问题十ConfigMap 更新后 Pod 不重启2 张K8s 不会自动重启引用 ConfigMap 的 Pod。如果用 subPath 挂载单个文件ConfigMap 更新后文件不会热更新。解法使用 Reloader 这类工具自动触发滚动更新或者在 ConfigMap 名称中加版本 hash。三、统一排查工具箱47 张工单中有 32 张可以用以下三个命令在 5 分钟内定位到根因# 1. 快速总览 kubectl describe pod pod-name -n ns | grep -A 20 Events: # 2. 资源实际使用 kubectl top pod pod-name -n ns --containers # 3. 最近日志含前一个容器的崩溃日志 kubectl logs pod-name -n ns --previous --tail100操作顺序固定Events → 资源使用 → 日志。不要跳步骤不要先去看日志再回来看 Events。90% 的问题在 Events 里就已经写明了根因。四、排障过程中容易忽略的系统性问题以上十个问题各自独立但它们存在三个系统性的共性问题容易被忽略监控覆盖不足OOM 问题中 30% 是在用户投诉后才发现的因为 Pod 重启太快Prometheus 的 scrape interval 来不及采集到内存尖峰。告警规则不精确大量 CrashLoopBackOff 的告警被和 ImagePullBackOff 混在同一个 PromQL 中噪声比高导致真正需要处理的告警被忽略。版本升级回归测试缺失PV 挂载和 DNS 问题都发生在集群升级后说明缺乏针对 CSI driver 和 CoreDNS 的专项回归检查。五、总结七月 Top 10 排障问题按频率的前三名是镜像拉取、OOM 和探针误配合计占工单量的 72%。这三类问题的共同特点是都不是 K8s 的 Bug而是配置和资源规划问题。治理方向有三条镜像治理统一基础镜像版本、强制设定 imagePullPolicy 策略、定期轮转 imagePullSecret。资源规划建立资源 request/Limit 的基线标准将 OOM 告警从事后通知升级为基于趋势的预警。探针规范制定 startupProbe/livenessProbe/readinessProbe 的配置模板禁止无 startupProbe 的 Pod 部署到生产环境。基础设施的稳定不是靠一次排障就能保证的靠的是把每类问题的根因固化为规范。