K8s HPA 终极对比：内置指标 vs. 自定义指标，谁更胜一筹？

各位老铁，咱们今天来聊聊 Kubernetes（K8s）里一个非常重要的功能——Horizontal Pod Autoscaler（HPA，水平 Pod 自动伸缩）。这玩意儿能根据你设定的指标，自动调整应用 Pod 的数量，让你的应用既能扛住流量高峰，又能在空闲时省钱。听起来是不是很香？

但是，K8s 自带的 HPA 默认只支持 CPU 和内存这两个指标。这在很多场景下是不够用的。比如，你的应用可能对网络延迟特别敏感，或者需要根据消息队列的长度来调整 Pod 数量。这时候，就轮到自定义指标 HPA 登场了。

那么问题来了，内置指标 HPA 和自定义指标 HPA 到底有什么区别？各自的优缺点是什么？在什么场景下应该选择哪种 HPA？别急，今天我就带你好好捋一捋，再结合几个实际案例，让你彻底搞懂 K8s HPA 的各种骚操作。

一、HPA 的基本原理：先来个“开胃小菜”

在深入对比之前，咱们先简单回顾一下 HPA 的基本原理。HPA 的核心思想就是：根据指标的当前值和目标值，计算出期望的 Pod 数量，然后通过 Deployment、ReplicaSet 等控制器来调整实际的 Pod 数量。

这个过程有点像你开车时的定速巡航：你设定一个目标速度（比如 100km/h），然后汽车会自动调整油门，让车速保持在这个目标值附近。如果上坡了（负载增加了），汽车会自动加大油门；如果下坡了（负载减少了），汽车会自动减小油门。

HPA 也是类似的道理。你设定一个指标的目标值（比如 CPU 使用率 50%），HPA 会不断地监控这个指标的当前值，然后根据当前值和目标值的差距，来调整 Pod 的数量。如果当前值高于目标值，HPA 会增加 Pod 数量；如果当前值低于目标值，HPA 会减少 Pod 数量。

二、内置指标 HPA：简单易用，但“管”得有点窄

K8s 自带的 HPA，也就是我们常说的内置指标 HPA，使用起来非常简单。你只需要在 Deployment 或者 ReplicaSet 的 YAML 文件里，配置一下 autoscaling/v1 或 autoscaling/v2beta2 版本的 HorizontalPodAutoscaler 对象，指定要监控的资源（CPU 或内存）和目标值，就完事了。

比如，下面这个例子就是让 HPA 监控 Deployment 的 CPU 使用率，目标值是 50%：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
 name: my-hpa
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: my-deployment
 minReplicas: 1
 maxReplicas: 10
 metrics:
 - type: Resource
 resource:
 name: cpu
 target:
 type: Utilization
 averageUtilization: 50

内置指标 HPA 的优点很明显：

简单易用： 不需要额外的配置，直接在 YAML 文件里定义就行。
快速上手： 只要你的集群里部署了 Metrics Server，HPA 就能正常工作。

但是，它的缺点也很突出：

支持的指标有限： 只能监控 CPU 和内存，无法满足更复杂的业务需求。
灵活性不足： 无法根据自定义的业务指标进行伸缩。

三、自定义指标 HPA：功能强大，但“玩”起来有点复杂

自定义指标 HPA 允许你使用任何你想要的指标来触发 Pod 的伸缩。这些指标可以是 K8s 集群内部的指标，也可以是外部系统的指标。只要你能把这些指标暴露给 HPA，HPA 就能根据这些指标来调整 Pod 数量。

要使用自定义指标 HPA，你需要做以下几件事：

部署自定义指标 API 服务器： K8s 社区提供了两种自定义指标 API 服务器：
- Prometheus Adapter： 这是最常用的自定义指标 API 服务器，它可以将 Prometheus 采集的指标转换成 HPA 可以识别的格式。
- Custom Metrics API Server： 这是 K8s 官方提供的自定义指标 API 服务器框架，你可以基于这个框架开发自己的自定义指标 API 服务器。
配置 HPA： 在 HPA 的 YAML 文件里，指定要监控的自定义指标和目标值。

比如，下面这个例子就是让 HPA 监控 Prometheus 采集的 http_requests_total 指标，目标值是每秒 100 个请求：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
 name: my-hpa
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: my-deployment
 minReplicas: 1
 maxReplicas: 10
 metrics:
 - type: External
 external:
 metric:
 name: http_requests_total
 selector:
 matchLabels:
 app: my-app
 target:
 type: AverageValue
 averageValue: 100

自定义指标 HPA 的优点：

支持各种指标： 只要你能采集到的指标，都可以用来触发 HPA。
灵活性强： 可以根据业务需求，定制各种复杂的伸缩策略。

缺点：

配置复杂： 需要部署和配置自定义指标 API 服务器。
上手难度高： 需要对 Prometheus 等监控工具有一定的了解。

四、实战案例：看看自定义指标 HPA 怎么“秀”

说了这么多理论，咱们来几个实际案例，看看自定义指标 HPA 到底能干啥。

案例 1：根据消息队列长度进行伸缩

假设你有一个应用，它从消息队列（比如 Kafka、RabbitMQ）里消费消息。如果消息队列里积压的消息太多，说明应用的消费速度跟不上生产速度，这时候就需要增加 Pod 数量来提高消费速度。如果消息队列里没什么消息，说明应用的消费能力过剩，这时候就可以减少 Pod 数量来节省资源。

要实现这个需求，你可以使用 Prometheus 采集消息队列的长度指标，然后通过 Prometheus Adapter 将这个指标暴露给 HPA。HPA 就可以根据消息队列的长度来调整 Pod 数量了。

案例 2：根据网络延迟进行伸缩

假设你有一个对网络延迟非常敏感的应用，比如在线游戏或者实时交易系统。如果网络延迟过高，用户体验会非常差，这时候就需要增加 Pod 数量来降低延迟。如果网络延迟很低，说明应用的负载不高，这时候就可以减少 Pod 数量来节省资源。

要实现这个需求，你可以使用 Prometheus 采集应用的平均响应时间指标，然后通过 Prometheus Adapter 将这个指标暴露给 HPA。HPA 就可以根据平均响应时间来调整 Pod 数量了。

案例 3：根据业务指标进行伸缩

假设你有一个电商网站，你希望在促销活动期间自动增加 Pod 数量来应对流量高峰。你可以使用 Prometheus 采集网站的订单量、用户活跃数等业务指标，然后通过 Prometheus Adapter 将这些指标暴露给 HPA。HPA 就可以根据这些业务指标来调整 Pod 数量了。

五、总结：选哪个？看你的“菜”

好了，说了这么多，相信你对内置指标 HPA 和自定义指标 HPA 都有了一定的了解。那么，在实际应用中，到底应该选择哪种 HPA 呢？

我的建议是：看你的“菜”下饭。

如果你的应用只需要根据 CPU 和内存进行伸缩，而且你对 HPA 的配置要求不高，那么内置指标 HPA 就足够了。
如果你的应用需要根据更复杂的指标进行伸缩，或者你需要定制各种复杂的伸缩策略，那么自定义指标 HPA 是更好的选择。

总之，没有最好的 HPA，只有最适合你的 HPA。希望这篇文章能帮助你更好地理解 K8s HPA，让你的应用在云原生时代“如鱼得水”。

如果你还有其他问题，欢迎在评论区留言，我会尽力解答。

最后，再强调一下： 玩转 K8s HPA，不仅要懂原理，更要多实践。只有在实践中，你才能真正掌握 HPA 的各种技巧，让它成为你手中的“利器”。

彩蛋： 别忘了，HPA 只是 K8s 自动伸缩的冰山一角。除了 HPA，还有 VPA（Vertical Pod Autoscaler，垂直 Pod 自动伸缩）和 Cluster Autoscaler（集群自动伸缩）等着你去探索。这些工具组合起来，才能真正实现 K8s 集群的弹性伸缩。

祝大家玩得开心，用得顺手！

K8s HPA 终极对比：内置指标 vs. 自定义指标，谁更胜一筹？