Kubernetes 排障：Pod、发布、网络与存储 · Kubernetes 排障手册

返回分篇目录

Kubernetes 排障：Pod、发布、网络与存储

Kubernetes 排障手册

从第一现场保存证据，再按Pod 症状、发布失败、Service、DNS、存储、节点或控制面进入具体路径。每次变更后回到原请求验证，最后处理临时措施与复盘。

排障原则

1. 先确认影响范围和用户症状，再看基础设施信号。
2. 明确集群、上下文、命名空间、对象名和事故开始时间。
3. 保存现状、日志、Event 和最近变更；不要先重启或删除证据。
4. 从最接近症状的一层开始，逐层验证假设。
5. 每次只做一个可回滚改变，记录时间和结果。
6. 恢复优先，但高风险数据/安全事故不得用破坏性操作“快速清场”。

第一现场

date -u
kubectl config current-context
kubectl cluster-info
kubectl -n demo get deployment,statefulset,daemonset,job,pod -o wide
kubectl -n demo get events --sort-by=.lastTimestamp
kubectl get nodes -o wide

查看目标对象完整状态：

kubectl -n demo get pod <pod> -o yaml
kubectl -n demo describe pod <pod>
kubectl -n demo logs <pod> -c <container> --since=30m --timestamps
kubectl -n demo logs <pod> -c <container> --previous --timestamps

YAML 可能含环境变量和引用信息，分享前脱敏；Secret 输出和 kubeconfig --raw 不进入事故群。

Pod 症状矩阵

症状	优先检查
Pending	FailedScheduling、requests、污点/亲和、PVC、配额、IP/节点容量
ContainerCreating	CNI Sandbox、镜像拉取、CSI Attach/Mount、Secret/ConfigMap
ErrImagePull/ImagePullBackOff	镜像名/digest、Registry/DNS、凭据、限流、架构
CrashLoopBackOff	上一次日志、退出码、启动参数、依赖、探针、OOM
Running 但 0/1 Ready	readiness 失败、端口、依赖、启动尚未完成
OOMKilled	limit、工作集峰值/泄漏、节点 OOM、应用内存参数
Evicted	Node Pressure、临时存储、日志、优先级/QoS
Terminating 卡住	Finalizer、preStop、进程不响应、Volume 卸载、节点失联
Completed	Job/一次性 Pod 正常完成；若属于服务则检查入口命令

CrashLoopBackOff 是退避结果，不是原因。不要循环删除 Pod；控制器会用同一配置重建。

Pending

先看 describe 的 Events；区分节点资源不足、污点/亲和性约束、PVC 未绑定等原因，再检查对应资源。预期是事件能解释未调度条件，修复后 Pod 被调度到满足条件的节点。

ImagePullBackOff

先记录 Events 中的具体拉取错误，再核对镜像名/标签或 digest、仓库可达性、凭据与 imagePullSecrets。修复后确认镜像已拉取且应用进入预期状态；仅改变重试次数不能说明仓库问题已解决。

CrashLoopBackOff

读取目标容器 logs --previous 和退出状态，检查启动命令、环境变量、依赖、探针和 OOM。多容器 Pod 必须指定容器；日志保留范围之外要回到集中日志。修复后确认重启数在观察窗口内稳定且容器 Ready。

启动链路的验证顺序

第一现场中的四组证据分别用于：get 记录 READY/STATUS/RESTARTS/NODE；describe 解释调度、拉取和探针事件；当前/上次日志定位应用启动错误；rollout 确认控制器是否完成发布。记录命名空间和控制器，避免 Pod 重建换名后丢失关联。

对应命令速查：get、describe、logs。

发布失败

kubectl -n demo rollout status deployment/web --timeout=2m
kubectl -n demo rollout history deployment/web
kubectl -n demo get deployment web -o yaml
kubectl -n demo get replicasets -l app=web
kubectl -n demo get pods -l app=web --sort-by=.metadata.creationTimestamp

检查 Progressing、Available、ReplicaFailure Conditions，比较新旧 ReplicaSet 的 PodTemplate、镜像、配置和探针。常见原因是新 Pod不可调度、readiness 不通过、配额不足或 progressDeadlineSeconds 超时。

ProgressDeadlineExceeded

命令等待超时不等于自动回滚；条件显示 ProgressDeadlineExceeded 时，新副本未在进度期限内就绪。用 describe Deployment 查看 Conditions/Events，再定位新 ReplicaSet 的 Pod 是 Pending、镜像失败还是探针失败；修复后重新观察 rollout。

预期结果是目标副本完成更新并可用，而不仅是 rollout 命令暂时没有报错。rollout 命令用于核对状态和历史。

回滚前确认数据库 Schema、ConfigMap/Secret 和外部 API 仍与旧镜像兼容。rollout undo 只恢复 PodTemplate。

Service 与网络

kubectl -n demo get service web -o yaml
kubectl -n demo get endpointslice -l kubernetes.io/service-name=web -o wide
kubectl -n demo get pods -l app=web -o wide
kubectl -n demo get networkpolicy

按顺序测试：

1. 应用是否监听预期地址（不是仅 127.0.0.1）和端口。
2. 调用方到 Pod IP 是否可达。
3. Service selector 是否匹配，EndpointSlice 是否有 Ready 端点。
4. 调用方到 Service DNS/ClusterIP 是否可达。
5. Ingress/Gateway 是否 Accepted/Resolved，Controller 与 LB 是否健康。
6. 外部 DNS、证书、WAF/LB 和源地址策略是否正确。

kubectl -n demo exec <client-pod> -- nslookup web
kubectl -n demo exec <client-pod> -- wget -S -O- http://web:80/readyz

业务镜像没有工具时使用批准的临时调试容器，不要临时在线安装并污染容器。

EndpointSlice 没有端点

比较 Service selector 与 Pod labels，并检查 Pod Ready。预期是存在匹配且就绪的后端地址；Service 对象存在本身不表示有可转发后端。

连接被拒绝

端点存在时继续核对应用监听地址、targetPort 和进程日志。恢复后从原调用方重试目标端口与业务路径，确认实际请求成功。

DNS

kubectl -n demo exec <pod> -- cat /etc/resolv.conf
kubectl -n kube-system get pods,service -l k8s-app=kube-dns -o wide
kubectl -n kube-system logs deployment/coredns --since=15m

确认是单个名称、单个节点、单个命名空间还是全局故障。NetworkPolicy 默认拒绝后常遗漏 UDP/TCP 53；大响应会回退 TCP。

存储

kubectl -n demo get pvc
kubectl -n demo describe pvc <pvc>
kubectl get pv <pv> -o yaml
kubectl get volumeattachments.storage.k8s.io
kubectl -n demo describe pod <pod>

• PVC Pending：StorageClass、制备器、配额、访问模式、拓扑。
• Attach 失败：云盘仍挂旧节点、CSI Controller、云 API权限/配额。
• Mount 失败：CSI Node、文件系统、Secret、节点路径或超时。
• 文件系统满：先停写/降流并按应用流程扩容或清理，保留证据。

不要为了“解卡”直接删 PV/PVC、VolumeAttachment 或 Finalizer；可能永久丢数据或造成多节点同时写。

节点

kubectl get nodes
kubectl describe node <node>
kubectl get pods -A --field-selector=spec.nodeName=<node> -o wide
kubectl top node <node>

关注 Ready Condition、Lease/心跳、MemoryPressure、DiskPressure、PIDPressure、NetworkUnavailable、Allocatable、镜像文件系统、容器运行时与 kubelet Event。需要宿主机证据时按平台 Runbook 查看 kubelet/runtime/journal；不要一开始就重启 kubelet或节点。

节点确认故障且业务已有冗余后，才考虑 cordon/drain，见升级与维护。

控制面与 API

kubectl get --raw='/readyz?verbose'
kubectl get --raw='/livez?verbose'
kubectl version
kubectl get apiservices
kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations

写请求超时而读请求正常时，检查准入 Webhook、etcd 和 API Server inflight/延迟。某 API Group 故障检查 APIService/CRD 和对应扩展服务。托管集群同时检查云状态页和控制面操作日志。

不要用 /livez 作为负载均衡器就绪判断；应使用 /readyz。健康端点 200 也不代表所有扩展 API 和业务控制器正常。

临时缓解与根因修复

可接受的临时措施必须明确：影响、持续时间、回退命令、负责人和后续修复。例如临时扩容、回滚已验证版本、隔离故障节点或降级非核心功能。

事故结束后：

• 恢复所有临时 scale、taint、策略和告警静默。
• 删除受控调试 Pod，轮换可能暴露的凭据。
• 保存时间线、命令、证据和用户影响。
• 将根因修复、测试、监控和 Runbook 更新落实到负责人。

注意

强制删除 Pod/Namespace、清空 Finalizer、删除 PVC/PV、直接修改 etcd 都不是常规排障步骤。这些操作可能掩盖根因、产生幽灵进程或永久丢数据，必须走灾难恢复审批和专用 Runbook。

官方资料

• Pod 排障
• Service 排障
• Deployment 条件与进度
• rollout status