K8s 生产排障实战

• apiserver 指标
• etcd 延迟
• 审计日志

排障三步：1）apiserver 指标：看 apiserver_request_duration_seconds、apiserver_request_total、apiserver_current_inflight_requests 等，识别慢请求类型（list-heavy 大对象）、高延迟、限流（429）。2）etcd 延迟：看 etcd 的 wal_fsync、backend_commit、grpc 延迟，etcd 慢会导致 apiserver 写慢；检查 etcd 磁盘、leader 状态、quorum。3）审计日志：定位具体慢请求的资源与 verb，找出大规模 list/watch（如无 label 的全量 list）。结合三层缩小范围：先看指标确认 apiserver 是否受限，再查 etcd 是否慢，最后用审计定位具体请求。

核心是"指标→etcd→审计三层缩小瓶颈"。常见元凶是 list-heavy 大对象与 etcd 慢。

• CrashLoopBackOff 含义
• 逐项排查
• 各因素

CrashLoopBackOff 表示容器反复崩溃重启。排查路径：1）看事件 kubectl describe pod（CrashLoopBackOff、Back-off restarting）；2）看日志 kubectl logs --previous（上次崩溃日志）；3）检查镜像：镜像是否存在、tag 是否正确、启动命令是否错误；4）检查探针：liveness/readiness 探针失败导致容器被杀；5）检查启动命令/入口：应用启动参数错误、缺依赖；6）检查依赖服务：数据库/配置中心不可达导致启动失败；7）检查资源限制：OOM 被杀（看 OOMKilled 状态）。逐项用 describe+logs+事件定位。

核心是"describe+logs 多方位排查"。用 --previous 看崩溃前日志，用 describe 看事件与探针。

• OOMKilled 原因
• requests/limits 设定
• JVM 容器感知

OOMKilled 表示容器内存超过 limits 被内核 OOM 杀掉。治理：1）合理设置 limits（过高导致节点超卖，过低导致 OOM）；2）JVM 应用需容器感知（用 -XX:+UseContainerSupport、-XX:MaxRAMPercentage，避免 JVM 堆超过容器 limits）；3）区分内存泄漏与突发流量：内存泄漏是持续增长不回落（用监控看内存曲线、heap dump 分析），突发是瞬时高峰（多副本/缓存/GC 调整）。定位：看事件 OOMKilled、dmesg、监控内存趋势、heap dump。优化：调大 limits、限流、分批、优化代码。

核心是"OOM 原因 + 合理 limits + JVM 容器感知 + 泄漏/突发区分"。JVM 需容器感知避免超限。

• Pending 排查
• CrashLoopBackOff 排查
• ImagePullBackOff 排查

Pending：调度未完成，看 kubectl describe pod 事件（Unschedulable、节点资源不足、污点/亲和、PVC 绑定失败），kubectl get nodes 看资源。CrashLoopBackOff：容器崩溃重启，看日志（--previous）与事件（探针失败、OOM、启动命令错误）。ImagePullBackOff：镜像拉取失败，看事件（认证失败、镜像不存在、网络、registry 限流），kubectl describe pod 的 ImagePull 事件，kubectl get events，检查 imagePullSecrets、镜像 tag、registry 可达性。三者的入口都是 kubectl describe pod 的事件与日志。

核心是"先 describe 看事件，再按类别定位"。Pending 看调度，CrashLoop 看日志，ImagePull 看拉取。

• Endpoints 检查
• kube-proxy
• CNI

Service 不通排查：1）Endpoints：kubectl get endpoints 确认后端 Pod IP 存在且 Ready；2）kube-proxy：确认 kube-proxy 运行、iptables/IPVS 规则是否正确（iptables -L/ipvsadm）；3）CNI：确认 Pod 网络正常、跨节点连通；4）NetworkPolicy：是否有策略阻断；5）DNS：确认 Service 名解析正确（nslookup）、CoreDNS 正常。从集群内 curl ClusterIP/Service 名逐层测试，定位断点。

核心是"逐层验证 Endpoints→kube-proxy→CNI→NetworkPolicy→DNS"。逐层缩小范围。

• cordon/drain/uncordon 流程
• drain 各 flag 风险
• PDB 阻止驱逐

维护流程：cordon 标记不可调度（不调度新 Pod）→ drain 驱逐现有 Pod（-ignore-daemonsets 保留 DaemonSet Pod、--delete-emptydir-data 允许删除 emptyDir 数据 Pod、--force 强制删除非 ReplicaSet 管理的 Pod、--disable-eviction 用 delete 而非 eviction）→ 维护后 uncordon。drain 顺序：先驱逐普通 Pod，按 PDB 检查。PDB 阻止驱逐导致 drain 卡住：若驱逐后可用副本低于 PDB minAvailable，驱逐被拒，drain 挂起。定位：看 drain 输出 "evicting via eviction API" 与 PDB 冲突，kubectl get pdb 看可用数，临时调低 PDB 或使用 --force。各 flag 风险：--force 可能导致非托管 Pod 数据丢失；--delete-emptydir-data 删除本地数据。

核心是"cordon/drain/uncordon + PDB 约束 + flag 风险"。drain 卡住常因 PDB 约束。

• 节点压力驱逐
• QoS 等级
• 驱逐顺序

节点压力驱逐（node-pressure eviction）是 kubelet 在节点资源（内存、磁盘、PID）压力下主动驱逐 Pod 释放资源。驱逐顺序按 QoS 等级：BestEffort 最先，其次 Burstable（按超限/use 程度），Guaranteed 最后（且仅当超过 limits 才被驱逐）。kubelet 基于 eviction 阈值（memory.available、nodefs.available、imagefs、pid）触发，并可能将节点标记为 MemoryPressure/EvictionThresholdMet。被驱逐的 Pod 状态为 Evicted，由控制器重建。QoS 越高越不易被驱逐。

核心是"QoS 决定驱逐顺序：BestEffort→Burstable→Guaranteed"。Guaranteed 最稳定。

• describe 事件
• 容器日志
• init 容器

Pod 启动失败排查：1）kubectl describe pod 看事件（调度失败、镜像拉取、探针、重启）；2）kubectl logs 看主容器日志（启动错误）；3）查看 init 容器：kubectl logs <pod> -c <init-container> 与状态（init 容器失败会阻塞主容器），init 容器用于初始化（如等待依赖、下载配置）；4）检查 init 容器完成状态（Completed 才能启动主容器）。逐层：事件→主容器日志→init 容器日志→依赖。init 容器失败是常见原因，会一直 Pending 或 CrashLoop。

核心是"describe+主容器日志+init 容器 逐层定位"。init 容器失败会阻塞主容器。

• kubectl debug 命令
• 临时容器
• 精简镜像排障

精简镜像常无 shell，无法 exec 进容器排障。kubectl debug 可给 Pod 添加临时容器（ephemeral container）运行排障工具镜像（如 --image=nicolaka/netshoot），进入该容器执行诊断命令，而不影响原容器。临时容器与 Pod 同网络命名空间，可查看网络、进程、文件。用法：kubectl debug -it <pod> --image=brokentool（复制 Pod 加 debug 容器）或 kubectl debug --target=<pod> -it --image=...（给现有 Pod 加临时容器）。临时容器在 Pod 删除前存在，可共享进程命名空间（--share-processes）。

核心是"临时容器注入排障工具到原 Pod"。解决精简镜像无 shell 的排障。

• PLEG 卡死
• CNI 调用失败
• 镜像拉取超时

节点级故障看 kubelet 日志（journalctl -u kubelet）。1）PLEG 卡死：日志报 "PLEG is not healthy"、容器状态获取超时，常因容器运行时异常、磁盘 I/O 阻塞；恢复：重启容器运行时/kubelet，排查磁盘。2）CNI 调用失败：日志报 CNI 错误、Pod 网络配置失败，检查 CNI 插件（calico/cilium）状态、网络配置；恢复：重启 CNI 组件。3）镜像拉取超时：日志报 ImagePull timeout，检查 registry 网络、DNS、镜像大小；恢复：重试或修网络。快速定位用 grep 关键字，看时间戳与上下文。

核心是"按日志关键字定位节点故障"。PLEG 卡死、CNI 失败、镜像超时是典型三类。

• 证书轮换
• RotateKubeletServerCertificate
• NotReady 排查

kubelet 证书过期或轮换失败会导致节点无法与 apiserver 通信，反复 NotReady。排查：1）看 kubelet 日志（证书过期、x509 错误）；2）检查 /var/lib/kubelet/pki 证书有效期；3）检查 CSR 是否被批准（kubectl get csr）；4）检查 RotateKubeletServerCertificate 与 RotateKubeletClientCertificate feature gate 是否开启（kubelet 自动轮换）。配置：kubelet 启用了 --rotate-certificates（客户端证书轮换）与 --rotate-server-certificates（服务端证书轮换，需 RotateKubeletServerCertificate feature）。修复：手动批准 CSR、重启 kubelet、替换过期证书。

核心是"证书轮换失败导致 NotReady + 检查 CSR/有效期/feature gate"。轮换需 CSR 批准。

• NPD 检测机制
• NodeCondition vs Event
• 告警语义

node-problem-detector（NPD）以 DaemonSet 运行在每个节点，检测内核死锁（kernel log）、容器运行时异常、网络问题等，通过系统日志与监控。检测到问题后上报两种方式：NodeCondition（节点状态，如 KernelDeadlock、MemoryPressure）反映节点持续异常状态，参与调度与驱逐决策；Event（一次性事件）反映短暂问题，用于告警通知。NodeCondition 是"状态"（持续），Event 是"事件"（瞬时），语义不同：NodeCondition 影响节点可用性，Event 用于触发告警。NPD 可配合自定义监控。

核心是"NodeCondition 是状态、Event 是事件"。NPD 检测节点级问题。

• kubelet 日志
• 容器运行时
• CNI

Pod 网络不通三层定位：1）kubelet 日志：看 Pod 是否创建成功、CNI 调用是否报错（journalctl -u kubelet）；2）容器运行时（containerd/CRI）：检查容器网络命名空间（crictl ps、crictl inspect），确认 Pod 网络接口是否创建；3）CNI：检查 CNI 插件（calico/cilium）的 Pod 与日志、IP 分配、路由、tunnel 状态。从"Pod 是否拿到 IP"→"跨节点是否通"→"路由/安全策略"逐层验证。用 exec 进容器 ping、traceroute 辅助。

核心是"kubelet→运行时→CNI 三层定位"。逐步确认网络配置与连通性。

• NotReady 常见原因
• kubelet/PLEG/磁盘/证书
• 驱逐连锁影响

节点 NotReady 常见原因：1）kubelet 异常（未运行、崩溃）；2）PLEG 卡死（容器运行时无响应）；3）磁盘压力（DiskPressure，节点被标记不可调度）；4）证书过期（kubelet 无法与 apiserver 通信）。连锁影响：节点 NotReady 后，apiserver 等待 node-monitor-grace-period（默认 40s）后标记 NotReady，再过 pod-eviction-timeout（默认 5 分钟）后，控制器在别的节点重建 Pod（受 PDB 约束）。若同时有磁盘压力，节点可能驱逐 Pod 并只读。连锁：NotReady→Pod 被驱逐→依赖该节点数据的 Pod 故障。

核心是"NotReady 原因 + 驱逐时间线 + 连锁影响"。等待窗口后 Pod 被重建。

• 认证失败
• 镜像不存在
• digest 不匹配

镜像拉取失败用 kubectl describe pod 的 ImagePullBackOff 事件与容器运行时日志区分。认证失败：错误 "unauthorized/authentication required"，检查 imagePullSecrets 与 registry 凭据。镜像不存在：错误 "manifest unknown/not found"，检查 tag 是否打错。digest 不匹配：错误 "digest mismatch/manifest digest did not match"，镜像被篡改或 tag 变化，改用 digest 拉取。拉取限流：错误 "toomanyrequests/rate limit exceeded"，registry 限流，稍后重试或换拉取策略。看事件 message 区分。

核心是"事件 message 区分四类失败"。认证/不存在/digest/限流各有典型错误。

• Unschedulable 事件
• 污点容忍
• 节点资源

Pod 调度失败排查：1）kubectl describe pod 看 Unschedulable 事件与原因（0/3 nodes are available: ...）；2）节点资源：确认节点资源不足（cpu/memory insufficient）；3）污点容忍：节点有污点而 Pod 无对应容忍，加 tolerations；4）亲和规则：nodeSelector/nodeAffinity 不匹配、podAntiAffinity 冲突；5）拓扑约束、PDB、PVC 绑定。逐项验证：看事件原因→检查节点资源→检查污点→检查亲和。用 kubectl get nodes 与 kubectl describe node 看资源与污点。

核心是"事件原因逐项核对资源/污点/亲和"。Unschedulable 事件给出具体原因。

• 事件定位
• Admission 日志
• 配额占用

ResourceQuota/LimitRange 导致 Pod 无法创建：1）事件：kubectl describe 或 get events 看 "exceeded quota"/"failed to create"；2）Admission 日志：apiserver 的 admission 日志显示 quota 拒绝原因（exceeded quota, requested: ..., used: ...）；3）配额占用：kubectl get resourcequota -n ns 看 currently used 与 hard，确认是否占满；kubectl get limitrange 看容器级约束。定位后调整配额或降低 Pod 资源请求。

核心是"事件+Admission 日志+配额占用三处定位"。quota 超限是常见拒绝原因。

• PV/PVC 状态
• CSI 驱动日志
• kubelet 卷管理器

存储挂载失败排查：1）PV/PVC 状态：kubectl get pvc/pv 看是否 Bound、StorageClass 是否正确、访问模式；2）CSI 驱动日志：kubectl logs <csi-driver> 看 ControllerPublish/NodePublish 错误；3）kubelet 卷管理器：看 kubelet 日志（attach/detach/mount 错误）、df/mount 确认是否挂载。定位顺序：PVC 是否 Bound→CSI 是否成功供给挂载→kubelet 是否实际挂载进容器。常见原因：StorageClass 不存在、节点不满足拓扑、CSI 驱动异常、Permissions。

核心是"PVC→CSI→kubelet 卷挂载逐层定位"。三层都需检查。

• DiskPressure 触发
• 驱逐与只读
• 治理（镜像/日志/emptyDir）

DiskPressure 是节点磁盘使用率超过阈值，kubelet 标记节点并驱逐 Pod，进一步可能使节点只读（eviction 阈值达到）。排查：1）df -h 看磁盘；2）镜像堆积：crictl images/crictl rmi 清理未用镜像（镜像 GC 阈值）；3）日志增长：容器日志占用（配 log rotation、限制日志大小）；4）emptyDir 占用：emptyDir 写大量数据（限制用量、迁移到持久卷）。治理：调镜像 GC 阈值、配置日志轮转、限制 emptyDir 大小、清理缓存。定位根因后释放磁盘空间即可恢复。

核心是"DiskPressure 触发驱逐/只读 + 镜像/日志/emptyDir 治理"。从磁盘占用源头治理。

• CoreDNS 副本状态
• forward 配置
• ndots 搜索域

DNS 故障排查：1）CoreDNS 副本状态：kubectl get pods -n kube-system -l k8s-app=kube-dns 看 Running，kubectl logs 看错误；2）上游 forward 配置：CoreDNS 的 forward 到上游 DNS（如 /etc/resolv.conf），若上游不可达则解析慢/失败；3）ndots 搜索域：Pod 的 /etc/resolv.conf 有 ndots:5 与多个 search 域，导致短域名解析需先尝试多个搜索域（每加一个域就多一次 DNS 查询），增加延迟。优化：减少搜索域、调整 ndots（如 ndots:1）、使用 FQDN 直接解析。测试用 nslookup/dig 看搜索域尝试次数。

核心是"CoreDNS 状态 + forward 上游 + ndots 搜索域延迟"。ndots 影响解析延迟。

• etcd 备份
• 版本兼容
• 回滚策略

集群升级预案：1）etcd 备份：升级前 etcdctl snapshot save 备份 etcd，确保可回滚；2）版本兼容：确认各组件版本兼容矩阵（apiserver/scheduler/controller 同版本，kubelet 可低一个次版本），迁移弃用 API；3）回滚策略：升级失败时先降级 worker 再降 control plane，用备份恢复 etcd；4）升级步骤：先升级 control plane，验证后逐批升级 worker，回滚预案准备。升级前先在测试环境验证。etcd 备份是回滚的关键保障。

核心是"备份 etcd + 版本兼容 + 分步升级与回滚"。etcd 备份保障回滚。