Kubernetes容器编排平台在生产环境中承载着大量业务工作负载，Pod异常是最常见的运维问题。本文系统性梳理K8s故障排查方法论，从Pod状态诊断到自动恢复配置，覆盖CrashLoopBackOff、OOMKilled、资源不足等高频场景，提供可直接复用的诊断流程和配置方案。

Pod状态诊断方法论：从kubectl到事件链路追踪

K8s故障排查的第一步是确定Pod当前状态。不同状态指向不同的根因。以下诊断流程适用于绝大多数Pod异常场景：

# 1. 查看Pod状态
kubectl get pods -n production -o wide

# 2. 查看Pod详情（重点关注Events部分）
kubectl describe pod <pod-name> -n production

# 3. 查看Pod日志（当前容器）
kubectl logs <pod-name> -n production --tail=200

# 4. 查看Pod日志（上一个崩溃的容器实例）
kubectl logs <pod-name> -n production --previous --tail=100

# 5. 查看节点资源使用情况
kubectl top nodes
kubectl top pods -n production --sort-by=memory

# 6. 查看Pod事件（按时间排序）
kubectl get events -n production --sort-by='.lastTimestamp' | tail -20

诊断顺序遵循”由外到内”原则：先看Pod状态码，再看Events事件，然后看容器日志，最后看节点资源。大部分问题在前三步就能定位。

CrashLoopBackOff深度排查：容器反复重启的根因分析

CrashLoopBackOff是K8s中最常见的Pod异常状态，表示容器启动后崩溃、被K8s重启、再崩溃的循环。排查步骤：

# 步骤1: 确认重启次数和退出码
kubectl get pod <pod-name> -n production \
  -o jsonpath='{.status.containerStatuses[0].restartCount}'
kubectl get pod <pod-name> -n production \
  -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

# 退出码参考：
# 0   - 正常退出
# 1   - 应用错误（代码异常、配置错误）
# 137 - OOMKilled（内存不足被杀）
# 139 - 段错误（SIGSEGV）
# 143 - SIGTERM（优雅终止）

# 步骤2: 查看上一次崩溃的日志
kubectl logs <pod-name> -n production --previous

# 步骤3: 检查Liveness Probe配置
kubectl get pod <pod-name> -n production -o yaml | grep -A10 livenessProbe

# 步骤4: 查看Events
kubectl describe pod <pod-name> -n production | grep -A20 Events

常见的CrashLoopBackOff根因及对应解决方案：

# 根因1: 应用配置错误（数据库连接失败等）
kubectl logs <pod-name> --previous | grep -i "error\|exception\|failed"

# 根因2: Liveness Probe过于敏感
# 解决: 调整initialDelaySeconds和periodSeconds
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3
  timeoutSeconds: 5

# 根因3: 启动依赖未就绪（如数据库未启动）
# 解决: 配置initContainer等待依赖
initContainers:
- name: wait-for-db
  image: busybox:1.36
  command: ['sh', '-c', 'until nc -z db-service 5432; do sleep 2; done;']

# 根因4: 容器启动命令错误
kubectl describe pod <pod-name> | grep -i "back-off"

OOMKilled问题定位：内存限制配置与JVM调优

OOMKilled（退出码137）是Java/Python应用在K8s中的高频问题。根因是容器实际内存使用超过resources.limits.memory，被内核OOM Killer杀掉。排查和解决：

# 1. 确认是否OOMKilled
kubectl get pod <pod-name> -n prod \
  -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'
# 输出: OOMKilled

# 2. 查看内存限制配置
kubectl get pod <pod-name> -n prod -o yaml | grep -A5 resources:

# 3. 查看历史内存使用趋势（需要Metrics Server）
kubectl top pod <pod-name> -n prod --containers

# 4. 对于JVM应用，调整堆内存参数
env:
- name: JAVA_OPTS
  value: >-
    -XX:+UseContainerSupport
    -XX:MaxRAMPercentage=70.0
    -XX:InitialRAMPercentage=50.0
    -XX:+UseG1GC
    -XX:MaxGCPauseMillis=200
    -Xlog:gc*:stdout:time,level,tags

resources:
  requests:
    memory: "512Mi"
    cpu: "250m"
  limits:
    memory: "1Gi"
    cpu: "1000m"

MaxRAMPercentage=70是一个经验值，预留30%给Metaspace、DirectBuffer、线程栈和JNI内存。GC日志输出到stdout便于通过kubectl logs查看。Docker自动化部署场景下，构建镜像时就应将JVM参数写入启动脚本，避免运行时手动注入环境变量。

资源不足调度失败：节点资源规划与节点亲和性

Pod处于Pending状态通常意味着调度失败，没有节点能满足Pod的资源请求或调度约束：

# 查看调度失败原因
kubectl describe pod <pod-name> -n prod | grep -A10 "Events:"
# 常见消息:
# - "Insufficient cpu" / "Insufficient memory"
# - "node(s) had taints that the pod didn't tolerate"
# - "node(s) didn't match node selector"

# 查看各节点资源分配情况
kubectl describe nodes | grep -A5 "Allocated resources"

# 解决方案1: 调整资源请求值
resources:
  requests:
    cpu: "100m"
    memory: "256Mi"

# 解决方案2: 配置节点亲和性
affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: node-type
          operator: In
          values: ["high-memory"]

# 解决方案3: 配置容忍度
tolerations:
- key: "dedicated"
  operator: "Equal"
  value: "batch"
  effect: "NoSchedule"

# 解决方案4: 配置Pod反亲和性，避免集中调度
podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchLabels:
          app: my-service
      topologyKey: kubernetes.io/hostname

自动恢复机制：PDB与HPA的协同配置

故障应急响应不应完全依赖人工介入。K8s提供了多种自动恢复机制，合理配置可以实现故障自愈：

# 1. Pod Disruption Budget - 防止驱逐导致服务不可用
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-server-pdb
  namespace: production
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: api-server

# 2. Horizontal Pod Autoscaler - 根据负载自动扩缩容
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
      - type: Pods
        value: 4
        periodSeconds: 15
      selectPolicy: Max

HPA的scaleUp配置为快速响应（15秒内可翻倍扩容），scaleDown配置为保守缩容（5分钟稳定窗口 + 每分钟最多缩50%），避免负载波动导致频繁扩缩容。配合监控告警体系，在HPA触发maxReplicas上限时发出告警，提示运维团队介入。

日志分析自动化：EFK Stack采集与异常告警

容器日志分散在各节点，手动排查效率极低。EFK（Elasticsearch + Fluentd + Kibana）是K8s生态中成熟的日志方案：

# Fluentd DaemonSet配置 - 采集所有容器日志
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: logging
spec:
  selector:
    matchLabels:
      app: fluentd
  template:
    metadata:
      labels:
        app: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1.16-elasticsearch
        env:
        - name: FLUENT_ELASTICSEARCH_HOST
          value: "elasticsearch.logging.svc.cluster.local"
        - name: FLUENT_ELASTICSEARCH_PORT
          value: "9200"
        volumeMounts:
        - name: varlog
          mountPath: /var/log
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log
      - name: varlibdockercontainers
        hostPath:
          path: /var/lib/docker/containers

日志采集到Elasticsearch后，在Kibana中配置告警规则：当ERROR级别日志在5分钟内超过阈值时触发Webhook告警。这样故障排查时可以在Kibana中按Namespace、Pod名称、日志级别快速过滤，大幅缩短MTTR（平均恢复时间）。CI/CD流水线中也可以集成日志分析步骤，在部署后自动检查异常日志，形成从部署到监控的完整闭环。混沌工程实践中，可以定期注入Pod故障验证自动恢复机制是否正常工作。