Kubernetes 生产级故障排查：从 Pod 崩溃到 etcd 性能调优的实战指南

Kubernetes 生产级故障排查：从 Pod 崩溃到 etcd 性能调优的实战指南

导读：在生产环境中，Kubernetes 集群的稳定性直接关系到业务的连续性。本文基于多年一线运维经验，系统梳理 Pod、Service、Node、存储、镜像、集群性能、etcd 等核心组件的故障排查思路，强调 \”先看状态 → 再看事件 → 最后定位根因\” 的工程化方法，助你从容应对 K8s 面试与生产故障。

一、故障排查方法论：三层递进式诊断

1.1 核心思路

┌─────────────────────────────────────────────────────────────┐
│ Kubernetes 故障排查三层模型 │
├─────────────────────────────────────────────────────────────┤
│ 第一层：状态层 (Status) → kubectl get 快速定位异常资源 │
│ 第二层：事件层 (Events) → kubectl describe 查看资源事件流 │
│ 第三层：根因层 (Root Cause) → logs/exec/debug 深入诊断 │
└─────────────────────────────────────────────────────────────┘

1.2 排障黄金命令清单

# 状态层 – 快速扫描
kubectl get pods -A –field-selector status.phase!=Running
kubectl get events –sort-by=\’.lastTimestamp\’
kubectl top nodes
kubectl top pods -A

# 事件层 – 深度查看
kubectl describe pod <pod-name> -n <namespace>
kubectl get events –field-selector involvedObject.name=<pod-name>

# 根因层 – 精准定位
kubectl logs <pod-name> -c <container-name> –previous
kubectl exec -it <pod-name> — /bin/sh
kubectl debug -it <pod-name> –image=nicolaka/netshoot

二、Pod 故障排查：从 Pending 到 CrashLoopBackOff

2.1 Pod 常见状态及含义

2.2 实战案例：CrashLoopBackOff 排查

场景：某微服务 Pod 持续重启，状态为 CrashLoopBackOff

# Step 1: 查看 Pod 状态
$ kubectl get pod payment-service-7d8f9c6b5-x2k4m -n prod
NAME READY STATUS RESTARTS AGE
payment-service-7d8f9c6b5-x2k4m 0/1 CrashLoopBackOff 15 45m

# Step 2: 查看 Pod 详情和事件
$ kubectl describe pod payment-service-7d8f9c6b5-x2k4m -n prod
Events:
Type Reason Age From Message
—- —— —- —- ——-
Normal Scheduled 45m default-scheduler Successfully assigned prod/payment-service-7d8f9c6b5-x2k4m to node-01
Normal Pulled 45m kubelet Container image \”registry.example.com/payment:v1.2.3\” already present on machine
Normal Created 45m kubelet Created container payment
Normal Started 45m kubelet Started container payment
Warning BackOff 2m (x187 over 44m) kubelet Back-off restarting failed container

# Step 3: 查看容器日志（关键！）
$ kubectl logs payment-service-7d8f9c6b5-x2k4m -n prod –previous
Exception in thread \”main\” java.lang.IllegalStateException:
Could not find a valid Docker environment.
at com.payment.config.DockerClient.init(DockerClient.java:45)
…

# Step 4: 检查资源配置
$ kubectl get pod payment-service-7d8f9c6b5-x2k4m -n prod -o yaml | grep -A 10 resources
resources:
limits:
memory: 256Mi # ⚠️ 内存限制过小
cpu: 200m
requests:
memory: 128Mi
cpu: 100m

根因分析：

解决方案：

# 修复 1: 移除 Docker-in-Docker 依赖，改用 Kubernetes 原生 API
apiVersion: apps/v1
kind: Deployment
metadata:
name: payment-service
spec:
template:
spec:
containers:
– name: payment
image: registry.example.com/payment:v1.2.4 # 修复版本
resources:
limits:
memory: 512Mi # 提升内存限制
cpu: 500m
requests:
memory: 256Mi
cpu: 200m
env:
– name: KUBERNETES_SERVICE_HOST
valueFrom:
fieldRef:
fieldPath: status.hostIP

2.3 OOMKilled 专项排查

# 检查 Pod 是否因 OOM 被杀
$ kubectl get pod <pod-name> -o jsonpath=\'{.status.containerStatuses[*].lastState.terminated.reason}\’
OOMKilled

# 查看历史内存使用
$ kubectl top pod <pod-name> –containers

# 检查节点内存压力
$ kubectl describe node <node-name> | grep -A 5 \”Allocated resources\”

内存限制计算公式：

推荐 limit = P95 内存使用量 × 1.5
推荐 request = P50 内存使用量 × 1.2

三、Service 故障排查：从 DNS 解析到负载均衡

3.1 Service 连通性检查清单

# 1. 检查 Service 是否存在且配置正确
kubectl get svc <svc-name> -n <namespace> -o wide

# 2. 检查 Endpoints 是否有后端 Pod
kubectl get endpoints <svc-name> -n <namespace>

# 3. 检查 Service 标签选择器是否匹配 Pod
kubectl get pods –show-labels -n <namespace>
kubectl get svc <svc-name> -n <namespace&g