什么是 Kubernetes HPA？它如何帮助您节省云成本？

自动扩缩容是 Kubernetes 的核心功能。您对扩缩容机制（HPA、VPA 和集群自动扩缩器）的配置越精细，运行应用程序的资源浪费和成本就越低。 

Kubernetes 提供了三种自动扩缩容机制：水平 Pod 自动扩缩容 (HPA)、垂直 Pod 自动扩缩容 (VPA) 和集群自动扩缩容。每一种机制都为实现云成本优化这一总体目标增添了独特的要素。 

本文重点介绍水平 Pod 自动扩缩容。您可以通过配置集群上的水平 Pod 自动扩缩容 (HPA) 设置，根据各种指标来控制运行的 Pod 数量。这样，您就可以根据需求进行向上或向下扩缩容。 

继续阅读，了解 Kubernetes HPA 是什么以及它如何通过实际示例工作。

我们先快速回顾一下 Kubernetes 自动扩缩容。

在深入了解水平 Pod 自动扩缩器 (HPA) 之前，让我们先来看一下 Kubernetes 自动扩缩容机制。 

Kubernetes 支持三种类型的自动扩缩容： 

• 水平 Pod 自动扩缩容 (HPA)，用于扩展应用程序的副本数量。 
• 垂直 Pod 自动扩缩器 (VPA)可以扩展容器的资源请求和限制。 
• 集群自动扩缩容程序，用于调整集群的节点数。 

这些自动扩缩容器在 Kubernetes 的两个层级上运行：Pod 层级和集群层级。Kubernetes 的 HPA 和 VPA 方法在 Pod 层级调整资源，而集群自动扩缩容器则扩展或缩减集群中的节点数量。 

什么是 Kubernetes 水平 Pod 自动扩缩容 (HPA)？

在许多应用中，使用情况会随时间变化——例如，晚上访问电商网站的人数通常比中午时分要多。当应用的需求发生变化时，您可以使用水平 Pod 自动扩缩器 (HPA) 根据 CPU 利用率自动添加或移除 Pod。

HPA 根据您提供的外部指标或自定义指标做出自动扩缩容决策。

首先，您需要使用 MIN 和 MAX 值定义在任何给定时间应运行的副本数量。配置完成后，水平 Pod 自动扩缩容控制器会负责检查指标并根据需要进行调整。默认情况下，它每 15 秒检查一次指标。

水平 Pod 自动扩缩容的工作原理是什么？

配置 HPA 控制器后，系统将监控部署中的 Pod，并判断是否需要更改 Pod 副本数。为此，HPA 会计算每个 Pod 指标值的加权平均值，并计算移除或添加副本是否能使该值更接近目标值。

示例场景

假设您的部署目标 CPU 利用率为 50%。目前有五个 Pod 正在运行，平均 CPU 利用率为 75%。在这种情况下，HPA 控制器将添加三个副本，以使 Pod 的平均利用率更接近 50% 的目标值。

何时使用 Kubernetes HPA？

Horizo​​ntal Pod Autoscaler 是一种自动扩缩容机制，非常适合扩展无状态应用程序。但它也可以用于支持扩展有状态集合。 

对于需求经常变化的工作负载，为了节省成本，请将 HPA 与集群自动扩缩容结合使用。这样，当 Pod 数量减少时，就能减少活动节点的数量。

水平舱自动扩缩器的局限性 

请注意，HPA 也存在一些局限性：

• 可能需要从横向扩展的角度来设计应用程序架构，以便将工作负载分配到多个服务器上。 
• HPA可能无法始终满足意外的需求高峰，因为新的虚拟机可能需要几分钟才能加载完毕。
• 如果您未对 pod 设置 CPU 和内存限制，则它们可能会频繁终止或浪费资源；如果您选择反其道而行之，则它们可能会浪费资源。 
• 如果集群容量不足，HPA 无法进行扩容，直到向集群添加新节点。集群自动扩缩器 (CA) 可以自动执行此过程。 

运行水平 Pod 自动扩缩容程序需要哪些组件？

水平 Pod 自动扩缩器 (HPA) 是 Kubernetes 集群管理器的一项功能，它可以监视 Pod 容器的 CPU 使用情况，并根据需要自动调整其大小，以维持目标利用率水平。 

为此，HPA 需要指标源。例如，当基于 CPU 使用率进行扩展时，它会使用metrics-server。如果您想使用自定义或外部指标进行 HPA 扩展，则需要部署一个实现了 custom.metrics.k8s.io API 或 external.metrics.k8s.io API 的服务；这将提供一个与监控服务或指标源的接口。 

自定义指标包括网络流量、内存或任何与 Pod 应用程序相关的值。如果您的工作负载使用标准 CPU 指标，请确保在 Pod 规范中配置容器的 CPU 资源限制。

运行 Kubernetes HPA 的专家技巧

1. 安装 metrics-server 

Kubernetes HPA 需要访问每个 Pod 的资源指标来制定扩展决策。这些值是从 metrics-server 提供的 metrics.k8s.io API 获取的。 

2. 为所有 Pod 配置资源请求

HPA 进行扩展决策的另一个关键信息来源是观察到的 Pod CPU 利用率值。但这些值是如何计算的呢？它们是单个 Pod 资源请求的百分比。 

如果某些容器缺少资源请求值，这些计算可能会完全不准确，导致运行效率低下和扩展决策失误。因此，对于由 HPA 进行扩展的 Kubernetes 控制器中的每个 Pod 的所有容器，都值得配置资源请求值。

3. 配置自定义指标和外部指标

自定义指标

您可以配置水平 Pod 自动扩缩器 (HPA) 以根据自定义指标进行扩缩容，这些自定义指标是您从应用程序收集的内部指标。HPA 支持两种类型的自定义指标： 

• Pod 指标 - 应用程序中所有 Pod 的平均值，仅支持 AverageValue 目标类型。 
• 对象指标 - 描述与应用程序位于同一命名空间中的任何其他对象的指标，支持 Value 和 AverageValue 目标类型。 

配置自定义指标时，请记住为 Pod 和对象指标使用正确的目标类型。 

外部指标

这些指标使 HPA 能够根据第三方监控系统提供的指标自动扩展应用程序。外部指标支持“值”和“平均值”两种目标类型。 

在自定义指标和外部指标之间进行选择时，应选择自定义指标，因为获取外部指标 API 比获取内部指标 API 更困难。

4. 确认您的 HPA 和 VPA 策略不冲突。

垂直 Pod 自动扩缩容器可自动处理请求和限制配置，从而降低开销并节省成本。而水平 Pod 自动扩缩容器则旨在横向扩展，而非纵向扩展或纵向缩减。 

在为企业级或专用级服务层设计集群时，请仔细检查您的分箱和打包密度设置是否相互冲突。

5. 使用实例权重分数

假设你的某个工作负载最终消耗的资源超过了它请求的资源。这是因为资源确实需要吗？还是因为资源可用但并非迫切需要，所以工作负载才消耗了这些资源？

在为自动扩缩容选择实例大小和类型时，请使用实例权重。实例权重尤其适用于采用多样化分配策略和使用竞价型实例的情况。

示例：HPA演示

由于这是 Kubernetes 的核心特性之一，我们使用的云服务提供商应该无关紧要。但在这个例子中，我们将使用 GKE。 

您可以通过用户界面创建集群，也可以通过 gcloud 工具创建集群，如下所示：

gcloud container \

    --project "[your-project]" clusters create "[cluster-name]" \

    --release-channel None \

    --zone "europe-west3-c" \

    --node-locations "europe-west3-c" \

    --machine-type "e2-standard-2" \

    --image-type "COS_CONTAINERD" \

    --disk-size "50" \

    --enable-autorepair \

    --num-nodes "3"

然后我们可以使用以下命令连接到集群：

gcloud container clusters get-credentials [cluster-name] --zone europe-west3-c --project [your-project]

这也会将您的上下文切换到集群，因此无论何时您使用 kubectl，您都将处于此集群的上下文中。

完成上述步骤后，我们可以验证是否能够看到这些节点。 

> kubectl get nodes

NAME                                      STATUS   ROLES    AGE     VERSION

gke-valdas-1-default-pool-cf1cd6be-cvc4   Ready    <none>   4m50s   v1.22.11-gke.400

gke-valdas-1-default-pool-cf1cd6be-q62h   Ready    <none>   4m49s   v1.22.11-gke.400

gke-valdas-1-default-pool-cf1cd6be-xrf0   Ready    <none>   4m50s   v1.22.11-gke.400

GKE 预装了指标服务器；我们可以使用以下方式验证这一点：

> kubectl get pods -n kube-system | grep metrics

gke-metrics-agent-n92rl                              1/1     Running   0          7m34s

gke-metrics-agent-p5d49                              1/1     Running   0          7m33s

gke-metrics-agent-tf96r                              1/1     Running   0          7m34s

metrics-server-v0.4.5-fb4c49dd6-knw6v                2/2     Running   0          7m20s

注意：如果您的集群没有指标服务器，您可以使用一条命令轻松安装它：

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

您可以在这里找到更多信息：https://github.com/kubernetes-sigs/metrics-server 

我们还可以使用 `top` 命令来验证指标是否已被收集：

> kubectl top pods -A

NAMESPACE     NAME                                                 CPU(cores)   MEMORY(bytes)

kube-system   event-exporter-gke-5479fd58c8-5rt4b                  1m           12Mi

kube-system   fluentbit-gke-5r6v5                                  5m           22Mi

kube-system   fluentbit-gke-nwcx9                                  4m           25Mi

kube-system   fluentbit-gke-zz6gl                                  4m           25Mi

kube-system   gke-metrics-agent-n92rl                              2m           26Mi

kube-system   gke-metrics-agent-p5d49                              3m           27Mi

kube-system   gke-metrics-agent-tf96r                              3m           26Mi

kube-system   konnectivity-agent-6fbc8c774c-4vvff                  1m           6Mi

kube-system   konnectivity-agent-6fbc8c774c-lsk26                  1m           7Mi

kube-system   konnectivity-agent-6fbc8c774c-rnvp2                  2m           6Mi

kube-system   konnectivity-agent-autoscaler-555f599d94-f2w5n       1m           4Mi

kube-system   kube-dns-85df8994db-lvf55                            2m           30Mi

kube-system   kube-dns-85df8994db-mvxv5                            2m           30Mi

kube-system   kube-dns-autoscaler-f4d55555-pctcj                   1m           11Mi

kube-system   kube-proxy-gke-valdas-1-default-pool-cf1cd6be-cvc4   1m           22Mi

kube-system   kube-proxy-gke-valdas-1-default-pool-cf1cd6be-q62h   1m           23Mi

kube-system   kube-proxy-gke-valdas-1-default-pool-cf1cd6be-xrf0   1m           26Mi

kube-system   l7-default-backend-69fb9fd9f9-fctch                  1m           1Mi

kube-system   metrics-server-v0.4.5-fb4c49dd6-knw6v                27m          24Mi

kube-system   pdcsi-node-mf6pt                                     2m           9Mi

kube-system   pdcsi-node-sxdrg                                     3m           9Mi

kube-system   pdcsi-node-wcnw7                                     3m           9Mi

现在，让我们创建一个包含资源请求和限制的单副本部署：

apiVersion: apps/v1

kind: Deployment

metadata:

 name: hpa-demo

 labels:

   app: nginx

spec:

 replicas: 1

 selector:

   matchLabels:

     app: nginx

 template:

   metadata:

     labels:

       app: nginx

   spec:

     containers:

     - name: nginx

       image: k8s.gcr.io/nginx-slim:0.8
      ports:

       - containerPort: 80

       resources:

         requests:

           cpu: 200m

         limits:

           cpu: 1000m

让我们将其保存到 demo.yaml 文件中并运行

> kubectl apply -f demo.yaml

我们可以通过以下方式检查它是否已部署：

> kubectl get deploy -n default

NAME       READY   UP-TO-DATE   AVAILABLE   AGE

hpa-demo   1/1     1            1           17m

最后，在配置 HPA 之前，我们需要公开一个可以调用以增加负载的服务，HPA 将对此做出反应。

让我们创建一个如下所示的 service.yaml 文件：

apiVersion: v1

kind: Service

metadata:

name: hpa-demo

labels:

  app: nginx

spec:

ports:

- port: 80

selector:

  app: nginx

并应用它

> kubectl apply -f service.yaml

我们可以通过以下方式验证该服务是否正常运行：

> kubectl get services
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE

hpa-demo     ClusterIP   10.92.62.191   <none>        80/TCP    7m35s

kubernetes   ClusterIP   10.92.48.1     <none>        443/TCP   48m

如您所见，hpa-demo 服务是存在的。

最后，我们需要配置 HPA。为此，我们可以创建一个名为 hpa.yaml 的文件，并填写以下内容：

apiVersion: autoscaling/v1

kind: HorizontalPodAutoscaler

metadata:

name: hpa-demo

spec:

scaleTargetRef:

  apiVersion: apps/v1

  kind: Deployment

  name: hpa-demo

minReplicas: 1

maxReplicas: 5

targetCPUUtilizationPercentage: 60

我们再次应用了它

> kubectl apply -f hpa.yaml

Now, let’s watch HPA in action using

>kubectl get hpa -w

NAME       REFERENCE             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE

hpa-demo   Deployment/hpa-demo   0%/60%    1         5         1          2m31s

如您所见，目前没有任何反应。但还记得我们之前是如何创建服务的吗？让我们使用 Busybox 开始生成一些负载：

> kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://hpa-demo; done"

我们应该立即看到HPA监控命令下的负载增加：

hpa-demo   Deployment/hpa-demo   16%/60%         1         5         1          8m47s

负载仍然不足以达到我们的目标，但为了演示，让我们将 targetCPUUtilizationPercentage 设置为 10，然后重新应用 hpa.yaml。

在监视命令下，我们应该看到目标已达到，并且添加了一个副本。

hpa-demo   Deployment/hpa-demo   16%/10%         1         5         1          15m

hpa-demo   Deployment/hpa-demo   16%/10%         1         5         2          15m

hpa-demo   Deployment/hpa-demo   9%/10%          1         5         2          16m

我们可以通过以下方式验证这一点：

> kubectl get deploy
NAME       READY   UP-TO-DATE   AVAILABLE   AGE

hpa-demo   2/2     2            2           40m

如您所见，我们有两个 pod，而部署只指定了一个 - 因此我们的 HPA 策略奏效了。

我们可以通过删除负载生成器 pod 来测试缩减规模：

> kubectl delete pod load-generator

过一段时间后，我们应该会看到：

NAME       REFERENCE             TARGETS   MINPODS   MAXPODS   REPLICAS   AGE

hpa-demo   Deployment/hpa-demo   0%/10%    1         5         1          26m

这意味着缩减规模的策略奏效了。

我们可以通过以下方式验证：

> kubectl get deploy

NAME       READY   UP-TO-DATE   AVAILABLE   AGE

hpa-demo   1/1     1            1           48m

基本就是这样。我们已经了解了如何根据 Pod 资源使用情况轻松地进行扩展和缩减。

使用HPA可实时了解成本。

Kubernetes 中不断提高的可扩展性对成本监控和控制提出了挑战，因为自动扩缩器会不断调整容量。

CAST AI 提供免费的成本监控产品，您可以按小时、按天、按周和按月查看您的云成本概览。 

只需一分钟或更短时间即可连接您的集群，立即实时查看当前成本，并访问过去数月的成本数据以进行全面报告。 

CAST AI 客户平均节省 63%他们的 Kubernetes 账单

连接您的集群，5分钟内即可查看您的成本，无需信用卡。