Kubernetes 集群中排查 “Pod 调度失败” 的核心命令与分析思路

在 Kubernetes（K8s）集群中，Pod 调度失败通常表现为 Pod 处于 Pending 状态，表示调度器无法找到合适的节点来运行 Pod。这可能是由于资源不足、节点选择规则、亲和性设置或节点状态问题引起的。以下是一个结构化的排查指南，基于真实可靠的 K8s 实践（基于 Kubernetes v1.24+），帮助您逐步诊断和解决问题。回答分为三部分：核心命令、分析思路和常见原因总结。

核心命令

这些命令是排查的基础，使用 kubectl 工具执行。所有命令都应在集群的上下文环境中运行（例如，通过 kubeconfig 文件认证）。

1. 查看 Pod 状态和事件：

   • kubectl get pods -n <namespace>：列出所有 Pod 的状态。重点关注 STATUS 列为 Pending 的 Pod。
   • kubectl describe pod <pod-name> -n <namespace>：获取 Pod 的详细信息，特别是 Events 部分。事件中通常会显示调度失败的原因，例如：

     Events:
       Type     Reason            Age   From               Message
       ----     ------            ----  ----               -------
       Warning  FailedScheduling  5m    default-scheduler  0/3 nodes are available: 3 Insufficient cpu.
     

2. 检查节点资源和使用情况：

   • kubectl get nodes -o wide：查看所有节点的状态、资源容量和可分配资源。确保节点状态为 Ready。
   • kubectl describe node <node-name>：检查特定节点的详细信息，包括资源分配、污点（Taints）和标签（Labels）。
   • kubectl top nodes：显示节点的实时 CPU 和内存使用率（需安装 Metrics Server）。如果资源不足，输出会类似：

     NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
     node-1     500m         25%    1024Mi          50%
     

3. 查看调度器日志：

   • 如果调度器（kube-scheduler）运行在 Pod 中（通常在 kube-system 命名空间）：

     kubectl get pods -n kube-system | grep scheduler  # 找到调度器 Pod 名称
     kubectl logs <scheduler-pod-name> -n kube-system --tail=100  # 查看最近 100 行日志
     

     日志中可能包含调度决策的细节，例如节点过滤原因。

4. 检查集群事件和资源请求：

   • kubectl get events --sort-by='.lastTimestamp' -n <namespace>：按时间排序查看事件，过滤调度失败事件。
   • kubectl get pod <pod-name> -o yaml -n <namespace>：导出 Pod 的 YAML 定义，检查资源请求（如 resources.requests.cpu）和调度规则（如 nodeSelector、affinity）。

分析思路（逐步诊断）

按照以下步骤系统性排查，从简单检查到深入分析。每个步骤都基于上一步的输出结果。

1. 确认问题现象：

   • 运行 kubectl get pods，确认 Pod 状态是否为 Pending。
   • 如果状态不是 Pending，则可能不是调度问题（例如，可能是启动失败）。

2. 分析 Pod 事件：

   • 使用 kubectl describe pod 查看事件。常见错误消息包括：
     • Insufficient cpu/memory：节点资源不足。
     • node(s) didn't match Pod's node affinity/selector：节点选择器或亲和性规则不匹配。
     • node(s) had taint {key:value}：节点污点未被 Pod 容忍。
   • 根据事件提示，缩小问题范围。

3. 检查节点可用性：

   • 运行 kubectl get nodes，确保所有节点状态为 Ready。如果节点状态为 NotReady，则需修复节点问题（如网络或 kubelet 故障）。
   • 使用 kubectl top nodes 检查资源使用率。计算资源缺口：例如，Pod 请求 CPU $100m$，但节点可用 CPU 为 $50m$，则资源不足。公式为： $$ \text{可用资源} < \text{Pod 请求资源} $$
   • 检查节点污点：kubectl describe node 输出中的 Taints 部分。Pod 必须通过 tolerations 匹配污点，否则无法调度。

4. 验证调度规则：

   • 在 Pod 的 YAML 中检查 nodeSelector、affinity 或 tolerations 字段。使用 kubectl get pod -o yaml 导出定义。
   • 示例：如果 Pod 设置了 nodeSelector: { disktype: ssd }，但所有节点标签不匹配，则调度失败。运行 kubectl get nodes --show-labels 验证节点标签。
   • 亲和性规则（如 requiredDuringSchedulingIgnoredDuringExecution）可能导致严格匹配失败。

5. 深入调度器日志：

   • 如果事件信息不足，查看 kube-scheduler 日志。日志中可能显示详细的调度决策，例如：
     • Predicates failed for Pod default/my-pod: Node node-1 Insufficient cpu
     • No nodes available that match all predicates
   • 日志帮助识别自定义调度插件或策略问题。

6. 测试修复方案：

   • 基于诊断结果，尝试临时修复：
     • 资源不足：增加节点、调整 Pod 资源请求或删除闲置 Pod。
     • 规则不匹配：修改 Pod 的 nodeSelector、affinity 或添加 tolerations。
     • 节点问题：重启 kubelet 或修复节点。
   • 创建测试 Pod 验证：kubectl run test-pod --image=nginx --requests=cpu=100m，观察是否调度成功。

常见原因与解决方案总结

• 资源不足（CPU/内存）：
  • 原因：节点资源耗尽，公式：$ \sum \text{Pod 请求} > \text{节点容量} $。
  • 解决：扩容节点、优化 Pod 资源请求（如降低 requests.cpu）、使用 kubectl drain 迁移 Pod。
• 节点选择规则不匹配：
  • 原因：nodeSelector 或 affinity 规则无匹配节点。
  • 解决：添加节点标签（kubectl label nodes <node-name> key=value）或调整 Pod 规则。
• 污点与容忍问题：
  • 原因：节点有污点（如 NoSchedule），Pod 无相应容忍。
  • 解决：在 Pod 添加 tolerations 或移除节点污点（kubectl taint nodes <node-name> key-）。
• 节点状态异常：
  • 原因：节点 NotReady（如 kubelet 故障）。
  • 解决：检查节点日志（journalctl -u kubelet），重启服务或修复网络。
• 其他因素：
  • 调度器配置错误：检查 kube-scheduler 启动参数（如 --policy-configmap）。
  • 资源碎片：小资源请求导致碎片化，使用 kubectl top pods 分析并优化。

通过以上命令和思路，您能快速定位调度失败的根本原因。实践建议：定期监控集群资源（如使用 Prometheus），并设置 Pod 资源请求合理值（例如，CPU 请求单位 $1 = 1000m$）。如果问题持续，检查 Kubernetes 版本和调度器文档以排除已知 Bug。