K8s Pod 调度疑难杂症：从原理到实战排查指南

在 Kubernetes (K8s) 集群中，Pod 调度失败是一个比较常见但又令人头疼的问题。尤其是在业务高峰期，如果关键应用的 Pod 因为资源不足或其他原因无法正常调度，会导致服务中断，影响用户体验。本文将深入探讨 Kubernetes Pod 调度失败排查 的方法，从底层原理到实战案例，帮助你快速定位并解决问题。

常见 Pod 调度失败原因及排查思路

Pod 调度失败的原因多种多样，常见的包括资源不足、节点选择器不匹配、污点和容忍度配置错误、亲和性和反亲和性策略冲突等。下面我们将逐一分析这些原因，并给出相应的排查思路。

1. 资源不足 (Insufficient Resources)

这是最常见的调度失败原因之一。当集群中没有足够的 CPU、内存或 GPU 资源来满足 Pod 的需求时，Kubernetes 调度器就无法将 Pod 调度到任何节点上。

排查思路：

• 查看 Pod 的 Events： 使用 kubectl describe pod <pod-name> 命令查看 Pod 的 Events 列表，通常会包含调度失败的具体原因，例如 Insufficient cpu 或 Insufficient memory。

  kubectl describe pod my-pod
  

• 查看节点资源使用情况： 使用 kubectl top node 命令查看各个节点的 CPU 和内存使用情况，确定哪些节点的资源已经达到瓶颈。

  

  kubectl top node
  

• 查看资源 Quota： 如果集群启用了 Resource Quota，需要检查 Pod 所在的 Namespace 是否超过了资源限制。

  kubectl describe quota -n <namespace>
  

解决方案：

• 扩容集群： 增加节点数量，提升集群的整体资源容量。可以使用 Kubernetes 提供的自动伸缩功能 (Horizontal Pod Autoscaler, HPA) 自动调整 Pod 副本数量。
• 优化资源请求： 调整 Pod 的资源请求 (resource requests) 和限制 (resource limits)，使其更符合实际需求。需要注意，过高的资源请求可能会导致 Pod 无法调度，而过低的资源请求可能会导致 Pod 性能下降。
• 清理无用资源： 删除不再使用的 Pod、Deployment、Service 等资源，释放集群资源。

2. 节点选择器不匹配 (Node Selector Mismatch)

Node Selector 允许你将 Pod 调度到具有特定标签 (label) 的节点上。如果 Pod 的 Node Selector 与任何节点的标签都不匹配，调度就会失败。

排查思路：

• 检查 Pod 的 Node Selector： 使用 kubectl get pod <pod-name> -o yaml 命令查看 Pod 的 Node Selector 配置。

  

  kubectl get pod my-pod -o yaml
  

• 检查节点的标签： 使用 kubectl get node <node-name> --show-labels 命令查看节点的标签。

  kubectl get node my-node --show-labels
  

解决方案：

• 修改 Pod 的 Node Selector： 将 Pod 的 Node Selector 修改为与现有节点的标签匹配的值。
• 修改节点的标签： 为节点添加与 Pod 的 Node Selector 匹配的标签。但需要谨慎操作，避免影响其他 Pod 的调度。

3. 污点和容忍度 (Taints and Tolerations)

污点 (Taints) 用于标记节点，表示节点不应该运行某些 Pod。容忍度 (Tolerations) 用于声明 Pod 可以容忍哪些污点。如果 Pod 没有容忍节点上的污点，调度就会失败。

排查思路：

• 查看节点的污点： 使用 kubectl describe node <node-name> 命令查看节点的污点。

  

  kubectl describe node my-node
  

• 检查 Pod 的容忍度： 使用 kubectl get pod <pod-name> -o yaml 命令查看 Pod 的容忍度配置。

  kubectl get pod my-pod -o yaml
  

解决方案：

• 为 Pod 添加容忍度： 为 Pod 添加与节点上的污点匹配的容忍度。
• 移除节点的污点： 如果确定 Pod 可以在该节点上运行，可以移除节点的污点。但需要谨慎操作，避免影响其他 Pod 的调度。

4. 亲和性和反亲和性 (Affinity and Anti-Affinity)

亲和性 (Affinity) 用于控制 Pod 应该调度到哪些节点上，反亲和性 (Anti-Affinity) 用于控制 Pod 不应该调度到哪些节点上。如果亲和性和反亲和性策略配置不当，可能会导致 Pod 无法调度。

排查思路：

• 检查 Pod 的亲和性和反亲和性配置： 使用 kubectl get pod <pod-name> -o yaml 命令查看 Pod 的亲和性和反亲和性配置。

  

  kubectl get pod my-pod -o yaml
  

• 分析亲和性和反亲和性策略： 仔细分析亲和性和反亲和性策略，确定是否存在冲突或不合理之处。

解决方案：

• 调整亲和性和反亲和性策略： 根据实际需求调整亲和性和反亲和性策略，使其更符合预期。

实战案例：Nginx Ingress Controller 调度失败

假设我们有一个 Nginx Ingress Controller 的 Pod 始终无法调度，Events 显示 0/3 nodes are available: 3 Insufficient cpu.。

排查步骤：

1. 查看节点资源使用情况： 使用 kubectl top node 命令查看各个节点的 CPU 使用情况，发现所有节点的 CPU 使用率都接近 100%。

2. 检查 Nginx Ingress Controller 的资源请求： 使用 kubectl get pod nginx-ingress-controller -o yaml 命令查看 Nginx Ingress Controller 的资源请求，发现 CPU 请求为 1000m (1 核)。

3. 解决方案： 由于集群资源紧张，且 Nginx Ingress Controller 的 CPU 请求较高，导致无法找到满足条件的节点。可以尝试以下两种方案：

   • 扩容集群： 增加节点数量，提升集群的整体 CPU 资源容量。
   • 降低 Nginx Ingress Controller 的 CPU 请求： 根据实际情况适当降低 Nginx Ingress Controller 的 CPU 请求，例如降低到 500m (0.5 核)。

   # 示例：修改 Deployment 中的 resource requests
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-ingress-controller
   spec:
     template:
       spec:
         containers:
         - name: nginx-ingress-controller
           resources:
             requests:
               cpu: 500m # 降低 CPU 请求
               memory: 256Mi
             limits:
               cpu: 1000m
               memory: 512Mi
   

避坑经验总结

• 合理设置资源请求和限制： 避免设置过高或过低的资源请求和限制，根据实际需求进行调整。
• 监控集群资源使用情况： 实时监控集群的 CPU、内存、磁盘等资源使用情况，及时发现资源瓶颈。
• 善用 Kubernetes 的调度特性： 灵活运用 Node Selector、Taints and Tolerations、Affinity and Anti-Affinity 等调度特性，实现更精细化的 Pod 调度。
• 熟悉 Kubernetes 的 Events 机制： 及时查看 Pod 的 Events 列表，了解调度失败的具体原因。
• 掌握常用的 kubectl 命令： 熟练掌握 kubectl describe、kubectl top、kubectl get 等命令，可以帮助你快速定位和解决问题。

掌握这些 Kubernetes Pod 调度失败排查 的技巧，可以让你在面对 Pod 调度问题时不再束手无策，快速恢复服务，保障业务稳定运行。同时，也要关注如 etcd 的状态，以及 kube-scheduler 本身的健康状况，这些都可能影响 Pod 的调度。