DevOps知识中心
DevOps知识中心

排查常见的 Kubernetes 性能瓶颈

学习系统性地诊断和解决常见的 Kubernetes 性能瓶颈，包括 CPU 节流、内存 OOMKills 和调度延迟。本指南提供了可操作的命令和最佳实践，用于调整资源请求、优化 HPA 扩展以及识别底层集群约束，以确保最佳应用程序性能。

32 浏览量

故障排除常见的 Kubernetes 性能瓶颈

Kubernetes 是大规模管理容器化应用程序的强大平台，但随着环境的增长，性能瓶颈可能会出现，导致部署缓慢、服务无响应和运营成本增加。了解如何系统地诊断和解决这些问题对于维护健康高效的集群至关重要。本指南深入探讨了 Kubernetes 堆栈各个层面的常见性能陷阱，提供了可操作的步骤和必要的诊断命令，以确保您的应用程序平稳运行。

本文将使您能够超越基本的监控，专门关注识别与资源分配、扩展机制和基本集群操作相关的限制。

阶段 1：识别症状

在深入研究特定组件之前，请明确定义观察到的性能下降情况。常见症状通常属于以下类别之一：

  • 部署/更新缓慢： Pod 创建花费过多时间，或者滚动更新停滞不前。
  • 应用程序无响应： Pod 正在运行，但未能响应应用程序级别的流量（例如，高延迟、5xx 错误）。
  • 资源峰值高： 节点或特定部署中出现无法解释的 CPU 或内存利用率峰值。
  • 调度延迟： 新的 Pod 长期处于 Pending（待定）状态。

阶段 2：诊断资源限制（CPU 和内存）

资源管理不善是 Kubernetes 性能问题最常见的原因。不正确设置的请求（requests）和限制（limits）会导致节流（throttling）或 OOMKill（内存溢出终止）。

1. 检查资源利用率和限制

首先，使用 kubectl describe 和 kubectl top 检查受影响应用程序的资源分配情况。

可操作检查： 将 requests 和 limits 与指标服务器报告的实际使用情况进行比较。

# 获取命名空间中所有 pod 的资源使用情况
kubectl top pods -n <namespace>

# 检查特定 pod 的资源请求/限制
kubectl describe pod <pod-name> -n <namespace>

2. CPU 节流

如果容器的 CPU 使用率反复达到其定义的限制（limit），内核将对其进行节流，即使节点本身有可用容量，也会导致严重的延迟尖峰。这通常与一般的 CPU 饥饿相混淆。

诊断提示： 即使 kubectl top 没有显示节点上 100% 的 CPU 使用率，也要注意高延迟响应。节流是按容器发生的。

解决方案：
* 如果工作负载确实需要更多的处理能力，请增加 CPU limit。
* 如果应用程序处于忙等待状态，请优化应用程序代码，而不是仅仅增加限制。

3. 内存压力和 OOMKill

如果容器超过其内存限制（limit），Kubernetes 将启动一个内存不足 (OOM) 终止，导致容器反复重启。

诊断： 检查 Pod 状态中频繁的重启（查看 kubectl get pods 中的 RESTARTS 列），并检查日志中是否有 OOMKilled 事件。

# 检查 OOMKill 的近期事件
kubectl get events --field-selector involvedObject.name=<pod-name> -n <namespace>

解决方案：
* 如果 OOMKill 频繁发生，请立即增加内存 limit。
* 对于长期修复，请对应用程序进行性能分析，以查找并修复内存泄漏或减小堆大小。

最佳实践：明智地设置请求。 确保资源 requests 设置得尽可能接近预期的最低使用量。如果 requests 设置得太低，调度程序可能会过度承诺节点，导致所有 Pod 同时达到其需求时产生争用。

阶段 3：调查调度瓶颈

当 Pod 仍处于 Pending（待定）状态时，问题在于调度程序无法找到合适的节点。

1. 分析待定 Pod

在待定 Pod 上使用 kubectl describe pod 来读取事件（Events）部分。该部分通常包含无法调度的明确解释。

常见的调度程序消息：

  • 0/3 nodes are available: 3 Insufficient cpu.（节点容量问题）
  • 0/3 nodes are available: 3 node(s) had taint {dedicated: infra}, that the pod didn't tolerate.（污点/容忍度不匹配）
  • 0/3 nodes are available: 1 node(s) had taint {NoSchedule: true}, that the pod didn't tolerate.（节点压力或维护）

2. 集群资源饱和

如果由于缺乏 CPU/内存而导致调度延迟，则意味着集群的聚合容量不足。

解决方案：
* 向集群添加更多节点。
* 验证节点利用率是否因资源请求配置错误（参见阶段 2）而被人为地提高。
* 如果运行在云提供商上，请使用集群自动伸缩器 (CA)，以便在累积待定 Pod 时动态添加节点。

阶段 4：扩展机制中的性能问题

自动扩展应快速响应，但 Horizontal Pod Autoscaler (HPA) 或 Vertical Pod Autoscaler (VPA) 的错误配置可能会导致问题。

1. 水平 Pod 自动伸缩器 (HPA) 滞后

HPA 依赖 Metrics Server 来报告准确的 CPU/内存利用率或自定义指标。

诊断步骤：

  1. 验证 Metrics Server 健康状况： 确保 Metrics Server 正在运行且可访问。
    bash kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes"
  2. 检查 HPA 状态： 检查 HPA 配置和近期事件。
    bash kubectl describe hpa <hpa-name> -n <namespace>
    查找指示指标源不可用或扩展决策循环是否正常运行的消息。

瓶颈： 如果使用自定义指标，请确保外部指标提供商正常运行，并在 HPA 的 pollingInterval 内报告数据。

2. 垂直 Pod 自动伸缩器 (VPA) 交互

虽然 VPA 会自动调整资源请求，但如果在调整阶段频繁重启或调整 Pod 大小（特别是对于不能容忍重启的有状态应用程序），它可能会导致性能不稳定。

建议： 首先以 Recommender 模式使用 VPA，或者使用 updateMode: "Off" 仅观察推荐而不自动应用，以减轻不必要的调整中断。

阶段 5：网络和存储性能

当计算资源看起来正常时，网络或持久存储可能是瓶颈所在。

1. CNI（容器网络接口）问题

如果 Pod 之间的通信（尤其是跨节点）缓慢或间歇性失败，CNI 插件可能已过载或配置不当。

故障排除：
* 检查 CNI 守护进程集 Pod（例如 Calico、Flannel）的日志。
* 使用 ping 或 curl 测试不同节点上 Pod 之间的基本连通性。

2. 持久卷 (PV) 延迟

严重依赖磁盘 I/O 的应用程序（数据库、日志系统）如果底层持久卷的延迟很高，将会受到影响。

可操作检查： 确认配置程序类型（例如 AWS EBS gp3 与 io1），并验证该卷是否满足所需的 IOPS/吞吐量规格。

存储警告： 切勿将高吞吐量数据库直接运行在标准的 hostPath 卷上，除非了解底层磁盘的性能特性。对于要求苛刻的工作负载，请使用托管云存储解决方案或高性能本地存储配置程序。

结论和后续步骤

对 Kubernetes 性能进行故障排除是一个迭代过程，需要系统化的方法，从应用程序层开始，向外扩展到节点和集群级别。通过仔细检查资源定义、分析调度事件和验证扩展指标，您可以有效地隔离瓶颈。请记住，将 kubectl describe 和 kubectl top 作为您的主要诊断工具。

后续步骤：
1. 实施稳健的资源配额 (Resource Quotas)，以防止“嘈杂的邻居”耗尽关键应用程序的资源。
2. 定期查看Pod 重启计数，及早发现细微的 OOM 或应用程序故障行为。
3. 利用专门跟踪 CPU 节流指标的 Prometheus/Grafana 仪表板，而不仅仅是原始使用率。