消除 Kubernetes 中的未利用资源

Kubernetes 中的未利用资源不仅仅是预算项目——它们是效率、可扩展性和性能的隐形杀手。

浪费的 CPU 周期、空闲内存和未充分利用的节点都会累积，增加成本的同时使集群处理实际工作负载的能力下降。如果你在大规模使用 Kubernetes，你会知道这些低效问题如何演变成实际的操作难题。

如今，随着Scaleops 等智能自动化工具的兴起，你可以快速轻松地检测、修复和预防未利用资源，包括“不可驱逐的工作负载”，如 PDB、配置错误的 Safe-to-Evict 注解和“裸露的 Pod”。自动化这一过程可以同时减少资源浪费和手动工作。

什么是 Kubernetes 中的未利用资源？

未利用资源是指由于配置不当或工作负载分配不佳而闲置但保留的计算、内存或存储容量。这些低效问题以多种方式显现：

• Pod 使用的资源远低于其请求的资源。
• 由于不可驱逐的工作负载，节点处于空闲状态。
• 过度配置的集群浪费了宝贵的云资源。

为什么未利用资源比以往任何时候都更重要

每个空闲的 CPU 核心或未使用的内存 GB 都代表浪费的钱。除了成本之外，资源低效还会破坏可扩展性，使集群臃肿且无法有效响应变化的工作负载。

随着集群规模的扩大，这些低效问题会加剧，将可管理的问题变成操作危机。解决未利用资源不仅仅是省钱——而是释放 Kubernetes 设置的全部潜力。

为什么会发生这种情况？

Kubernetes 的灵活性是有代价的：复杂性。虽然它为团队提供了精确管理资源的工具，但要实现最佳利用率需要深入了解资源请求、限制、调度策略和自动缩放机制。

未利用资源的常见原因包括：

• 配置错误的 **Pod 中断预算 (PDB)**，阻止 Pod 被驱逐。
• 过度使用safe-to-evict: false 注解。
• 没有管理控制器的裸露 Pod，使其不可驱逐。
• 过于保守的资源请求，远超实际使用量。

解决未利用资源的关键挑战

1. 可见性： 没有强大的监控，未利用资源可能会被忽视，直到成本飙升或性能下降。
2. 不可驱逐的工作负载： PDB 和关键注解通常会阻止自动缩放器优化资源。
3. 手动工作： 识别、分析和修复低效问题需要大量时间和专业知识，分散了其他工程优先事项。
4. 可扩展性： 集群越大，手动微调数百或数千个节点上的资源分配就越困难。

实现解决方案

现代工具如ScaleOps 自动化了繁重的工作。

通过检测低效问题、智能重新调度工作负载并持续监控资源浪费，ScaleOps 等工具弥合了 Kubernetes 的原始能力与实际可用性之间的差距。

凭借智能算法和直观的仪表板，ScaleOps 和其他现代工具可以在不进行持续手动调整的情况下优化资源使用，并实现最佳结果。

你将学到什么

在本指南中，我们将分解：

• Kubernetes 中的未利用资源是什么以及为什么它们至关重要。
• 未利用资源的主要原因，包括“不可驱逐的工作负载”。
• 自动化资源优化的工具和策略，包括 ScaleOps。
• 管理集群资源效率的最佳实践和陷阱。

让我们深入探讨并解决正在耗尽 Kubernetes 集群效率的问题。

了解 Kubernetes 中的未利用资源

在 Kubernetes 中高效使用资源对于保持成本效益、可扩展性和性能至关重要。然而，各种因素可能导致资源被分配但未充分利用，使其闲置并增加成本。让我们探讨未利用资源是什么、为什么发生以及如何有效解决它们。

什么是 Kubernetes 中的未利用资源？

未利用资源是指分配给 Kubernetes 集群中节点或 Pod 的 CPU、内存或存储容量，但未被应用程序或工作负载主动使用。这些闲置资源通常由于以下原因而发生：

• 过度配置： 分配的资源超过所需。
• 不当调度： 工作负载在节点间分配不佳。
• 自动缩放器限制： 由于特定 Pod 配置或约束，无法调整或缩减节点。

为什么会发生这种情况

1. 保守的资源请求： 开发者通常高估资源需求以避免中断，导致 Pod 使用的 CPU 或内存远低于其分配量。
2. 受限的工作负载移动性： 某些工作负载（如关键系统 Pod）被配置为保持在特定节点上。
3. 不平衡的调度： Kubernetes 的默认调度可能会导致某些节点过度分配而其他节点空闲，因为装箱算法不足。
4. 节点级约束： 集群自动缩放器和其他工具无法驱逐标记为不可驱逐的 Pod，导致节点未充分利用。

检测未利用资源

使用Prometheus 和Grafana 等工具监控集群指标，以识别请求和实际资源使用之间的差异。例如，以下 PromQL 查询显示 Pod 的 CPU 使用情况：rate(container_cpu_usage_seconds_total[5m])

将其与kube_pod_container_resource_requests 配对以比较请求和实际使用情况：kube_pod_container_resource_requests{resource="cpu"}

这些指标可以突出显示过度配置的 Pod 或未充分利用的节点。

未利用资源的类型

一般未充分利用

一般未充分利用发生在资源（CPU、内存）被分配但未被 Pod 完全消耗时。这通常源于过于保守的资源请求和不匹配的缩放策略。

为什么会发生这种情况

1. 峰值开销： 开发者根据潜在峰值使用量而不是实际平均使用量来配置资源。
2. 静态资源分配： 为随时间需求变化的工作负载设置固定的资源限制。

如何检测

通过比较实际使用情况与请求，使用监控工具检查低资源利用率比率：kubectl top pods

此命令显示每个 Pod 的当前 CPU 和内存消耗，便于识别未充分利用的 Pod。

示例：过度配置的部署

apiVersion: apps/v1
kind: Deployment
metadata:
 name: over-provisioned-app
spec:
 replicas: 3
 template:
   spec:
     containers:
     - name: app-container
       image: app-image:v1
       resources:
         requests:
           cpu: "500m"
           memory: "1Gi"
         limits:
           cpu: "1"
           memory: "2Gi"

如果每个 Pod 的实际使用量约为200m CPU 和512Mi 内存，则此部署浪费了超过一半的分配资源。

常见用例

• 预生产环境： 资源过度配置以模拟峰值负载。
• 可突发工作负载： 使用量偶尔激增的应用程序通常会导致过度配置。

不可驱逐的工作负载

不可驱逐的工作负载是指 Kubernetes 无法重新调度或移除的 Pod，这成为自动缩放器效率的重大障碍。使用正确的工具可以轻松解决 https://scaleops.com/blog/scaleops-pod-placement-optimizing-unevictable-workloads/这些问题，但手动处理可能会成为永久的痛点。

不可驱逐工作负载的关键贡献者

1. Pod 中断预算 (PDB)

PDB 定义了在干扰期间必须保持运行的最小副本数。这可以防止关键工作负载被驱逐，但会阻碍节点缩放。

示例 PDB 配置：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
 name: my-app-pdb
spec:
 minAvailable: 2
 selector:
   matchLabels:
     app: my-app

此配置确保始终运行两个副本，但在缩减节点时可能会阻止驱逐，导致某些节点未充分利用。

2. Safe-to-Evict 注解

标记为safe-to-evict: false 的 Pod 无法在节点缩放或装箱操作期间被移除或重新调度。

注解示例：

metadata:
 annotations:
   cluster-autoscaler.kubernetes.io/safe-to-evict: "false"

3. 裸露 Pod

直接创建的没有控制器（如 Deployments、ReplicaSets）的 Pod 缺乏重新调度和缩放所需的自动化。

裸露 Pod 示例：

apiVersion: v1
kind: Pod
metadata:
 name: standalone-pod
spec:
 containers:
 - name: app-container
   image: app-image:v1

这些 Pod 阻止节点缩减，导致资源闲置。

如何解决不可驱逐的工作负载

在开始之前，我的建议是使用智能指定工具自动化这一过程，我最喜欢的工具是Scaleops。

我选择这些工具的原因很简单：

1. 安装 10 分钟后（无需代码更改/配置），你将看到 95% 以上的未利用资源被消除，并且不会再回来。
2. 它自动完成，无需任何手动工作。
3. 它持续自动检测、修复和预防未利用资源。启动并忘记。

但是，你也可以选择手动并反复执行此操作，无论出于何种原因。如果你这样做，以下步骤可能会有所帮助：

1. 调整 Pod 中断预算

审查并更新 PDB，以在可能的情况下允许更多灵活的驱逐：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
 name: updated-pdb
spec:
 maxUnavailable: 1
 selector:
   matchLabels:
     app: my-app

2. 谨慎使用 Safe-to-Evict

仅对关键工作负载应用safe-to-evict 注解。

3. 将裸露 Pod 替换为受控工作负载

使用 Deployments 或 StatefulSets 等控制器部署工作负载，以确保适当的管理和可扩展性。

示例部署之前裸露的 Pod：

apiVersion: apps/v1
kind: Deployment
metadata:
 name: managed-app
spec:
 replicas: 2
 selector:
   matchLabels:
     app: my-app
 template:
   metadata:
     labels:
       app: my-app
   spec:
     containers:
     - name: app-container
       image: app-image:v1

这确保 Kubernetes 可以有效地扩展和重新调度工作负载。

通过解决一般未充分利用和不可驱逐的工作负载，Kubernetes 集群可以更高效地运行，降低成本并提高可扩展性。保持主动，定期审计并使用自动化工具以保持最佳资源利用率。

检测、修复和预防未利用资源

为什么要检测和预防未利用资源？

未利用资源导致：

• 增加成本： 闲置资源增加云账单。
• 性能下降： 资源碎片化影响工作负载效率。
• 可扩展性有限： 低效集群难以应对扩展需求。

智能自动化工具如何提供帮助

ScaleOps 等工具通过以下方式提供自动化解决方案来解决资源低效问题：

1. 检测： 通过全面的集群分析识别未充分利用的节点、不可驱逐的 Pod 和资源分配问题。
2. 修复： 应用智能调度算法重新分配工作负载，而不违反 PDB 或 safe-to-evict 规则。
3. 预防： 持续监控集群，确保最小化不可驱逐的工作负载并有效利用资源。

以下是 ScaleOps 如何优化不可驱逐的工作负载：# 示例 ScaleOps 优化

apiVersion: scaleops/v1
kind: PodOptimization
metadata:
 name: optimize-workloads
spec:
 policies:
   - type: "reschedule"
     targets:
       - labelSelector: "safe-to-evict: false"
     action: "optimize-placement"

此配置识别不可驱逐的 Pod 并优化其放置以更好地分配资源。

手动检测和修复 Kubernetes 中的未利用资源

虽然像 ScaleOps 这样的自动化工具简化了未利用资源的检测和纠正，但手动方法提供了灵活性和直接控制。使用 Kubernetes 原生工具和命令，你可以分析资源使用情况并解决集群中的低效问题。

检测未利用资源

使用kubectl top 识别未充分利用的 Pod

kubectl top 命令检索资源使用情况的指标，如 CPU 和内存，适用于集群中的 Pod 和节点。要识别未充分利用的 Pod：kubectl top pods --all-namespaces

此命令显示所有运行 Pod 的当前资源使用情况。将报告的值与 Pod 配置中定义的资源请求进行比较。例如，使用100m CPU 但请求500m CPU 的 Pod 表示过度配置。

分析节点以查找资源低效问题

要分析节点及其利用率水平，请运行：kubectl top nodes

此命令显示节点间的总 CPU 和内存使用情况。利用率持续较低的节点可能存在不可驱逐的工作负载或调度不平衡。

比较资源请求与实际使用情况

使用 Prometheus 指标比较请求和实际使用情况。对于 CPU 利用率，以下 PromQL 查询很有帮助：rate(container_cpu_usage_seconds_total[5m])

将其与请求的资源进行比较：kube_pod_container_resource_requests{resource="cpu"}

此比较突出显示分配的资源超过其消耗的 Pod。

修复过度配置的资源

调整资源请求和限制

过度配置的 Pod 浪费了可以分配给其他地方的资源。要解决此问题，请更新未充分利用 Pod 的资源请求和限制。例如：

apiVersion: apps/v1
kind: Deployment
metadata:
 name: resource-optimized-app
spec:
 replicas: 2
 template:
   spec:
     containers:
     - name: app-container
       image: app-image:v1
       resources:
         requests:
           cpu: "250m"
           memory: "512Mi"
         limits:
           cpu: "500m"
           memory: "1Gi"

此更新将资源请求与观察到的使用情况对齐，减少浪费的同时保持性能。

解决不可驱逐的工作负载

审查和修改 Pod 中断预算 (PDB)

Pod 中断预算 (PDB) 可以阻止驱逐，导致资源闲置。列出集群中的所有 PDB：

kubectl get pdb --all-namespaces

检查minAvailable 或maxUnavailable 值。例如：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
 name: app-pdb
spec:
 minAvailable: 3
 selector:
   matchLabels:
     app: critical-app

如果minAvailable 值过高，请调整以允许在缩放期间更灵活：

spec:
 minAvailable: 2

移除 Safe-to-Evict 注解

Safe-to-evict 注解阻止 Pod 被自动缩放器驱逐。要查找带有此注解的 Pod：

kubectl get pods --all-namespaces -o json | jq '.items[] | select(.metadata.annotations."cluster-autoscaler.kubernetes.io/safe-to-evict" == "false") | .metadata.name'

一旦识别，编辑 Pod 配置以移除注解：

kubectl edit pod <pod-name>

删除以下注解：

metadata:
 annotations:
   cluster-autoscaler.kubernetes.io/safe-to-evict: "false"

将裸露 Pod 转换为受控工作负载

没有控制器的裸露 Pod 阻止节点缩放。将其转换为受控工作负载，如 Deployments。导出 Pod 配置：

kubectl get pod naked-pod -o yaml > naked-pod.yaml

修改 YAML 以创建 Deployment：

apiVersion: apps/v1
kind: Deployment
metadata:
 name: managed-app
spec:
 replicas: 1
 selector:
   matchLabels:
     app: naked-pod
 template:
   metadata:
     labels:
       app: naked-pod
   spec:
     containers:
     - name: app-container
       image: app-image:v1

应用更新后的配置并删除原始裸露 Pod：

kubectl apply -f managed-app.yaml
kubectl delete pod naked-pod

持续监控和优化

定期监控是防止未利用资源再次发生的关键。使用 Prometheus 和 Grafana 等工具设置仪表板和警报以监控资源使用指标。监控请求和实际使用之间的差异，以主动调整资源分配。这种手动方法确保集群保持优化和成本效益。

管理未利用资源的最佳实践

如果不使用智能自动化解决方案并完全手动操作，请确保：

1. 定期审计 PDB

确保 PDB 配置允许在缩放或维护期间必要的驱逐。避免过于严格的策略，锁定 Pod 位置。 2.谨慎使用 Safe-to-Evict 注解

仅对真正关键的工作负载使用safe-to-evict: false。过度使用会限制自动缩放器优化能力。 3.使用控制器部署工作负载

避免裸露 Pod，使用 Deployments、ReplicaSets 或 StatefulSets 等控制器部署工作负载。这确保适当的管理和驱逐。 4.采用自动化资源管理工具

利用 ScaleOps 等工具自动化检测和优化未充分利用的资源。 5.持续监控资源使用情况

实施强大的监控，实时跟踪资源利用率并识别低效问题。

需要注意的陷阱

如果不使用智能自动化解决方案并完全手动操作，请注意：

1. 严格的 PDB

配置错误的 PDB 可以阻止自动缩放器操作，导致资源闲置。 2.过度使用不可驱逐注解

将太多 Pod 标记为不可驱逐会妨碍自动缩放努力并增加成本。 3.忽视裸露 Pod

未能有效管理裸露 Pod 会阻止节点缩放并浪费资源。 4.不一致的资源监控

没有定期审计或监控的集群可能会随着时间的推移积累低效问题。 5.缺乏自动化

依赖手动流程管理集群资源可能导致错误和延迟。

结论

高效资源管理是保持可扩展、成本效益 Kubernetes 集群的关键。通过了解和解决未利用资源，工程团队可以实现显著的成本节约和性能提升。

我们讨论了：

• 未利用资源的类型，包括不可驱逐的工作负载。
• 手动检测和修复这些问题的挑战。
• ScaleOps 等工具如何自动化优化、提高可见性并简化资源管理。

首先使用 Kubernetes 原生工具审查集群中的低效问题，或深入研究像 ScaleOps 这样的自动化解决方案以获得更简化的方法。