K8s HPA (Horizontal Pod Autoscaler) 结合自定义与外部指标的灵活伸缩 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

好的，各位亲爱的程序员朋友们，大家好！我是你们的老朋友，人称“Bug终结者”的码农侠。今天，我们要聊一个在 Kubernetes (K8s) 世界里既神秘又强大的存在——Horizontal Pod Autoscaler (HPA)。

HPA，顾名思义，就是水平 Pod 自动伸缩器。它能像一个勤劳的园丁，根据应用负载的大小，自动调整 Pod 的数量，让你的应用永远保持最佳状态。想象一下，你的应用就像一棵小树苗，HPA 就是那个默默浇水施肥的园丁，让它茁壮成长，迎风而立。

但是，仅仅依靠 CPU 利用率和内存使用率来伸缩，就像只靠阳光和雨水来养活植物，有时难免会顾此失彼。我们需要更精细化的肥料和更专业的照料，才能让植物开出最美的花朵。

因此，今天我们要深入探讨 HPA 结合自定义指标和外部指标的灵活伸缩，让你的应用在 K8s 的海洋里，乘风破浪，一帆风顺！

一、HPA 的基本原理：从新手村到进阶之路

首先，让我们回顾一下 HPA 的基本原理。HPA 的工作流程可以简单概括为以下几个步骤：

监控指标： HPA 会定期从 Metrics Server 或其他指标源获取 Pod 的指标数据，例如 CPU 利用率、内存使用率等。
计算期望副本数： HPA 根据设定的目标值（例如 CPU 利用率 50%）和当前指标数据，计算出期望的 Pod 副本数。
调整副本数： HPA 调用 Deployment 或 ReplicaSet 的 API，调整 Pod 的副本数，使其接近期望值。

这个过程就像一个自动驾驶系统，HPA 就是那个智能驾驶员，时刻监控路况（指标数据），并根据路况调整方向盘（副本数），确保车辆平稳行驶（应用稳定运行）。

步骤	描述	形象比喻
监控指标	HPA 定期从 Metrics Server 或其他指标源获取 Pod 的指标数据。	就像医生给病人做体检，测量血压、心率等各项指标。
计算副本数	HPA 根据设定的目标值和当前指标数据，计算出期望的 Pod 副本数。	就像厨师根据食谱和用餐人数，计算出需要准备的食材份量。
调整副本数	HPA 调用 Deployment 或 ReplicaSet 的 API，调整 Pod 的副本数，使其接近期望值。	就像空调根据室内温度，自动调节制冷或制热功率。 /

二、自定义指标：让 HPA 了解你的应用语言

仅仅依靠 CPU 和内存来伸缩，对于某些应用来说，可能并不够精确。例如，一个处理消息队列的应用，CPU 和内存可能并不高，但消息队列的积压量却很大，如果不及时扩容，可能会导致消息丢失或处理延迟。

这时，我们就需要引入自定义指标，让 HPA 能够理解你的应用的语言，根据更贴合业务场景的指标进行伸缩。

1. 如何暴露自定义指标？

暴露自定义指标的方式有很多种，常见的有以下几种：

Prometheus Exporter： 使用 Prometheus Exporter 暴露应用内部的指标，例如消息队列的积压量、请求处理时间等。Prometheus Exporter 就像一个翻译官，将应用内部的语言翻译成 Prometheus 能够理解的语言。
Metrics API： 通过 Kubernetes Metrics API 暴露自定义指标。这种方式需要编写一个 Metrics Server，负责收集和暴露指标数据。Metrics API 就像一个官方认证的翻译机构，提供更规范和标准的翻译服务。
Adapter： 使用 Adapter 将第三方监控系统的指标转换为 Kubernetes 可以使用的格式。Adapter 就像一个多语种翻译器，能够将各种语言翻译成 Kubernetes 可以理解的语言。

2. 如何配置 HPA 使用自定义指标？

一旦你的应用暴露了自定义指标，你就可以配置 HPA 使用这些指标进行伸缩了。在 HPA 的 YAML 文件中，你需要指定 metrics 字段，并配置 type 为 Object 或 Pods，分别对应于从单个对象或多个 Pods 收集的指标。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Object
    object:
      metric:
        name: my_custom_metric  # 自定义指标名称
      describedObject:
        apiVersion: apps/v1
        kind: Service
        name: my-app-service # 服务名称，指标从该服务暴露
      target:
        type: AverageValue
        averageValue: 100m

在这个例子中，HPA 会监控 my_custom_metric 指标，并尝试保持其平均值在 100m 左右。

三、外部指标：打破 K8s 的边界，拥抱更大的世界

有时候，我们需要根据 K8s 集群外部的指标进行伸缩。例如，根据数据库的连接数、消息队列的整体积压量、甚至是天气预报来调整 Pod 的数量。

这时，我们就需要引入外部指标，让 HPA 能够感知 K8s 集群之外的世界，根据更全局的指标进行伸缩。

1. 如何获取外部指标？

获取外部指标的方式通常需要借助第三方监控系统，例如 Prometheus、CloudWatch 等。这些监控系统可以收集各种各样的指标，并将它们暴露给 HPA 使用。

2. 如何配置 HPA 使用外部指标？

配置 HPA 使用外部指标与配置自定义指标类似，也是通过 metrics 字段进行配置，但需要将 type 设置为 External。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: external_metric_name # 外部指标名称
      target:
        type: AverageValue
        averageValue: 100

在这个例子中，HPA 会监控名为 external_metric_name 的外部指标，并尝试保持其平均值在 100 左右。

四、实战演练：让你的应用飞起来！

理论讲了一大堆，不如来点实际的。下面，我们通过一个简单的例子，演示如何使用 HPA 结合自定义指标和外部指标进行伸缩。

场景：

假设我们有一个 Web 应用，需要根据请求处理时间和数据库连接数进行伸缩。

自定义指标： 请求处理时间（单位：毫秒）。
外部指标： 数据库连接数。

步骤：

暴露请求处理时间： 使用 Prometheus Exporter 暴露 Web 应用的请求处理时间。
配置 Prometheus 收集数据库连接数： 配置 Prometheus 收集数据库连接数。
创建 HPA： 创建一个 HPA，同时使用请求处理时间和数据库连接数进行伸缩。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-web-app
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: request_processing_time_ms  # 请求处理时间
      target:
        type: AverageValue
        averageValue: 500m # 目标平均请求处理时间：500ms
  - type: External
    external:
      metric:
        name: database_connections # 数据库连接数
      target:
        type: AverageValue
        averageValue: 50 # 目标平均数据库连接数：50

在这个例子中，HPA 会同时监控请求处理时间和数据库连接数，并根据这两个指标综合判断是否需要伸缩。如果请求处理时间超过 500ms，或者数据库连接数超过 50，HPA 就会自动增加 Pod 的副本数。反之，如果请求处理时间和数据库连接数都低于目标值，HPA 就会自动减少 Pod 的副本数。

五、注意事项：HPA 的甜蜜陷阱与避坑指南

HPA 虽然强大，但也并非万能。在使用 HPA 的过程中，我们需要注意以下几个问题：

指标选择： 选择合适的指标至关重要。指标应该能够准确反映应用的负载情况，并且具有可预测性。如果指标选择不当，可能会导致 HPA 频繁伸缩，或者根本无法起到作用。
目标值设置： 目标值的设置也需要谨慎。目标值过高可能会导致资源浪费，目标值过低可能会导致应用性能下降。我们需要根据应用的实际情况，进行反复测试和调整，才能找到最佳的目标值。
伸缩策略： HPA 提供了多种伸缩策略，例如 Horizontal 和 Vertical。我们需要根据应用的特点，选择合适的伸缩策略。
冷却时间： HPA 默认有一个冷却时间，即在伸缩操作之后，需要等待一段时间才能进行下一次伸缩。这个冷却时间可以防止 HPA 频繁伸缩，但也会导致伸缩反应不够及时。我们可以根据实际情况，调整冷却时间。
监控和告警： 监控 HPA 的运行状态非常重要。我们需要监控 HPA 的伸缩操作、指标数据等，及时发现和解决问题。同时，我们还需要设置告警，当 HPA 出现异常时，能够及时通知相关人员。

问题	描述	解决方案
指标选择	选择的指标不能准确反映应用的负载情况，导致 HPA 无法正常工作。	深入了解应用的业务场景，选择能够准确反映应用负载的指标。例如，对于 Web 应用，可以选择请求处理时间、QPS 等指标；对于消息队列应用，可以选择消息积压量等指标。
目标值设置	目标值设置不合理，导致 HPA 频繁伸缩或无法达到预期效果。	通过反复测试和调整，找到最佳的目标值。可以先设置一个初始值，然后观察 HPA 的运行情况，逐步调整目标值，直到达到最佳效果。
伸缩策略	选择了不合适的伸缩策略，导致 HPA 无法满足应用的需求。	根据应用的特点，选择合适的伸缩策略。例如，对于 CPU 密集型应用，可以选择 `Horizontal` 伸缩策略；对于内存密集型应用，可以选择 `Vertical` 伸缩策略。
冷却时间	冷却时间设置不合理，导致 HPA 伸缩反应不够及时或过于频繁。	根据应用的特点，调整冷却时间。如果应用对伸缩反应要求较高，可以缩短冷却时间；如果应用对伸缩稳定性要求较高，可以延长冷却时间。
监控和告警	没有对 HPA 进行监控和告警，导致无法及时发现和解决问题。	建立完善的监控和告警体系，监控 HPA 的运行状态、指标数据等，及时发现和解决问题。可以使用 Prometheus、Grafana 等工具进行监控和告警。

六、总结：让 HPA 成为你的 K8s 神器！

HPA 结合自定义指标和外部指标的灵活伸缩，就像给你的应用装上了一个智能大脑，让它能够根据各种各样的指标，自动调整自身的规模，永远保持最佳状态。

掌握 HPA 的使用技巧，不仅可以提高应用的可用性和性能，还可以降低运维成本，让你的应用在 K8s 的海洋里，自由翱翔！

希望今天的分享对大家有所帮助。记住，HPA 只是一个工具，关键在于如何巧妙地使用它。希望大家能够灵活运用 HPA，让它成为你的 K8s 神器！

最后，祝大家 Bug 越来越少，代码越来越优雅！我们下次再见！

发表回复 取消回复

发表回复取消回复