Kubernetes自动伸缩全攻略：HPA、VPA、KEDA、CA、Karpenter谁更强？

原文链接（了解 Kubernetes 的简介）

Kubernetes 主要支持三种扩缩容策略：

参见链接

1. 水平自动扩展（HPA）

• 目标：根据观察到的CPU利用率或其他选定指标自动调整部署或有状态集中的Pod副本数量。
• 用例：当应用程序在负载增加时需要更多Pod，或者在需求减少时需要更少的Pod。
• 机制：Kubernetes监控Pod的指标（如CPU使用率或内存使用量）。当达到阈值时，HPA控制器会相应调整运行中的Pod副本数量。

链接

我们接下来会讲KEDA。

2. 垂直 Pod 自动扩缩容 (VPA)：

• 目的：根据 pod 实际使用情况随时间调整其 资源请求和限制（CPU/内存）。
• 应用场景：当你希望 Kubernetes 自动调整分配给 pod 的资源而不改变 pod 的数量时。
• 机制：VPA 监控 pod 的资源使用情况，并在必要时推荐调整 CPU 和内存的值。这些调整会在 pod 重启时应用，例如在滚动更新或维护期间。

3. 集群自动扩缩容（CA）

• 目标：根据所有工作负载对资源的需求情况自动调整Kubernetes集群中的节点数量。
• 使用场景：如果集群中的可用资源不足以满足需求，则Kubernetes会添加更多节点；当资源使用率较低时，则减少节点。
• 机制：Cluster Autoscaler组件在当资源限制导致无法调度Pod时增加节点，并移除利用率较低的节点。 自动缩放器会根据未调度的Pod和可用节点来做出扩展决策。

点击这里链接

下一节我们会讲 Karpenter。

除了Kubernetes自带的自动伸缩机制之外，例如KEDA（基于Kubernetes的事件驱动自动伸缩）和Karpenter这样的工具扩展了更动态或事件触发的工作负载的伸缩能力。这些工具可以无缝地与Kubernetes集成，并提供了更先进的伸缩功能。

目的：KEDA 实现了基于外部事件源（例如：消息队列、数据库、HTTP 请求）的事件驱动自动伸缩，而不是像传统方式那样基于 CPU 或内存等资源指标。

主要特点 ：

• 根据事件驱动的工作负载来扩展 Kubernetes 部署或作业。
• 支持多种事件来源，包括 Apache Kafka、Azure 事件中心、RabbitMQ、Redis Streams、Prometheus、AWS SQS 等。
• 在没有事件时，可以将工作负载缩减到 零 ，有助于优化资源利用并降低成本。
• 可以与 Kubernetes 本身的水平 Pod 自动扩展器 (HPA) 一起使用。

KEDA是怎么工作的：

1. Scaler：KEDA 使用“Scaler”来连接各种事件源。这些Scaler定义了如何将外部事件转换为与Kubernetes兼容的指标。
2. Kubernetes Metrics Adapter：KEDA 将事件数据暴露为Kubernetes可以使用的自定义指标，用于做出缩放调整。KEDA 向HPA提供这些指标，根据事件流量来调整pod的数量。
3. Scale-to-Zero：当无事件需要处理时，KEDA 可以将pod的数量减少到零。这对于仅在事件发生时需处理事件的工作负载特别有用，比如消息队列。

示例用例说明：你有一个微服务，用于处理来自Azure队列的消息。KEDA可以监控队列中的消息，当队列中有消息时，KEDA会根据消息数量调整微服务的Pod数量。一旦队列变为空，KEDA会减少Pod的数量，甚至减少到零，直到有新的消息出现。

安装与使用：

• 你可以使用 Helm 或 kubectl 在 Kubernetes 集群中安装 KEDA。

helm install keda kedacore/keda --namespace keda  # 使用 Helm 安装 KEDA 监控器，指定命名空间为 keda

• 安装了 KEDA 后，您可以定义代表工作负载的 ScaledObjects。这些对象用于定义您的工作负载应如何根据事件进行扩缩。

例如**ScaledObject**定义：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: queue-scaler
spec:
  scaleTargetRef:
    name: worker-deployment
  minReplicaCount: 最小副本数
  maxReplicaCount: 最大副本数
  triggers:
    - type: azure-queue
      metadata:
        queueName: myqueue
        connection: AzureWebJobsStorage

目的：Karpenter 是一个开源工具，旨在根据运行在 Kubernetes 上的工作负载的实际情况，动态快速提供基础设施资源（如计算节点）。

特点：

• 按需节点供应：Karpenter 根据工作负载需求快速添加节点，并在不再需要时移除它们。
• 成本优化：它根据工作负载动态调整实例大小，减少浪费并提高资源利用率。
• 原生云：Karpenter 与诸如 AWS 等云提供商集成，根据 pod 需求提供最具成本效益的计算资源选项。
• 自定义实例类型：它根据 pod 的需求动态提供不同类型的实例和大小的资源。

Karpenter 是怎么工作的，

1. Pod 调度：当 Kubernetes 因节点资源不足而无法调度 Pod 时，Karpenter 会收到一个调度事件。
2. 节点供应：Karpenter 会检查调度约束（例如，资源请求、亲和性和反亲和性规则），并为特定工作负载供应优化的新节点。它可以基于成本和性能需求提供多种类型的实例。
3. 节点排空：当工作负载需求下降时，Karpenter 会自动移除利用率较低的节点，并重新平衡工作负载，确保资源高效利用。

示例用例：运行在AWS上的Kubernetes集群根据传入的网络流量来扩展Pod数量。当突然出现流量激增时，Karpenter检测到需要额外的资源并调配新的EC2实例，这些实例将是最优的大小和类型。一旦流量下降，Karpenter会优雅地清空未充分利用的节点并缩减相应的基础设施。

安装与使用：简单几步教你如何安装和使用

• Karpenter 可以通过 Helm 或其他包管理器来安装。例如，在 AWS 上，可以使用 Helm 安装 Karpenter：

helm repo add karpenter https://charts.karpenter.sh helm repo update helm install karpenter karpenter/karpenter \   --namespace karpenter --create-namespace \   --set serviceAccount.create=true \   --set controller.clusterName=<cluster-name> \   --set controller.cluster端点=<cluster-endpoint>

*Karpenter 根据 pod 请求自动分配节点，所以一般不需要额外的手动设置。

• 监控资源使用情况：监控 CPU、内存和其他资源的使用情况以设置合适的自动扩展阈值非常重要。使用像 Prometheus 和 Grafana 这样的监控工具来获得详细信息。
• 合理配置 Pod 和节点资源：避免为 Pod 设置过高或过低的资源请求。过度配置会浪费资源，而配置不足会导致 Pod 受限，性能下降。
• 利用 KEDA 实现事件驱动扩展：对于由外部事件驱动的工作负载（例如消息队列或 webhook），可以考虑使用 KEDA 根据这些外部源来扩展 Pod 数量。这在传统 CPU 或内存扩展无法满足需求时尤为理想。
• 使用 Karpenter 实现高效的节点管理：在云环境中，Karpenter 通过动态选择实例类型和大小来优化节点扩展，从而降低成本并提高性能。这确保了基础设施能够根据当前的工作负载需求进行调整，从而减少资源浪费并提高成本效益。

别忘记点击鼓掌和关注按钮，这样我就能写更多类似的文章了。

• Horizontal Pod 自动水平扩缩 (HPA) 根据资源使用情况指标（如 CPU 和内存）调整 Pod 的数量。
• Vertical Pod 自动垂直扩缩 (VPA) 调整单个 Pod 的资源请求和限制。
• Cluster 自动扩缩 (CA) 根据整个集群的资源需求调整节点的数量。
• KEDA 引入事件驱动的自动扩缩，使 Kubernetes 能够根据外部事件（如消息队列）进行调整。
• Karpenter 高效管理计算资源（节点）的动态分配，以匹配工作负载需求，从而优化成本并提高性能。

视频链接

在 Kubernetes 中使用合适的扩展策略和工具有助于保证应用程序运行高效且经济实惠，无论是在云端还是本地部署。

• Kubernetes 自动伸缩，HPA vs. VPA vs. Keda vs. CA vs. Karpenter vs. Fargate 的比较。
• Kubernetes 自动伸缩简介及实施的最佳实践。