分类 kubectl 下的文章

Kubernetes 生产集群故障排查实战手册

一、概述

1. 问题背景

A. 场景描述

生产环境 Kubernetes 集群突然宕机，业务中断，管理层每 5 分钟询问一次处理进度。运维人员需要在高压环境下快速定位问题并恢复服务。

B. 核心挑战

  • 时间紧迫，业务损失持续增加
  • 管理层高频催促，心理压力大
  • 集群组件复杂，问题定位困难
  • 需要系统性排查思路，避免盲目操作

C. 解决目标

建立标准化故障排查流程，快速定位根因并恢复服务

二、故障排查总体流程

1. 系统性方法论

故障排查遵循从全局到局部、从现象到本质的原则：

graph TD
    A[故障发现] --> B[第一步: 定位环境]
    B --> C[第二步: 全局健康检查]
    C --> D{问题范围判断}
    D -->|集群级| E[节点层排查]
    D -->|应用级| F[Pod 层排查]
    E --> G[第三步: 问题 Pod 诊断]
    F --> G
    G --> H{问题类型}
    H -->|健康检查失败| I[第四步: 探针检查]
    H -->|部署问题| J[第五步: 部署与回滚]
    H -->|网络问题| K[第六步: 网络连通性]
    I --> L[第七步: 快速修复]
    J --> L
    K --> L
    L --> M{是否需要回滚?}
    L -->|立即生效| N[执行修复]
    L -->|观察验证| O[监控指标]
    M -->|是| P[回滚操作]
    M -->|否| Q[继续排查]
    N --> O
    P --> O
    O -->|指标正常| R[故障恢复]
    O -->|指标异常| Q

Kubernetes 故障排查流程图

2. 流程说明

  • 步骤 1-2：全局视角，确定问题范围
  • 步骤 3-6：局部深入，定位具体原因
  • 步骤 7：快速恢复，保障业务优先

三、详细操作步骤

1. 第一步：定位当前环境

A. 检查当前上下文

kubectl config current-context

作用：确认当前操作的集群，避免误操作生产/测试环境

B. 查看所有上下文

kubectl config get-contexts

输出示例：

CURRENT   NAME                  CLUSTER               AUTHINFO
*         prod-cluster          prod-cluster          admin-user
          test-cluster          test-cluster          admin-user
          staging-cluster       staging-cluster       admin-user

C. 切换上下文（如需要）

kubectl config use-context prod-cluster

D. 列出所有命名空间

kubectl get ns

作用：了解集群中部署的业务范围，快速定位故障域

★ Insight ─────────────────────────────────────
第一步看似简单，但却是最容易出错的环节。多次重大事故都是因为运维人员操作了错误的集群。在压力环境下，人的判断力会下降，因此必须严格执行上下文确认流程。
─────────────────────────────────────────────────

2. 第二步：全局健康检查

A. 节点健康状态

kubectl get nodes

关键指标：

  • STATUS：Ready 表示正常，NotReady 表示节点故障
  • ROLES：识别 master/control-plane 节点
  • VERSION：检查版本是否一致
  • AGE：判断节点是否为新加入

异常信号：

  • 多个节点 NotReady：可能是网络或存储问题
  • 控制平面节点 NotReady：集群管理功能受损
  • 单个节点 NotReady：硬件故障或 kubelet 进程异常

B. 所有 Pod 状态

kubectl get pods -A

关键指标：

  • READY：就绪容器数/总容器数
  • STATUS：Running、Pending、Failed、CrashLoopBackOff
  • RESTARTS：重启次数异常增长表示资源泄露

C. 最近事件流

kubectl get events --sort-by=.metadata.creationTimestamp -A

作用：按时间倒序查看集群事件，快速发现异常模式

常见事件类型：

  • FailedMount：存储卷挂载失败
  • FailedScheduling：资源不足或调度器故障
  • Unhealthy：健康检查失败
  • NodeNotReady：节点失联

★ Insight ─────────────────────────────────────
这一步的核心价值在于判断问题范围。如果所有节点和 Pod 都有问题，通常是集群级故障（网络、DNS、API Server）；如果只有部分 Pod 异常，则是应用级故障。这一判断直接影响后续排查路径。
─────────────────────────────────────────────────

3. 第三步：问题 Pod 深度诊断

A. 获取 Pod 详细信息

kubectl describe pod podname -n namespace

关键信息区域：

  • Events：Pod 生命周期事件，常包含错误线索
  • State：当前运行状态（Waiting、Running、Terminated）
  • Last State：上一次退出状态和退出码
  • Containers：资源限制、请求、探针配置

B. 查看容器日志

kubectl logs podname -n namespace

进阶用法：

# 查看崩溃前的日志（CrashLoopBackOff 场景）
kubectl logs podname -n namespace --previous

# 查看多容器 Pod 的特定容器日志
kubectl logs podname -c container-name -n namespace

# 实时跟踪日志
kubectl logs podname -n namespace -f

C. 进入容器调试

kubectl exec -it podname -n namespace -- /bin/sh

用途：

  • 手动执行健康检查命令
  • 查看进程状态和端口监听
  • 检查配置文件和环境变量
  • 测试网络连通性

4. 第四步：健康探针检查

A. 探针类型说明

Kubernetes 三种探针：

探针类型检查时机失败后果
Liveness Probe运行中定期检查重启容器
Readiness Probe运行中定期检查从 Service 移除
Startup Probe启动阶段检查禁用其他探针直到成功

B. 识别探针失败

在 describe 输出中查找：

Events:
  Warning  Unhealthy  pod/name  Liveness probe failed: HTTP probe failed with statuscode: 500

C. 手动测试探针端点

kubectl exec -it podname -n namespace -- curl localhost:port/health

测试重点：

  • 端口是否正确监听
  • 响应时间是否超时
  • 返回状态码是否符合预期
  • 响应内容是否包含健康标识

D. 探针配置优化建议

livenessProbe:
  httpGet:
    path: /health/live
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

★ Insight ─────────────────────────────────────
探针配置是应用稳定性的关键。initialDelaySeconds 过短会导致应用启动失败，过长会延长故障检测时间。failureThreshold 设置过低会因为网络抖动导致重启，设置过高会延迟故障恢复。建议根据实际启动时间和 SLA 要求调整。
─────────────────────────────────────────────────

5. 第五步：部署与回滚检查

A. 查看部署状态

kubectl rollout status deployment/name -n namespace

输出判断：

  • Successfully deployed：部署成功
  • waiting for replicas：滚动更新中
  • error：部署失败

B. 查看部署历史

kubectl rollout history deployment/name -n namespace

输出示例：

REVISION  CHANGE-CAUSE
5         <none>
4         Update image to v2.0
3         Initial deployment

C. 执行回滚操作

# 回滚到上一版本
kubectl rollout undo deployment/name -n namespace

# 回滚到指定版本
kubectl rollout undo deployment/name --to-revision=3 -n namespace

D. 回滚决策框架

graph TD
    A[发现部署后故障] --> B{故障影响范围}
    B -->|全量影响| C[立即回滚]
    B -->|部分影响| D{是否可快速修复?}
    D -->|是, 10分钟内| E[原地修复]
    D -->|否, 或不确定| F[回滚再修复]
    C --> G[保留故障版本用于分析]
    E --> H{修复验证}
    F --> H
    H -->|成功| I[保留当前版本]
    H -->|失败| J[执行回滚]
    J --> K[离线分析故障版本]

回滚决策流程图

6. 第六步：网络连通性验证

A. 列出服务

kubectl get svc -n namespace

关键信息：

  • TYPE：ClusterIP、NodePort、LoadBalancer
  • CLUSTER-IP：集群内部 IP
  • EXTERNAL-IP：外部访问 IP
  • PORT(S)：服务端口映射

B. 检查端点

kubectl get endpoints -n namespace

作用：验证 Service 是否正确关联到 Pod

正常输出示例：

NAME         ENDPOINTS                     AGE
my-service   10.244.1.5:8080,10.244.2.7:8080   7d

异常情况：

  • ENDPOINTS 为空：Service 选择器错误或 Pod 未就绪
  • ENDPOINTS 不完整：部分 Pod 不可用

C. DNS 解析测试

kubectl exec -it podname -- nslookup servicename

完整命令示例：

# 测试同命名空间服务
kubectl exec -it podname -n default -- nslookup my-service

# 测试跨命名空间服务
kubectl exec -it podname -n default -- nslookup my-service.other-namespace

# 测试外部域名
kubectl exec -it podname -n default -- nslookup google.com

D. Pod 间连通性测试

# 从 Pod A 测试 Pod B 的连通性
kubectl exec -it pod-a -- ping pod-b-ip

# 测试 Service 连通性
kubectl exec -it pod-a -- curl http://service-name:port/health

7. 第七步：快速修复方案

A. 重启部署

kubectl rollout restart deployment/name -n namespace

适用场景：

  • 应用状态异常但配置无变化
  • 内存泄露导致性能下降
  • 临时性网络故障导致连接池耗尽
  • 缓存数据异常

原理：触发滚动更新，逐个替换 Pod

B. 删除问题 Pod

kubectl delete pod podname -n namespace

适用场景：

  • Pod 处于 CrashLoopBackOff 状态
  • 节点故障导致 Pod 不可调度
  • 临时存储卷故障

注意：删除后 Deployment 会自动创建新 Pod

C. 强制删除（谨慎使用）

kubectl delete pod podname -n namespace --force --grace-period=0

风险提示：

  • 跳过优雅关闭，可能导致数据丢失
  • 仅在 Pod 卡在 Terminating 状态时使用

D. 资源调整

# 扩容副本数
kubectl scale deployment/name --replicas=5 -n namespace

# 编辑资源配置
kubectl edit deployment/name -n namespace

四、快速修复决策树

graph TD
    A[Pod 异常] --> B{重启次数}
    B -->|持续增长| C[重启 Deployment]
    B -->|稳定但异常| D{日志报错}
    D -->|OOMKilled| E[增加内存限制]
    D -->|CrashLoopBackOff| F[检查启动命令]
    D -->|ImagePullBackOff| G[检查镜像可用性]
    C --> H{观察 5 分钟}
    H -->|恢复正常| I[问题解决]
    H -->|持续异常| J[回滚版本]
    F --> K{配置正确?}
    K -->|是| L[检查依赖服务]
    K -->|否| M[修正配置]
    G --> N{镜像存在?}
    N -->|是| O[检查认证信息]
    N -->|否| P[上传镜像或修改标签]

快速修复决策图

五、常见故障模式与应对

1. 镜像拉取失败

现象：ImagePullBackOff 或 ErrImagePull

排查步骤：

  1. 检查镜像名称和标签是否正确
  2. 验证镜像仓库认证信息（imagePullSecrets）
  3. 测试镜像仓库连通性
  4. 检查私有仓库证书

解决方案：

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

# 绑定到 ServiceAccount
kubectl patch serviceaccount default \
  -p '{"imagePullSecrets": [{"name": "regcred"}]}' \
  -n namespace

2. 资源不足

现象：Pending 状态，Events 显示 FailedScheduling

排查步骤：

  1. 检查节点资源使用率
  2. 验证 Pod 资源请求和限制
  3. 查看污点和容忍度配置

解决方案：

# 查看节点资源
kubectl top nodes

# 查看资源配额
kubectl describe quota -n namespace

# 调整 Pod 资源请求
kubectl set resources deployment/name \
  --requests=cpu=200m,memory=256Mi \
  --limits=cpu=500m,memory=512Mi \
  -n namespace

3. 存储卷挂载失败

现象：容器处于 ContainerCreating 状态

排查步骤：

  1. 查看 Events 中的 FailedMount 错误
  2. 验证 PVC 绑定状态
  3. 检查 StorageClass 配置
  4. 确认存储后端可用性

解决方案：

# 查看 PVC 状态
kubectl get pvc -n namespace

# 查看 PV 详细信息
kubectl describe pv pv-name

# 检查 StorageClass
kubectl get storageclass

六、预防措施与最佳实践

1. 监控与告警

必备指标：

  • 集群级别：节点健康、资源使用率
  • 应用级别：Pod 状态、重启次数
  • 业务级别：服务可用性、响应时间

告警规则：

  • 节点 NotReady 超过 1 分钟
  • Pod 重启次数超过 3 次
  • 服务端点数量为 0
  • API Server 响应时间超过 5 秒

2. 故障演练

定期演练场景：

  • 节点故障模拟
  • 网络分区测试
  • 资源耗尽场景
  • 依赖服务故障

演练目标：

  • 验证自动恢复机制
  • 熟悉故障处理流程
  • 发现潜在风险点

3. 文档与知识库

维护内容：

  • 应用部署文档
  • 常见故障处理手册
  • 架构依赖关系图
  • 联系人清单

4. 代码审查要点

Deployment 配置审查：

  • 健康探针配置是否合理
  • 资源请求和限制是否设置
  • 镜像标签是否使用固定版本
  • 优雅关闭配置是否正确

七、关键要点总结

  1. 遵循系统性流程：按步骤顺序执行，避免跳跃式排查
  2. 先全局后局部：先确定问题范围，再深入具体组件
  3. 快速恢复优先：必要时先回滚再分析根因
  4. 保留故障现场：日志、配置、状态要及时备份
  5. 记录处理过程：便于事后复盘和知识沉淀

★ Insight ─────────────────────────────────────
这套故障排查流程的价值不仅在于技术指导，更在于建立了标准化的应急响应机制。在压力环境下，人的决策质量会显著下降，因此提前建立的流程和检查清单成为保障。真正的可靠性来自于日常的预防措施和演练，而非故障时的临时应对。
─────────────────────────────────────────────────

参考资料

  1. Akhilesh Mishra (@livingdevops) - Kubernetes Troubleshooting Playbook
  2. Kubernetes 官方文档 - Troubleshooting
  3. kubectl Cheat Sheet