K8s 高频问题一站式排查清单

生产环境 Kubernetes 集群常见故障的快速诊断路径。10 个高频场景，每个都给出排查步骤、根因修复、风险提醒和回滚方案。 每个问题链接到对应的深度页面，这里做快速定位，详细分析去对应页面。

问题一：Pod Pending

诊断入口： kubectl describe pod → Events 段看最后几行

三大根因：

⚠️ 风险提醒： 修改污点会影响其他 Pod 调度——确认节点属专用节点前别乱删污点。 🔙 回滚： 如果是改 YAML 解决的，直接 kubectl apply 原配置；涉及污点则 taint 命令恢复。

📖 深度排查 → k8s-scheduling-strategy-guide | resource-rbac-scheduling-troubleshooting

问题二：Pod CrashLoopBackOff

诊断入口： 容器退出码 + kubectl logs --previous

排查步骤： 退出码 → 应用日志 → 启动命令 → 健康检查配置

常见退出码：

⚠️ 风险提醒： kubectl logs --previous 拿的是崩溃前的日志，是最关键的线索——别漏掉。 🔙 回滚： 如果是新版镜像导致的，快速 kubectl set image deployment/<name> <container>=<old-tag> 回退版本。

📖 深度排查 → pod-troubleshooting | k8s-probes-guide

问题三：Service 访问失败

诊断入口： 三步定位法——DNS 解析 / kube-proxy 转发 / Pod 监听

kubectl run test --image=busybox -it --rm -- sh
/ # nslookup <svc-name>.<namespace>.svc.cluster.local
/ # telnet <svc-name>.<namespace> 80

三个环节：

⚠️ 风险提醒： endpointSlice 或 endpoints 是排障关键——kubectl get endpoints <svc> 看是否有 Ready 后端。 🔙 回滚： 如果是新 Service 配置导致的，检查 Annotation 和 Service Type。

📖 深度排查 → service-troubleshooting | k8s-service-access-troubleshooting

问题四：镜像拉取失败（ImagePullBackOff）

诊断入口： kubectl describe pod → Events 段看具体错误

五步排查：

根因快速对照：

⚠️ 风险提醒： imagePullPolicy: Always 会让节点每次都拉取，私有仓库带宽不足时可能导致镜像拉取雪崩。建议稳定版本用 IfNotPresent。 🔙 回滚： kubectl edit deployment <name> 恢复旧镜像标签。

📖 深度排查 → pod-troubleshooting（ImagePullBackOff 章节） | docker-image-optimization

问题五：Node NotReady

诊断入口： kubectl get nodes → kubectl describe node <node-name>

四步排查：

⚠️ 风险提醒： Node NotReady 后，该节点上非 DaemonSet Pod 默认在 pod-eviction-timeout（默认 5 分钟）后驱逐到其他节点。别急着触发节点下线，先确认是不是短暂的网络抖动。 🔙 回滚： 如果是证书问题，更新证书后重启 kubelet；如果是资源耗尽，清理后不用操作会自动恢复 Ready。

📖 深度排查 → node-troubleshooting

问题六：存储卷挂载异常

诊断入口： kubectl get pvc -n <ns> → kubectl describe pvc <pvc-name>

故障链定位：

PVC Pending → 检查 StorageClass → 检查 PV → 检查 CSI 驱动 → 检查后端存储

常见根因：

⚠️ 风险提醒： 有状态应用的存储问题不适用简单的 Pod 重建——新 Pod 会挂载同名 PVC，如果 PVC 本身有问题则修复过程更复杂。 🔙 回滚： 如果是 PV/PVC 配置问题，先恢复原 StorageClass 和 PVC 定义，再重新创建 Pod。

📖 深度排查 → storage-troubleshooting | k8s-persistent-storage-guide | k8s-statefulset-guide

问题七：资源配额耗尽 / Pod 驱逐

诊断入口： kubectl get pod -n <ns> | grep Evicted

核心排查：

# 查看命名空间配额
kubectl get resourcequota -n <namespace>

# 查看 LimitRange
kubectl get limitrange -n <namespace>

# 查看被驱逐 Pod 的原因
kubectl get pod <evicted-pod> -n <ns> -o yaml | grep -A 5 "reason"

触发条件：

⚠️ 风险提醒： kubectl describe pod 的 Status.Reason 字段区分是资源耗尽驱逐还是节点压力驱逐——处理方式完全不同。 🔙 回滚： 临时去掉 Pod 的资源限制（删除 limits 字段）可快速拉起，但治本要调整配额或优化应用。

📖 深度排查 → k8s-resource-limits-configuration | resource-rbac-scheduling-troubleshooting

问题八：etcd 集群故障

诊断入口： etcdctl endpoint health / systemctl status etcd

核心排查：

# 检查集群成员
etcdctl member list

# 检查端点健康
etcdctl endpoint health

# 检查端点状态（含 Raft 指标）
etcdctl endpoint status --write-out=table

# 检查告警（空间满会触发 alarm）
etcdctl alarm list

生产环境关键指标：

⚠️ 风险提醒： etcd 是有状态核心组件。etcd 恢复失败后不要直接替换数据目录——用 etcdctl snapshot restore 从快照恢复。永远不要手工复制/替换 etcd 数据文件。 🔙 回滚： 定期 etcdctl snapshot save 做快照，故障时 etcdctl snapshot restore 恢复。

📖 深度排查 → k8s-production-incident-case-studies（etcd 故障案例） | k8s-troubleshooting-principles

问题九：DNS 解析异常

诊断入口： kubectl run test --image=busybox -it --rm -- nslookup <svc-name>

排查步骤：

常见根因：

• CoreDNS Pod 未运行或正在重启 → 检查资源限制 / OOM
• ndots:5 导致额外的 DNS 查询 → 应用配置 ndots:1 优化
• 自定义 DNS Policy 覆盖了集群 DNS → 检查 Pod dnsPolicy 字段
• 网络策略（NetworkPolicy）阻止了 DNS 流量 → 检查 UDP 53 端口规则

⚠️ 风险提醒： CoreDNS 的 resources.limits.memory 不足会导致 OOM 重启，引发间歇性 DNS 超时——这是"服务一会好一会坏"的最常见原因。 🔙 回滚： 临时加一个 dnsPolicy: ClusterFirstWithHostNet 可以绕过部分 DNS 问题，但治本要修 CoreDNS。

📖 深度排查 → service-troubleshooting（DNS 章节） | k8s-service-access-troubleshooting

问题十：Pod 安全策略 / 权限不足

诊断入口： kubectl get pod <pod> -n <ns> -o yaml | grep -A 20 securityContext

三层安全控制：

定位步骤：

# 检查 Pod 安全上下文
kubectl get pod <pod> -n <ns> -o yaml | grep -A 15 securityContext

# 检查命名空间安全标签
kubectl get ns <ns> -o yaml | grep pod-security

# 检查是否有 Seccomp / AppArmor 配置
kubectl get pod <pod> -n <ns> -o yaml | grep -E "seccomp|apparmor"

# 复现问题：exec 进容器测试写入/执行权限
kubectl exec -it <pod> -n <ns> -- touch /tmp/test
kubectl exec -it <pod> -n <ns> -- id

⚠️ 风险提醒： readOnlyRootFilesystem: true 并且没有挂载 emptyDir 卷时，程序任何磁盘写入都会失败——第一次部署时极易忽略。 🔙 回滚： 如果是 securityContext 配置问题，先注释掉限制字段重启 Pod 恢复服务，再逐一收紧权限。

📖 深度排查 → resource-rbac-scheduling-troubleshooting | k8s-production-incident-case-studies

关联页面