标签：K8s 与云原生故障排查 - Ai拆代码的曹操

kubectl drain 卡了 2 小时？找你的 PodDisruptionBudget

kubectl drain 卡了 2 小时？找你的 PodDisruptionBudget 场景：节点下线维护，kubectl drain 执行后 10 分钟一个 Pod 都没驱逐——PDB 设了 minAvailable: 100%，allowedDisruptions=0，drain 卡死了路

VPA 推荐不准？不是 VPA 不行——是你 Pod 重启过场景：VPA 上线后推荐 CPU 1.2 核，Pod 实际只用 300m 路径：坐标 → 分层 → 路径 → 定位 → 标点以下排查基于 K8s v1.25，VPA v1.x（autoscaling.k8s.io/v1 API）。上篇

CPU 85% 但 HPA 利用率只有 14%？问题不在采集——requests 分母太大了场景：线上服务流量翻 3 倍 → CPU 冲到 85% → HPA 没扩容 → Pod 数卡在 3 不动路径：坐标 → 分层 → 路径 → 定位 → 标点以下排查基于 K8s v1.25，metrics

场景：CronJob 定时备份凌晨没执行 + Job 重试耗尽（K8s v1.25）路径：kubectl describe cronjob → kubectl get job -o yaml → kubectl get pods 上篇讲了 DaemonSet 优雅终止，核心是通过 PDB 和 pr

DaemonSet 滚动更新导致服务中断——优雅终止与 PodDisruptionBudget 场景: DaemonSet RollingUpdate 过程中旧 Pod 被 SIGTERM → 进程不优雅退出 → Prometheus 采集链路断裂路径: Pod(优雅终止机制) → CRI(信号转

DaemonSet 更新策略不一致——OnDelete vs RollingUpdate 选择陷阱场景: 给 fluent-bit DaemonSet 改了镜像版本，kubectl rollout restart 命令成功了——但 Pod 一个都没重启路径: Pod 状态 → 策略分层对比 →

DaemonSet 滚动更新导致节点逐个宕机场景: DaemonSet 滚动更新 CNI 配置 → DaemonSet Pod 逐节点终止重建 → 节点逐台 NotReady 路径: Pod → CRI → Node → 集群逐层排查版本: K8s v1.25 上篇讲了 Pod 调度不均衡问题

上篇我们聊了 Pod CrashLoopBackOff 时日志拿不到的排查思路，用 crictl 绕过 kubectl 直接读容器运行时日志。这篇看一个完全不同的方向——Pod 不是起不来，是起来了但分布不均衡。场景：Deployment 20 副本上线后，Pod 全堆在 2 台 Node，其余

Pod 状态 CrashLoopBackOff：日志拿不到怎么办？场景：Pod 一直 CrashLoopBackOff，kubectl logs 看不到崩溃前的错误日志路径：坐标 → 分层 → 路径 → 定位 → 标点以下排查基于 K8s v1.25，容器运行时为 containerd v1.

Pod 启动慢——Init Container / 镜像拉取策略优化场景：灰度 5% 流量 → 超时率飙升 → 回滚 → 新版 Pod 启动慢了 3 分钟路径：坐标 → 分层 → 路径 → 定位 → 标点以下排查基于 K8s v1.25，容器运行时为 containerd 1.6。坐标上篇