Kubernetes容器编排故障排查手册：Pod异常、资源瓶颈与集群诊断全流程

K8s故障排查的系统性方法

Kubernetes容器编排环境中的故障排查，不能靠猜和随机执行命令。SRE稳定性工程的核心在于建立从现象到根因的标准化诊断流程。Docker自动化部署虽然简化了应用交付，但在K8s中网络、存储、调度三个层面的故障交织，需要逐层定位。本文整理一套从Pod状态到集群节点的完整排查路径。

Pod异常状态快速诊断

Pod是K8s最小调度单元，Pod异常是DevOps实践中最高频的故障类型。不同状态对应不同排查方向：

# 查看Pod状态和事件
kubectl get pods -o wide
kubectl describe pod <pod-name> -n <namespace>

# 查看Pod日志（含前一容器崩溃日志）
kubectl logs <pod-name> -n <namespace> --previous
kubectl logs <pod-name> -n <namespace> -c <container-name> --tail=100

# 查看Pod事件时间线
kubectl get events -n <namespace> --sort-by='.lastTimestamp'

ImagePullBackOff：镜像拉取失败，排查镜像名称、私有仓库凭证：

# 检查imagePullSecrets
kubectl get secret <secret-name> -n <namespace> -o yaml

# 验证凭证有效性
kubectl create secret docker-registry regcred \
    --docker-server=registry.company.com \
    --docker-username=pull-user \
    --docker-password=<token> \
    --docker-email=ops@company.com \
    --dry-run=client -o yaml | kubectl apply -f -

CrashLoopBackOff：容器启动后立即退出，重点关注应用启动日志和资源限制：

# 常见原因：OOMKilled
kubectl describe pod <pod-name> | grep -A5 "Last State"

# 常见原因：健康检查失败，临时调整探针策略排查
kubectl patch deployment <deploy-name> -n <namespace> -p '
spec:
  template:
    spec:
      containers:
      - name: app
        livenessProbe:
          initialDelaySeconds: 60
        readinessProbe:
          initialDelaySeconds: 30
'

资源瓶颈与LimitRange排查

K8s调度器根据requests值分配节点资源，资源超卖和LimitRange冲突是CI/CD流水线部署失败的常见原因：

# 查看节点资源使用率
kubectl top nodes
kubectl describe node <node-name> | grep -A8 "Allocated resources"

# 查看Pod资源使用
kubectl top pods -n <namespace> --sort-by=memory

# 查看LimitRange配置
kubectl get limitrange -n <namespace> -o yaml

# 查看ResourceQuota配额
kubectl get resourcequota -n <namespace> -o yaml

资源规划原则：requests设为实际P95消耗值，limits设为P99值的1.5倍。过低导致OOM，过高浪费集群资源：

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

网络连通性故障诊断

K8s集群网络排查需覆盖Pod到Pod、Pod到Service、Pod到外部三个维度：

# 在临时调试Pod中执行网络测试
kubectl run netshoot --image=nicolaka/netshoot --rm -it -- bash

# DNS解析测试
nslookup kubernetes.default.svc.cluster.local
nslookup <service-name>.<namespace>.svc.cluster.local

# Service端点检查
kubectl get endpoints <service-name> -n <namespace>

# NetworkPolicy阻断排查
kubectl get networkpolicy -n <namespace>
kubectl describe networkpolicy <policy-name> -n <namespace>

CoreDNS配置异常是服务发现失败的常见原因：

# 检查CoreDNS配置
kubectl get configmap coredns -n kube-system -o yaml

# 常见修复：添加stubdomain或forward配置
.:53 {
    errors
    health
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
        pods insecure
        fallthrough in-addr.arpa ip6.arpa
    }
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

监控告警体系搭建

故障应急响应的效率取决于监控告警体系覆盖的完整性。Prometheus + Alertmanager + Grafana是当前主流方案：

# Prometheus关键告警规则
groups:
- name: k8s-node-alerts
  rules:
  - alert: NodeNotReady
    expr: kube_node_status_condition{condition="Ready",status="unknown"} == 1
    for: 5m
    labels:
      severity: critical
    annotations:
      summary: "Node is NotReady"

  - alert: PodCrashLoopBackOff
    expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Pod is crash looping"

  - alert: HighMemoryUsage
    expr: |
      (sum(container_memory_working_set_bytes{container!=""})
      / sum(kube_node_status_allocatable{resource="memory"}))
      > 0.85
    for: 10m
    labels:
      severity: warning

混沌工程验证与日志分析

生产集群的可靠性需要混沌工程主动验证。Chaos Mesh是K8s原生的故障注入工具：

# 安装Chaos Mesh
kubectl apply -f https://mirrors.chaos-mesh.org/v2.6.2/chaos-mesh.yaml

# 网络延迟注入
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: network-delay
  namespace: chaos-testing
spec:
  action: delay
  mode: one
  selector:
    namespaces:
      - production
    labelSelectors:
      app: payment-service
  delay:
    latency: "200ms"
    jitter: "50ms"
  duration: "5m"

日志分析方面，EFK（Elasticsearch + Fluentd + Kibana）栈配合K8s日志轮转策略，确保日志不撑爆节点磁盘：

# kubelet日志轮转配置 /var/lib/kubelet/config.yaml
containerLogMaxSize: "50Mi"
containerLogMaxFiles: 5

Kubernetes故障排查的效率取决于对集群各组件运行状态的全面感知。Pod状态是表象，资源分配和网络策略是约束，监控告警是预警，混沌工程是验证。四者联动形成完整的SRE运维闭环，从被动救火转为主动保障。