Kubernetes容器编排排障手册：从Pod异常到CI/CD流水线的DevOps全场景诊断

Kubernetes故障排查的系统化方法论

Kubernetes集群出问题，最忌讳的就是凭直觉乱查。容器编排系统组件多、依赖链长，一个Pod起不来可能是镜像、网络、存储、RBAC、资源限制中任何一个环节的故障。系统化排障的核心原则是：分层定位，从底层往上逐层排除——节点→控制面→网络→存储→应用。

Pod异常状态诊断流程

Pod是Kubernetes中最小的调度单元，也是最常出问题的对象。遇到Pod异常，先看状态再查事件：

# 快速定位问题Pod
kubectl get pods -A --field-selector=status.phase!=Running

# 查看Pod详细事件
kubectl describe pod <pod-name> -n <namespace>

# 查看容器日志
kubectl logs <pod-name> -n <namespace> -c <container> --previous  # 崩溃前的日志

不同状态的排查路径完全不同：

ImagePullBackOff——镜像拉取失败。常见原因：镜像地址错误、私有仓库认证缺失、网络策略阻断。

# 创建镜像拉取密钥
kubectl create secret docker-registry regcred \
  --docker-server=registry.example.com \
  --docker-username=pull-user \
  --docker-password=<password> \
  -n <namespace>

# 在Deployment中引用
spec:
  imagePullSecrets:
    - name: regcred

CrashLoopBackOff——容器启动后反复崩溃。需要看容器内应用的日志，而非Kubernetes层面的事件。常见原因：配置文件缺失、数据库连接失败、OOMKilled。

# 检查是否被OOM杀掉
kubectl describe pod <pod-name> | grep -A5 "Last State"
# 输出中 OOMKilled: true 表示内存不足

# 临时增大资源限制排查
resources:
  requests:
    memory: "256Mi"
  limits:
    memory: "1Gi"

Pending——调度失败，Pod无法分配到节点。用 kubectl describe pod 查看事件中的调度失败原因：

# 常见Pending原因
# 1. 资源不足：0/3 nodes available: 3 Insufficient memory
# 2. 节点选择器不匹配：0/3 nodes available: 3 node(s) didn't match Pod's node affinity
# 3. PVC无法挂载：0/3 nodes available: 3 node(s) didn't find available persistent volumes

监控告警体系：从指标采集到故障应急响应

生产集群必须有完整的监控体系。Prometheus + Grafana + AlertManager是当前事实标准：

# Prometheus核心告警规则
groups:
  - name: kubernetes-alerts
    rules:
      - alert: PodCrashLooping
        expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Pod {{ $labels.namespace }}/{{ $labels.pod }} 持续重启"

      - alert: NodeNotReady
        expr: kube_node_status_condition{condition="Ready",status="true"} == 0
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "节点 {{ $labels.node }} NotReady超过3分钟"

      - alert: PVCUsageHigh
        expr: kubelet_volume_stats_used_bytes / kubelet_volume_stats_capacity_bytes > 0.85
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "PVC {{ $labels.persistentvolumeclaim }} 使用率超过85%"

告警的黄金法则：宁可漏报，不可误报。一条每天触发但不需要处理的告警，比没有告警更危险——它会让人对所有告警麻木。每条告警必须有明确的处理动作（runbook），否则不应该存在。

混沌工程：主动发现系统脆弱性

监控是被动的，故障是主动的。混沌工程的核心思想是：在用户发现故障之前，自己先制造故障来验证系统的容错能力。Chaos Mesh是Kubernetes生态中最成熟的混沌工具：

# 网络延迟注入
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: api-latency
  namespace: chaos-testing
spec:
  action: delay
  mode: one
  selector:
    namespaces: ["production"]
    labelSelectors:
      app: "api-gateway"
  delay:
    latency: "500ms"
    correlation: "50"
  duration: "5m"

# Pod故障注入（模拟实例异常退出）
apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: pod-failure
  namespace: chaos-testing
spec:
  action: pod-failure
  mode: one
  selector:
    namespaces: ["production"]
    labelSelectors:
      app: "order-service"
  duration: "2m"

混沌实验要从小范围开始，逐步扩大爆炸半径。先在测试环境验证，确认系统在预期故障下能自愈，再到生产环境执行。每次实验要有明确的假设：比如”删除一个Pod，服务应在30秒内恢复”。

CI/CD流水线中的Kubernetes部署最佳实践

Kubernetes环境下的CI/CD流水线有几个特有的最佳实践：

GitOps模式——应用配置以声明式YAML存储在Git仓库，通过ArgoCD自动同步到集群，而非CI流水线直接kubectl apply：

# ArgoCD Application定义
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: api-service
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.example.com/platform/k8s-manifests.git
    targetRevision: main
    path: overlays/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

渐进式发布——使用Canary或Blue-Green策略，先向一小部分流量引入新版本，验证无异常后全量切换：

# Argo Rollouts Canary策略
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-service
spec:
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: {duration: 5m}
        - setWeight: 30
        - pause: {duration: 5m}
        - analysis:
            templates:
              - templateName: error-rate-check
        - setWeight: 100

网站运维的核心不是灭火，而是建防火墙——从监控告警到混沌工程再到GitOps自动化，每一层都在降低故障发生概率和影响范围。把排障流程固化成自动化脚本和runbook，才是运维能力的真正沉淀。