16.8.5 常见故障场景与处置流程

本节聚焦 Kubernetes 常见故障场景与标准化处置流程，配合可执行命令、配置示例、排错步骤与练习，帮助快速定位与恢复。

1. Pod无法启动或 CrashLoopBackOff#

现象：Pod状态为Pending、CrashLoopBackOff、ImagePullBackOff。

排查与命令解释

# 1) 查看事件，定位调度、镜像、挂载等失败原因
kubectl describe pod demo-api-7f7c8f7c4c-abcde -n prod

# 2) 查看日志；若容器不断重启，使用 --previous 查看上次崩溃日志
kubectl logs demo-api-7f7c8f7c4c-abcde -n prod
kubectl logs demo-api-7f7c8f7c4c-abcde -n prod --previous

# 3) 查看命名空间事件时间线，锁定集群级故障
kubectl get events -n prod --sort-by=.lastTimestamp

处置示例：镜像拉取失败

# 检查镜像仓库访问与 Secret
kubectl get secret regcred -n prod -o yaml

# 重新创建镜像拉取 Secret（示例）
kubectl create secret docker-registry regcred \
  --docker-server=registry.example.com \
  --docker-username=devops \
  --docker-password='Passw0rd' \
  --docker-email=devops@example.com -n prod

# 更新 Deployment 引用
kubectl patch deploy demo-api -n prod \
  -p '{"spec":{"template":{"spec":{"imagePullSecrets":[{"name":"regcred"}]}}}}'

处置示例：配置错误

# 检查 ConfigMap/Secret 与环境变量
kubectl get cm demo-api-config -n prod -o yaml
kubectl get secret demo-api-secret -n prod -o yaml

# 修复配置后滚动重启
kubectl rollout restart deploy demo-api -n prod

练习
1) 将镜像名改为不存在的 tag，观察 ImagePullBackOff。
2) 恢复正确 tag 后，验证 Pod 正常启动。

---

2. Pod一直 Pending（调度失败）#

现象：Pod长期Pending。

排查与命令解释

# 1) 查看调度失败原因（资源不足、污点、亲和性）
kubectl describe pod demo-api-7f7c8f7c4c-abcde -n prod

# 2) 检查节点状态与污点
kubectl get node
kubectl describe node worker-01 | grep -i taint -A2

# 3) 检查资源配额
kubectl describe quota -n prod

处置示例：资源请求过高

# 下调 requests，示例: CPU 500m -> 200m
kubectl patch deploy demo-api -n prod -p '
{
  "spec": {
    "template": {
      "spec": {
        "containers": [{
          "name": "demo-api",
          "resources": {
            "requests": {"cpu":"200m","memory":"256Mi"},
            "limits": {"cpu":"500m","memory":"512Mi"}
          }
        }]
      }
    }
  }
}'

练习
1) 设置 nodeSelector 指向不存在的 label，观察 Pending。
2) 修改为正确 label，观察调度成功。

---

3. 服务不可达或间歇性超时#

现象：Service访问失败、请求超时。

排查与命令解释

# 1) 确认 Service 与 Endpoints 是否一致
kubectl get svc,ep -n prod

# 2) 检查 Pod Ready 状态与 IP
kubectl get pod -n prod -o wide

# 3) 查看网络策略
kubectl get netpol -n prod

处置示例：Service selector 错误

# /tmp/demo-api-svc.yaml
apiVersion: v1
kind: Service
metadata:
  name: demo-api
  namespace: prod
spec:
  selector:
    app: demo-api   # 确保与 Pod label 一致
  ports:
  - port: 80
    targetPort: 8080

kubectl apply -f /tmp/demo-api-svc.yaml

练习
1) 将 Service selector 改为不存在的 label，观察 Endpoints 为空。
2) 修正后验证访问恢复。

---

4. 节点 NotReady 或频繁重启#

现象：节点NotReady、Pod迁移。

排查与命令解释

# 1) 查看节点条件
kubectl describe node worker-01

# 2) 查看 kubelet/containerd 日志（在节点上执行）
journalctl -u kubelet -n 200 --no-pager
journalctl -u containerd -n 200 --no-pager

# 3) 检查磁盘空间与 inode
df -h
df -i

处置示例：磁盘满导致 NotReady

# 清理无用镜像（在节点执行）
crictl images
crictl rmi --prune

# 清理日志
find /var/log -type f -name "*.log" -size +100M -exec truncate -s 0 {} \;

练习
1) 使用大日志文件填满 /var/log（测试环境）。
2) 观察 Node DiskPressure，清理后恢复。

---

5. 资源飙升导致服务不稳定#

现象：CPU/内存持续高，Pod被 OOMKilled。

排查与命令解释

# 1) 查看 OOMKill 事件
kubectl describe pod demo-api-7f7c8f7c4c-abcde -n prod | grep -i oom -A3

# 2) 查看实时资源
kubectl top pod -n prod
kubectl top node

处置示例：启用 HPA

# /tmp/demo-api-hpa.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: demo-api-hpa
  namespace: prod
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo-api
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

kubectl apply -f /tmp/demo-api-hpa.yaml

练习
1) 人为增加压测流量，观察 HPA 扩容。
2) 压力下降后观察缩容。

---

6. 滚动发布失败或回滚不一致#

现象：Deployment升级卡住、不可用。

排查与命令解释

# 1) 查看发布状态
kubectl rollout status deploy/demo-api -n prod

# 2) 查看失败原因（探针失败、镜像拉取等）
kubectl describe deploy demo-api -n prod

处置示例：调整探针超时

# /tmp/demo-api-deploy.yaml 片段
readinessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  timeoutSeconds: 2
  failureThreshold: 6

kubectl apply -f /tmp/demo-api-deploy.yaml

快速回滚

kubectl rollout undo deploy/demo-api -n prod

练习
1) 将 readinessProbe path 写错，观察发布失败。
2) 修正 path，验证恢复。

---

7. DNS解析异常#

现象：服务间调用失败，解析超时。

排查与命令解释

# 1) 进入 Pod 测试解析
kubectl exec -it demo-api-7f7c8f7c4c-abcde -n prod -- sh -c "nslookup kubernetes.default"

# 2) 查看 CoreDNS 状态
kubectl get pod -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns --tail=100

处置示例：扩容 CoreDNS

kubectl scale deploy/coredns -n kube-system --replicas=3

练习
1) 暂时缩容 CoreDNS 到 1，观察解析延迟。
2) 恢复到 2 或 3 副本。

---

8. 存储挂载失败#

现象：Pod因PVC挂载失败启动。

排查与命令解释

kubectl describe pvc data-demo-api -n prod
kubectl get pv
kubectl get sc

处置示例：StorageClass 参数修正

# /tmp/sc-nfs.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-sc
provisioner: nfs.csi.k8s.io
parameters:
  server: 10.0.0.10
  share: /exports/k8s
reclaimPolicy: Retain
volumeBindingMode: Immediate

kubectl apply -f /tmp/sc-nfs.yaml

练习
1) 使用错误的 NFS server，观察挂载失败。
2) 修正 server 后重新创建 PVC 验证挂载成功。

---

9. 控制面组件异常#

现象：API响应慢、集群不可操作。

排查与命令解释

# 1) 查看控制面组件
kubectl get pod -n kube-system | egrep 'apiserver|etcd|controller|scheduler'

# 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 \
  endpoint health

处置示例：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

练习
1) 观察 etcd 磁盘占用与延迟指标变化。
2) defrag 后验证 API 响应改善。

---

10. 标准化处置流程（SOP）#

SOP模板
1. 告警确认：确认影响范围与优先级，记录时间线。
2. 快速止血：回滚发布、切流、扩容、降级。
3. 定位根因：事件、日志、指标三线并行排查。
4. 恢复验证：验证核心链路与SLA指标。
5. 复盘改进：输出根因、预防措施与自动化改进项。

SOP脚本示例（快速收集信息）

#!/usr/bin/env bash
# /opt/k8s/triage.sh
NS=${1:-prod}
APP=${2:-demo-api}

echo "== Pod 状态 =="
kubectl get pod -n "$NS" -l app="$APP" -o wide

echo "== 事件 =="
kubectl get events -n "$NS" --sort-by=.lastTimestamp | tail -n 20

echo "== Deployment =="
kubectl describe deploy "$APP" -n "$NS" | sed -n '1,120p'

echo "== HPA/资源 =="
kubectl get hpa -n "$NS"
kubectl top pod -n "$NS" | head -n 10

练习
1) 在测试环境运行 triage.sh 收集一条故障时间线。
2) 将输出整理成复盘报告模板，包含“影响、根因、改进”。