清浅池塘1. 运维视角的 Kubernetes 生产故障全景
先说说我为什么想写这篇东西。在过去的几年里，我几乎每天都要和 Kubernetes 集群打交道，从单机 Minikube 到上千节点的生产集群都折腾过。真正让我觉得“这玩意儿值得好好记录”的，不是它有多复杂，而是生产环境里的故障往往不是单一原因造成的。一个 Pod 频繁重启，背后可能是镜像问题、资源配额、健康检查写错、甚至 etcd 响应变慢；而 etcd 性能劣化又会引发整个 API Server 链路的连锁反应。你会发现，表面上是个小问题，追下去却可能牵出整个集群的隐患。
这篇指南我打算按一条实战路径来组织：先从最底层的 Pod 崩溃讲起，一层层往上，到节点异常、网络问题，再到 etcd 的存储与性能调优。每一类问题我都会结合自己实际踩过的坑，把排查步骤、命令、判断逻辑和参数调整讲清楚。适合正在负责生产集群稳定性的运维工程师、SRE，也适合刚入门但想建立系统排查思路的 Kubernetes 使用者。就算你只是好奇“kubelet 到底怎么调用 containerd 的”，这里面也有对应的链路拆解。
一句话总结：这不是一本面面俱到的 Kubernetes 教程，而是一份拿过来就能用的故障排查手册。你不需要从头读，遇到问题查对应章节就行。但如果你愿意通读一遍，我相信你对集群的整体理解会上一个台阶。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 从 Pod 崩溃到稳定运行：容器生命周期排查
2.1 CrashLoopBackOff 不是随机事件，是一套状态机
Pod 频繁重启是生产环境里最常见的故障，没有之一。很多人一看到 CrashLoopBackOff 就慌，其实这个状态本身是 Kubernetes 在保护你——它检测到容器启动后反复退出，于是按指数退避策略（10 秒、20 秒、40 秒……最大 300 秒）控制重启频率，避免容器疯狂占用节点资源。这是 kubelet 在替你“踩刹车”，不是系统坏了。
排查的第一步永远是看状态和事件，而不是直接重启。我见过太多同事一上来就把 Deployment 删了重建，结果问题依旧，还丢掉了宝贵的现场证据。正确的操作顺序是这样的：
bash复制# 1. 查看 Pod 整体状态和重启次数
kubectl get pod <pod-name> -n <namespace> -o wide
# 2. 看事件，这里往往直接告诉你失败原因
kubectl describe pod <pod-name> -n <namespace>
# 3. 拿上次退出的容器日志（注意不是当前，是 --previous）
kubectl logs <pod-name> -n <namespace> --previous --tail=200
kubectl describe 输出的 Events 区域是重点排查对象。常见的失败原因就那么几类：镜像拉取失败（ImagePullBackOff）、健康检查失败（Liveness probe failed）、容器启动命令崩溃、volume 挂载报错等。拿到这些信息后再决定下一步动作，一般就能定位到根因。
这里有个容易忽略的细节：如果容器是 OOMKilled 或探针失败，kubectl describe 里会有明确标识，但如果是应用自身抛异常退出，Exit Code 才是关键线索。比如 Exit Code 137 代表被 SIGKILL（通常是 OOM 或节点驱逐），Exit Code 1 则是应用内部错误，需要结合日志判断。把这些信息串起来，再去看日志，才不会盲人摸象。
2.2 应用日志与实际退出原因对不上，是探针还是启动顺序问题
我遇到过一个比较刁钻的案例：应用日志显示正常启动，没有任何报错，但 Pod 就是不断重启。第一次排查时我盯着日志看了半天，完全没问题，后来才发现是 Liveness 探针的 initialDelaySeconds 设置太短。应用启动需要 15 秒，探针却从第 5 秒就开始探测，第 6 次失败后 kubelet 直接杀掉容器重启。日志里当然看不到任何异常，因为进程是被探针机制杀掉的。
这个案例给我的教训是：排查 CrashLoopBackOff 时，不仅要看业务日志，还要把探针配置、启动耗时、资源限制放在一起看。你可以用下面这段命令快速检查探针的配置和最近一次重启的触发原因：
bash复制# 查看探针配置
kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.spec.containers[0].livenessProbe}' | jq
# 查看容器上次终止原因和退出码
kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.status.containerStatuses[0].lastState}' | jq
如果确认是探针问题，调整方向有两个：一是把 initialDelaySeconds 设置成“应用平均启动时间 + 20% 的余量”；二是把探针的 periodSeconds 调大一点，减少探测频率，给应用留出足够的喘息空间。但不要盲目调大，探针的目的是快速发现死锁和卡死，调得太宽松就失去了意义。
2.3 kubelet 与 containerd：从请求到容器的一整条调用链路
聊到容器生命周期，就必须把 kubelet 和容器运行时之间到底怎么协作搞清楚。很多新手对“kubelet 调用 containerd”只有模糊的概念，遇到 CRI 相关报错就无从下手。我给你拆开讲一遍。
kubelet 是运行在每个节点上的代理，它的核心职责之一就是确保 Pod 里的容器按照声明运行。但它不直接使用 Docker 或 containerd 的命令行工具，而是通过 CRI（Container Runtime Interface）插件协议与容器运行时通信。这里面的关键角色是 containerd 的 CRI 插件（通常是内置的 io.containerd.grpc.v1.cri），它监听在本地的 Unix Socket 上，默认路径是 /run/containerd/containerd.sock。
kubelet 启动时会通过 --container-runtime-endpoint 指定这个 Socket 地址，然后以 gRPC 方式调用 CRI 接口。整个调用链大概是这样的：
text复制kubectl → API Server → kubelet（通过 watch 或 list-watch 获取 Pod 变更）
→ kubelet 内部的 SyncPod 流程
→ 调用 CRI 的 RunPodSandbox 接口（创建 Pod 沙箱/网络命名空间）
→ 调用 CreateContainer 接口（创建容器配置）
→ 调用 StartContainer 接口（真正启动容器进程）
→ containerd CRI 插件解析请求，通过 containerd 核心 API 操作容器
→ runc 执行容器进程
关键点在于：kubelet 不关心底层是 Docker、containerd 还是 CRI-O，只要目标运行时实现了 CRI 接口，kubelet 就能跟它通信。这也是为什么现在 Kubernetes 1.24 之后可以完全移除 dockershim 的原因——containerd 作为更轻量的运行时，直接实现了 CRI，不再需要 Docker 的中间层适配。
现场排查时，如果你怀疑 kubelet 和 containerd 之间的通信有问题，可以用 ctr 命令直接测试 containerd 本身是否正常：
bash复制# 查看 containerd 的 CRI 插件状态
ctr --address /run/containerd/containerd.sock version
# 列出当前节点上的容器（和 Pod，会带 k8s.io 前缀）
ctr --address /run/containerd/containerd.sock c list
# 查看 containerd 日志，重点关注 CRI 请求解析失败记录
journalctl -u containerd --no-pager -n 200
如果 ctr 能列出容器，说明 containerd 本身是活的，问题大概率出在 kubelet 到 containerd 的链路，比如 Socket 路径不对、权限问题、或者 kubelet 配置了错误的 --container-runtime-endpoint。此时检查 kubelet 日志：
bash复制journalctl -u kubelet --no-pager -n 200 | grep -i "container runtime"
常见的报错包括 Failed to connect to containerd、failed to get sandbox image、context deadline exceeded 等。其中 context deadline exceeded 要特别警惕，它通常意味着 containerd 响应超时，背后可能是镜像拉取慢、磁盘 I/O 瓶颈、或 containerd 本身的 goroutine 泄漏。
2.4 镜像拉取失败：别只盯着 Registry 认证
Pod 启动失败还有一个高频原因是镜像拉取失败。很多人一看到 ImagePullBackOff 就先去检查账号密码，但实际生产环境中，镜像拉取失败的原因远不止认证这一种。
拿我之前遇到过的案例来说：有一段时间我们集群里某个节点频繁出现镜像拉取超时，但其他节点完全正常。排查半天才发现，这个节点的 /var/lib/containerd 所在磁盘空间已经用到了 95%，containerd 在解压镜像层时空间不足，直接拉取失败。kubectl describe 里报的是 failed to extract layer，不看磁盘根本联想不到。
还有一次是镜像仓库的限流问题。我们在公共镜像仓库拉取同一个基础镜像，频率一高就被限流，报错信息是 toomany requests。这种问题用 imagePullPolicy: IfNotPresent 加本地缓存镜像可以缓解，但最稳妥的方案是搭建私有镜像仓库，平时把镜像同步到内网，集群只从内网拉取。
排查镜像拉取问题，我建议按照下面的顺序来：
bash复制# 1. 确认 Pod 事件里的具体报错，是认证、超时、还是 manifest 解析失败
kubectl describe pod <pod-name> | grep -A 5 "Events"
# 2. 手动拉取镜像复现问题
ctr --address /run/containerd/containerd.sock images pull <image-name>
# 3. 检查 containerd 的镜像存储空间
df -h /var/lib/containerd
特别注意一下：如果你用的是私有仓库且开启了 TLS，镜像仓库的证书过期也会导致拉取失败。报错往往是 x509: certificate has expired or is not yet valid，很多人第一反应是改 containerd 配置跳过验证，但那是下策。正确做法是更新节点的 CA 证书，并使用 registry.mirrors 或 config_path 配置仓库的 TLS 信任。
2.5 Pod 一直 Pending：调度器在说什么悄悄话
Pod 卡在 Pending 状态，说明调度器还没把它绑定到节点上。这通常不是容器运行问题，而是资源、标签、污点或亲和性配置不满足。排查方式依然是先看事件：
bash复制kubectl describe pod <pod-name> -n <namespace>
常见的事件有：
0/x nodes are available: insufficient cpu：节点 CPU 资源不足。0/x nodes are available: 1 node(s) had untolerated taint：节点有污点，Pod 没有对应的容忍。0/x nodes are available: node(s) didn't match pod anti-affinity rules：反亲和性规则把节点都排除了。
如果是资源不足，别急着加节点，先看看是不是有 Pod 的 resource request 设置得过高。我见过有人把 CPU request 设成 10 核，结果 16 核的节点上只能调度 1 个 Pod，其他全部 Pending。调整 request 值到合理范围，再配合 Pod 的优先级和抢占策略，调度效率会好很多。
污点和容忍度的问题也比较多。节点打上 dedicated=infra:NoSchedule 这类污点后，只有带对应容忍度的 Pod 才能调度上去。有些同学把污点打在节点上，却忘了给关键 DaemonSet 加容忍度，结果整个集群的日志采集和监控组件全挂，排查起来一头雾水。记住一条规则：节点打污点之前，先想清楚哪些系统组件必须有容忍度，否则先别打。
3. 从节点异常到集群瘫痪：中间层故障
3.1 节点 NotReady 的第一现场与第二现场
节点状态变为 NotReady，是集群层面的重大故障信号。生产环境里，NotReady 的典型诱因包括 kubelet 挂掉、网络插件故障、节点磁盘满、负载过高导致 kubelet 无法上报心跳等。排查思路要区分“第一现场”和“第二现场”。
第一现场：登录到这个节点上，先看 kubelet 是否存活、状态是否正常：
bash复制systemctl status kubelet
journalctl -u kubelet --no-pager -n 200 | tail -50
如果 kubelet 反复重启，日志会显示 panic 或 fatal error。常见的致命错误包括：审计日志目录权限不对、kubelet 证书过期、containerd socket 连接不上等。看完 kubelet 再看节点资源状态：
bash复制df -h /var/lib/kubelet
free -h
uptime
磁盘 100% 满会导致 kubelet 无法创建临时文件，直接进入只读状态；内存耗尽会触发系统 OOM，kubelet 本身也可能被杀掉。这类问题的处理方式是先扩容或清理，恢复节点资源，再重启 kubelet。
第二现场：如果单节点看起来正常，但集群 API Server 依然无法更新节点状态，可能是 kubelet 到 API Server 的网络链路有问题。检查 kubelet 日志里的上报错误，或者直接在这个节点上测试 API Server 连通性：
bash复制kubectl --kubeconfig=/etc/kubernetes/kubelet.conf get --raw=/healthz
如果 API Server 地址从节点上无法访问，那就是防火墙、安全组、或节点到 API Server 之间的负载均衡出问题了。别在节点上反复重启 kubelet，那是浪费力气。
3.2 网络插件异常导致节点之间互相看不见
Kubernetes 集群依赖 CNI 网络插件来打通 Pod 之间的通信。常见的 CNI 包括 Calico、Cilium、Flannel。当网络插件出问题时，最典型的现象是 Pod 能起来，但跨节点通信失败，DNS 解析超时，Service 访问不通。
排查 Calico 类问题时，我通常会先看 Pod 状态和 Felix 日志：
bash复制kubectl get pods -n kube-system -l k8s-app=calico-node -o wide
kubectl logs -n kube-system calico-node-<id> -c calico-node --tail=100
如果 Felix 日志里大量出现 BGP connection established 后又被断开，多半是节点之间的 BGP 端口（默认 179）被安全组挡了。跨云环境里，这种问题特别隐蔽，因为 Kubernetes 组件都正常，Pod 也能启动，但节点之间的路由根本学不到。检查云厂商的安全组和 VPC 路由表是关键。
Cilium 的问题则经常出现在 eBPF 程序加载失败或内核版本不兼容上。升级内核或发行版后，Cilium 的 Agent 可能无法初始化。此时用 cilium status 查看整体健康状态，再根据告警逐项排查：
bash复制kubectl exec -n kube-system <cilium-pod> -- cilium status
我踩过的一个坑是：节点上开启了 IPv6 但内核模块没加载，导致 Cilium 初始化失败，所有 Pod 网络异常。这提醒我们，在部署 CNI 之前，一定要先核对内核版本和系统参数，很多东西在部署文档里写得清楚，但实际运维时很容易跳过。
3.3 CoreDNS 的“看似正常，实际有问题”
CoreDNS 作为集群内部的 DNS 服务，一旦出问题，影响是全局性的。很多服务间调用的失败，根因是 DNS 解析慢或超时。
CoreDNS 故障分几种层次。一种是 Pod 本身 CrashLoopBackOff，通过常规排查就能发现。另一种是 Pod 正常运行，但解析性能极差，这就要看 CoreDNS 的实例数量和资源限制。
我处理过一个具体案例：集群从 50 个节点扩到 200 个节点后，服务间的调用延迟骤增，但 CoreDNS Pod 的 CPU 使用率并不高，也没有报错。后来仔细分析才发现，CoreDNS 副本数只有 2，但部署的每个应用都在启动时会解析大量外部域名，因为 ndots:5 的默认配置，每解析一个域名都要先尝试多个 search domain，导致 DNS 查询量爆炸。
解决方案有两步。第一步，调整 CoreDNS 的副本数，并用 PDB（PodDisruptionBudget）保护，kubectl scale deployment/coredns -n kube-system --replicas=3。第二步，优化应用的 DNS 配置，把 ndots 改成合适的值，或者直接用 FQDN 访问服务，减少无效查询。这里要注意：ndots 不能盲目调低，否则短域名解析会受影响，最佳实践是结合应用实际使用的域名类型做针对性配置。
4. 存储与元数据层：etcd 的日常运维与故障应对
4.1 etcd 挂了，整个集群就“僵住”了
如果说 kubelet 是集群的肌肉，那 etcd 就是大脑。所有的资源状态、配置信息、集群元数据都存在 etcd 里。etcd 不可用，API Server 就无法读写集群状态，整个 Kubernetes 控制面就变成只读或者干脆拒绝服务。
etcd 故障的典型表现是：kubectl 命令卡住，kubectl get nodes 超时，API Server 日志里全是 etcdserver: request timed out 或 etcdserver: leader changed。
当你确定 etcd 出问题时，先别急着操作，按下面的步骤确认现状：
bash复制# 1. 查看 etcd 集群成员状态（从 API Server 所在节点执行）
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint health --cluster
# 2. 查看 etcd 集群成员列表
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
member list
这里要提醒一点：在执行 etcdctl 命令之前，先把 ETCDCTL_API=3 设置好，否则可能默认走 v2 API，直接报错。
如果只有一个副本的 etcd 挂了，要谨慎处理。生产环境建议至少 3 个副本，这样单个副本故障不会丢数据，集群也能正常工作。但如果你的集群本来就只有单副本，挂掉后最稳妥的办法是用备份恢复，而不是尝试“原地重启”。原地重启如果数据目录损坏，只会让问题更严重。
4.2 旧数据目录导致启动失败：一个容易被忽略的坑
这是我在实际运维中踩过的一个比较典型的坑：etcd 节点因为某种原因被迫重新初始化，但它的数据目录里还残留着旧数据。启动的时候，etcd 可能会因为数据和新的集群成员信息不一致而起不来，报错信息往往是 etcdserver: apply request took too long 或者直接 failed to start。
比如你重建了一个 etcd 节点，加入了新的集群，但 /var/lib/etcd 里还有旧集群的数据。这个新旧数据混杂的状态非常危险，最典型的现象是：某个 etcd 节点启动后一直报 wal: file does not exist 或者数据校验失败，导致整个集群的 quorum 被破坏。
处理方法要分场景：
- 如果这个节点是要重新加入一个已有的健康集群，最干净的做法是清空该节点的数据目录，让它从集群重新同步数据。同步命令可以参考：
bash复制# 在 etcd 节点上停止 etcd 服务
systemctl stop etcd
# 备份旧数据目录（强烈建议，不要一上来就删）
mv /var/lib/etcd /var/lib/etcd.bak.$(date +%Y%m%d%H%M%S)
# 确保新目录权限和属主正确
mkdir -p /var/lib/etcd
chown etcd:etcd /var/lib/etcd
# 重新启动 etcd，正常情况下它应该从集群中的其他节点全量同步数据
systemctl start etcd
- 如果整个集群都已经不可用，只剩单副本数据，那就得靠备份恢复。这要求你平时就做了 etcd 的定期快照。没有备份的情况下单副本数据损坏，基本只能接受部分丢失。
这个坑的关键教训是：etcd 节点重启之前，一定要先搞清楚“这个节点要扮演什么角色”——是重新加入现有集群，还是作为新集群的一部分。角色不同，数据目录的处理方式完全不一样。盲目保留旧目录，等于埋了一颗定时炸弹。
4.3 etcd 性能瓶颈：怎么定位、怎么调优
etcd 是集群里的性能敏感组件，尤其对磁盘延迟极其敏感。当集群规模变大，或者 API Server 的请求量上来后，经常出现 etcd 响应变慢、leader 频繁切换的情况。
判断 etcd 是否遇到性能瓶颈，可以关注以下几个指标：
etcd_server_leader_changes_seen_total：leader 切换次数。如果在短时间内频繁切换，通常说明 leader 节点磁盘 I/O 能力不足。etcd_disk_wal_fsync_duration_seconds：WAL 文件 fsync 耗时。etcd 在写入任何数据前都要先同步到 WAL，这个值如果 P99 超过 100ms，基本可以断定磁盘性能跟不上。etcd_server_heartbeat_send_failures_total：心跳发送失败次数，持续增长说明网络延迟或 CPU 紧张。
定位到 etcd 性能差后，调优从硬件和配置两个维度入手。硬件维度：
- 使用 SSD 或 NVMe，不要用机械硬盘。etcd 对磁盘随机写入和 fsync 性能要求极高，这是硬件底线。
- 将 WAL 目录和数据目录分开放到不同的磁盘上。WAL 是追加写模式，数据目录的读写模式不同，分开可以避免互相争抢 I/O。
配置维度：
--snapshot-count：默认 100000 表示每 100000 次事务触发一次快照。如果数据量很大，可以把快照间隔调大（比如 500000），减少快照落盘时的 I/O 抖动，但快照间隔越大，恢复时需要重放 WAL 越长，需要权衡。--heartbeat-interval和--election-timeout：默认分别是 100ms 和 1000ms。如果集群网络延迟偏高，可以适当调大 heartbeat，避免频繁触发选举。比如 200ms 和 2000ms 的组合是我在中等规模集群里常用的配置。--quota-backend-bytes：默认 2GB，如果集群元数据量大，可以调大到 8GB 或更高。超过配额后 etcd 会拒绝写入，必须提前规划。
数据库整理方面，etcd 的 compaction 和 defrag 是运维里的必修课。对象数量不断增长，etcd 后端存储的碎片化会越发严重。具体建议：
bash复制# 查看当前 etcd 后端数据库大小
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint status --write-out=table
# 手动压缩所有历史版本（保留最近 10 分钟的数据）
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
compact $(date -d '-10 minutes' +%s%N)
# 对每个 etcd 节点执行碎片整理
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
defrag
注意：compact 是全局操作，在任一节点执行即可。但 defrag 必须针对每个节点单独执行，并且会短暂阻塞该节点的读写操作，建议在业务低峰期做。
4.4 etcd 备份与恢复：没有备份的 etcd 不是生产环境
讲调优之前，我更想先强调备份。生产环境里，etcd 备份是最后的安全网。etcd 的备份可以用 etcdctl 的 snapshot 命令完成：
bash复制ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
snapshot save /backup/etcd-snapshot-$(date +%Y%m%d%H%M%S).db
备份文件要定期拷贝到独立的存储，至少保留最近 7 天的快照。恢复流程不要等到灾难发生时才想，平时就要在测试环境演练一遍。恢复的核心步骤是：
bash复制# 1. 在目标节点恢复快照到指定数据目录
ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd-snapshot-<date>.db \
--data-dir=/var/lib/etcd-restore \
--name=<节点名> \
--initial-cluster=<节点名>=https://<节点IP>:2380 \
--initial-advertise-peer-urls=https://<节点IP>:2380 \
--initial-cluster-token=<新的token>
# 2. 修改 etcd 配置指向恢复出的数据目录
# 3. 启动 etcd 并验证
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key \
endpoint health
恢复时特别容易踩的坑是成员名称不一致。--name 必须和 etcd 配置里的节点名匹配，否则集群成员列表会混乱。而且恢复后的集群要使用新的 --initial-cluster-token，避免和旧集群的元数据冲突。
5. 生产故障速查表与高频问题处理清单
5.1 高频故障分类速查
根据我自己的经验，Kubernetes 生产环境里大约 80% 的故障集中在下面这些类型。把它们整理成一张速查表，遇到问题时先对着表格自查一遍，往往能省下不少时间。
| 故障现象 | 常见根因 | 第一步排查命令 |
|---|---|---|
| Pod 反复 CrashLoopBackOff | 探针失败、启动崩溃、OOM | kubectl describe pod + kubectl logs --previous |
| Pod 卡 Pending | 资源不足、污点、亲和性 | kubectl describe pod 查看事件 |
| 节点 NotReady | kubelet 故障、磁盘满、网络插件 | journalctl -u kubelet + df -h |
| Service 访问不通 | Endpoints 为空、kube-proxy 异常 | kubectl get endpoints |
| DNS 解析超时 | CoreDNS 副本不足、ndots 配置 | kubectl get pods -n kube-system -l k8s-app=kube-dns |
| etcd 请求超时 | 磁盘 I/O 慢、leader 切换 | etcdctl endpoint health |
| 镜像拉取失败 | 仓库认证、磁盘空间、限流 | kubectl describe pod 查看事件 |
| kubelet 证书过期 | 证书未自动轮换 | `journalctl -u kubelet |
| API Server 响应慢 | etcd 性能、请求量过大 | kubectl get --raw /metrics 看 apiserver 指标 |
| 污点未容忍 | 节点调度不上去 | kubectl describe node 查看 Taints |
这张表的作用是帮你快速锁定方向，别在错误的方向上浪费太多时间。定位到具体原因后，再回到前面对应章节做深入排查。
5.2 排查过程中最容易翻车的几个操作
有些操作在故障时看起来“应该做”，但实际操作会带来更大的麻烦。这里集中列出来，算是给大家提个醒。
第一，不要在没搞清楚根因的情况下直接删除 Pod。Pod 重建后会从镜像仓库重新拉取镜像，如果镜像仓库本身有问题，重建只会增加压力。而且删除 Pod 的同时会丢失现场事件信息，后面再排查就要靠猜了。
第二，不要去生产 etcd 节点上跑 defrag 或 compact 这类重量级操作，除非你已经确认当前是业务低峰期。defrag 会阻塞 etcd 的读写，在高负载时段执行可能导致整个集群不可用。我在测试环境试过，一个 2GB 的 etcd 数据文件，defrag 需要 10 到 20 秒，期间所有写请求全部排队。
第三，不要随意修改 kubelet 或 containerd 的关键配置。比如把 --container-runtime-endpoint 改错了，kubelet 会直接连不上运行时，所有 Pod 都会被标记为失败。修改前先备份原配置，并确保在维护窗口执行。
第四，不要忽略集群事件保留时间。默认情况下，Pod 事件只保留 1 小时，kubectl describe pod 里能看到的事件信息非常有限。如果需要追溯更长时间的故障，建议部署事件采集工具（比如 Kubernetes 事件持久化方案），把事件写入 Elasticsearch 或其他存储中，方便事后分析。
5.3 运维习惯：让下次故障好查一点
处理了这么多故障，我最深的体会是：排查效率的高低，很大程度上取决于平时积累了哪些可观测性数据。一个没有监控、没有日志采集、没有事件持久化的集群，出问题时就像摸着黑走迷宫，每一步都靠猜。
所以我强烈建议，在集群上线前就把下面三件事做好：
第一，部署监控系统。至少覆盖节点层面（CPU、内存、磁盘 I/O、网络流量）、Pod 层面（CPU、内存、网络、文件系统）、etcd 层面（leader 切换、WAL fsync 延迟、db 大小）这三个维度的指标。不用一步到位上全链路，先把核心组件盯住。
第二，统一日志采集。Kubernetes 里 Pod 是随时可能被调度的，日志不能只存在本地，否则 Pod 被重建后日志就没了。用 DaemonSet 方式部署日志采集器，把 /var/log/containers/*.log 收集到集中存储，排查问题时会轻松很多。
第三，做好资源配额管理。给每个 Namespace 设置 ResourceQuota，给每个 Deployment 设置合理的 request 和 limit。一个没有资源限制的集群，一旦某个应用发生内存泄漏，可能会拖垮整个节点，进而引发级联故障。这也是我在生产环境里最常提醒团队的一点。
6. 一点个人体会
写到最后，说点题外话。Kubernetes 的故障排查，表面上是在跟各种报错信息斗智斗勇，实际上考验的是对整个系统架构的理解。很多人遇到问题喜欢到处搜命令，搜到一条就试一条，这种“乱枪打鸟”的方式效率极低，而且容易错过真正的根因。
我的经验是：每遇到一个故障，先花几分钟想清楚这个组件在整条链路里的位置，它依赖什么、被谁依赖，然后顺着链路逐层排查。比如 Pod 起不来，你的思路应该是：API Server 有没有把这个 Pod 写入 etcd → 调度器有没有选到节点 → kubelet 有没有收到通知 → kubelet 有没有成功调用 containerd → containerd 有没有拉镜像、创建容器 → 容器进程有没有正常启动。链路理清了，问题就藏不住。
另外，维护 Kubernetes 集群，保持敬畏心很重要。生产环境里我见过太多事故，都是因为某个看起来“无害”的操作引起的。改配置之前备份，重启节点之前做好 Pod 驱逐规划，清理数据目录之前确认角色。这些习惯听起来繁琐，但在关键时刻能救命。
如果这篇指南能帮你在下一次故障排查时少走几步弯路，那就不算白写。