在 Kubernetes 集群中，CPU 突然爆满可能导致 Pod 状态变为
Pending，影响应用的可用性。本文将深入分析其原因，并附上相关命令及其执行结果，帮助你更好地理解和解决此问题。

1. 问题描述

在 Kubernetes 集群中，当 CPU 突然爆满时，Pod 可能无法获得所需的资源，从而导致其状态变为 Pending。这种情况通常与资源管理、流量变化或配置错误有关。

2. 原因分析及命令执行结果

2.1 突发流量

• 描述: 应用在特定时间段内接收到意外的高流量，超出了 Pod 的处理能力。

• 影响: 导致现有 Pod CPU 使用率飙升，影响新 Pod 的调度。

• 命令:

  kubectl top pods --all-namespaces
  

• 示例输出:

  NAMESPACE     NAME           CPU(cores)   MEMORY(bytes)
  default       my-app-1      900m         256Mi
  default       my-app-2      850m         256Mi
  default       my-app-3      800m         256Mi
  

• 分析: 以上输出显示多个 Pod 的 CPU 使用率接近或超过 800m，表明流量飙升可能导致资源不足。

2.2 资源限制配置不当

• 描述: Pod 的 CPU 和内存请求及限制配置不当，导致资源被过度使用。

• 影响: 资源竞争加剧，影响新 Pod 的调度。

• 命令:

  kubectl get pods <pod-name> -o yaml
  

• 示例输出:

  apiVersion: v1
  kind: Pod
  metadata:
    name: my-app-1
  spec:
    containers:
    - name: app-container
      resources:
        requests:
          cpu: "200m"
          memory: "256Mi"
        limits:
          cpu: "1"
          memory: "1Gi"
  

• 分析: 该 Pod 的请求为 200m，但其 CPU 使用率接近 900m，说明实际需求超过了配置的限制。

2.3 集群规模不足

• 描述: 集群中的节点数量不足，无法满足新 Pod 的资源请求。

• 影响: 节点的 CPU 和内存资源有限，导致调度器无法为新的 Pod 分配资源。

• 命令:

  kubectl get nodes
  

• 示例输出:

  NAME            STATUS   ROLES    AGE   VERSION
  node-1         Ready    <none>   30d   v1.23.0
  node-2         Ready    <none>   30d   v1.23.0
  

• 分析: 只有两个节点，可能无法处理所有 Pod 的资源请求，特别是在流量高峰期间。

2.4 资源泄漏

• 描述: 应用或服务中的内存或 CPU 资源未被正确释放，导致资源被长期占用。

• 影响: 随着时间推移，集群中的可用资源减少，最终导致 Pod 状态变为 Pending。

• 命令:

  kubectl logs <pod-name>
  

• 示例输出:

  2023-11-06 12:00:00.123 ERROR [main] com.example.App - Memory leak detected
  

• 分析: 日志中出现内存泄漏警告，表明应用未能有效管理资源，可能导致 CPU 和内存使用飙升。

2.5 Node 资源耗尽

• 描述: 某些节点的资源被完全占用，导致无法调度新的 Pod。

• 影响: 如果节点的 CPU 或内存被大量使用，调度器将无法在该节点上调度新的 Pod。

• 命令:

  kubectl top nodes
  

• 示例输出:

  NAME           CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
  node-1        1000m        100%   2Gi             80%
  node-2        800m         80%    1.5Gi           60%
  

• 分析: node-1 的 CPU 使用率达到 100%，这会阻止在该节点上调度新的 Pod，导致 Pending 状态。

3. 故障排查步骤

步骤 1: 检查集群资源使用情况

使用以下命令检查节点和 Pod 的资源使用情况，以评估是否存在资源紧张的情况。

• 命令:

  kubectl top nodes
  kubectl top pods --all-namespaces
  

步骤 2: 查看 Pod 状态和事件

检查 Pending 状态的 Pod 的详细信息，了解导致其无法调度的原因。

• 命令:

  kubectl get pods --all-namespaces
  kubectl describe pod <pod-name> -n <namespace>
  

步骤 3: 检查资源配额和限制

检查集群中的资源配额和限制配置。

• 命令:

  kubectl get resourcequotas --all-namespaces
  kubectl get limitranges --all-namespaces
  

步骤 4: 检查调度器事件

查看调度器的事件日志，识别因资源不足而导致 Pod Pending 的相关信息。

• 命令:

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

4. 解决方案

解决方案 1: 扩展集群资源

根据需要增加节点数量或升级节点的规格（增加 CPU 和内存）。

解决方案 2: 优化资源请求和限制

检查并调整 Pod 的资源请求和限制配置，确保其合理。

解决方案 3: 使用 Horizontal Pod Autoscaler (HPA)

配置 HPA，根据 CPU 使用情况自动扩展 Pod 数量。

解决方案 4: 监控和告警

配置监控系统，监控 CPU 和内存使用情况，并设置告警。

解决方案 5: 资源泄漏排查

定期检查应用日志和性能指标，识别和修复资源泄漏问题。

解决方案 6: 采用 Node Affinity 或 Taints/Tolerations

配置节点亲和性或污点/容忍策略，以优化 Pod 的调度。

5. 总结

Kubernetes 集群中的 CPU 突然爆满导致 Pod 状态变为 Pending 是一种常见且影响深远的问题。通过识别问题的根本原因，并采取相应的解决方案，可以有效缓解这一问题，确保集群的稳定性和应用的高可用性。定期监控集群资源使用情况，合理配置资源请求与限制，以及使用自动扩展策略等措施将有助于提高集群的弹性和应对突发流量的能力。