K8s 中的自定义度量指标与 HPA 策略 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

好的，各位观众老爷们，大家好！我是你们的老朋友，人称“代码小王子”的程序猿阿甘。今天呢，咱们不聊诗和远方，就来聊聊 Kubernetes (K8s) 里那些让你的应用像变形金刚一样，自动伸缩的“黑科技”：自定义度量指标与 HPA 策略。

准备好了吗？系好安全带，咱们要起飞啦！🚀

开场白：应用界的“变形金刚”梦

想象一下，你的应用就像一个兢兢业业的打工人，每天辛勤工作。但有时候，突然来了个“618”或者“双十一”，流量瞬间爆炸！💥 这时候，如果你的应用还是原来的配置，那肯定要崩溃的！就像让一个瘦弱的小伙子去搬运一座山，那是不可能完成的任务。

所以，我们需要一种机制，能让应用根据实际的负载情况，像变形金刚一样，自动调整自身的大小，从而应对各种突发情况。而 Kubernetes 的 HPA (Horizontal Pod Autoscaler) 策略，配合自定义度量指标，就能实现这个“变形金刚”梦！

第一幕：什么是 HPA？（Horizontal Pod Autoscaler）

HPA，顾名思义，就是水平 Pod 自动伸缩器。它的作用是根据应用的实际负载情况，自动调整 Pod 的数量，从而保证应用的稳定性和性能。

你可以把 HPA 想象成一个聪明的管家，它时刻监控着你的应用，当发现应用的负载过高时，就会自动增加 Pod 的数量；当负载降低时，又会自动减少 Pod 的数量。这样，你的应用就能始终保持最佳状态，既不会因为负载过高而崩溃，也不会因为资源浪费而心疼你的钱包。💰

HPA 的工作原理：

HPA 的工作原理其实很简单，它主要依赖以下几个关键组件：

Metrics Server (或 Prometheus)： 用于收集应用的度量指标，例如 CPU 利用率、内存使用率、请求数量等等。
HPA Controller： 负责监控 Metrics Server 提供的度量指标，并根据预设的策略，计算出需要调整的 Pod 数量。
Replication Controller (或 Deployment)： 负责实际的 Pod 数量调整。

用大白话来说，就是 Metrics Server 负责“体检”，HPA Controller 负责“诊断”，Replication Controller 负责“开药方”。

举个栗子：

假设你有一个 Web 应用，你希望当 CPU 利用率超过 70% 时，自动增加 Pod 的数量；当 CPU 利用率低于 30% 时，自动减少 Pod 的数量。那么，你可以配置一个 HPA，指定 CPU 利用率为目标指标，并设置相应的阈值。

第二幕：自定义度量指标：让 HPA 更懂你的应用

虽然 HPA 已经很强大了，但它默认只支持 CPU 和内存这两种度量指标。在很多情况下，这远远不够！例如，你的应用可能更关心每秒处理的请求数量，或者数据库的连接数等等。这时候，就需要用到自定义度量指标了。

自定义度量指标，顾名思义，就是你可以根据自己的需求，定义一些新的度量指标，并让 HPA 根据这些指标进行自动伸缩。这就像给 HPA 安装了一个“外挂”，让它更懂你的应用，从而做出更精准的决策。😎

如何定义自定义度量指标？

定义自定义度量指标，通常需要以下几个步骤：

暴露度量指标： 首先，你需要让你的应用能够暴露相关的度量指标。这可以通过各种方式实现，例如：
- Prometheus Exporter： 这是最常用的方式，你可以使用 Prometheus Exporter 将你的应用指标暴露给 Prometheus。
- Custom Metrics API： Kubernetes 提供了一个 Custom Metrics API，你可以使用它来暴露自定义的度量指标。
- External Metrics API： 如果你的度量指标来自外部系统，例如云平台的监控服务，你可以使用 External Metrics API 来暴露这些指标。
配置 Metrics Server： 接下来，你需要配置 Metrics Server，让它能够从你的应用中收集这些自定义的度量指标。
配置 HPA： 最后，你需要配置 HPA，指定使用哪些自定义的度量指标，并设置相应的阈值。

各种API的区别是什么？

API 类型	描述	数据来源	适用场景
Resource Metrics API	提供节点和 Pod 的资源使用情况，如 CPU 和内存。	kubelet 内置的 cAdvisor	基础的资源监控和基于 CPU/内存的 HPA。
Custom Metrics API	允许暴露集群内部的自定义指标，例如应用程序的请求延迟、队列长度等。	由用户部署的 Metrics Adapter 提供数据，通常是从 Prometheus 或其他监控系统收集。	应用程序级别的监控和 HPA，对应用程序的行为有更细粒度的控制。
External Metrics API	允许暴露集群外部的指标，例如云服务提供的监控数据，如数据库连接数、消息队列长度等。	由用户部署的 Metrics Adapter 提供数据，通常是从云服务商或其他外部监控系统收集。	基于外部系统状态进行伸缩，例如根据数据库的负载或消息队列的积压程度进行 HPA。
Pod Metrics API	允许直接从 Pod 中获取指标数据，而不是通过 Metrics Server 聚合。这对于某些特殊的指标收集场景可能很有用。	直接从 Pod 的 metrics endpoint 获取数据，通常需要应用程序提供相应的 endpoint。	特殊的指标收集场景，例如需要从 Pod 中获取一些独特的指标，但这种方式可能会增加 kubelet 的负担。

举个栗子：

假设你有一个电商应用，你希望根据每秒处理的订单数量来自动伸缩。你可以使用 Prometheus Exporter 将订单数量暴露给 Prometheus，然后配置 Metrics Server 从 Prometheus 中收集这些指标。最后，你可以配置 HPA，指定使用订单数量作为度量指标，并设置相应的阈值。

第三幕：HPA 策略：让伸缩更智能

有了自定义度量指标，HPA 就能更懂你的应用了。但是，如何让 HPA 做出更智能的伸缩决策呢？这就需要用到 HPA 策略了。

HPA 策略，就是你告诉 HPA 如何根据度量指标来调整 Pod 的数量。例如，你可以指定 HPA 增加 Pod 的速度，或者限制 Pod 的最大数量等等。

HPA 策略的配置：

HPA 策略的配置主要包括以下几个方面：

目标指标 (Target Metric)： 指定 HPA 监控的度量指标，例如 CPU 利用率、内存使用率、自定义指标等等。
目标值 (Target Value)： 指定 HPA 希望达到的目标值，例如 CPU 利用率 70%、每秒处理 1000 个请求等等。
最小副本数 (Min Replicas)： 指定 Pod 的最小数量，防止 HPA 将 Pod 数量缩减到 0。
最大副本数 (Max Replicas)： 指定 Pod 的最大数量，防止 HPA 无限制地增加 Pod 的数量。
伸缩策略 (Scaling Policy)： 指定 HPA 增加或减少 Pod 的速度。Kubernetes 1.18 引入了 Behavior，可以配置scaleUp 和 scaleDown。
- HorizontalPodAutoscalerBehavior 中包含 scaleUp 和 scaleDown 两个配置项。
- scaleUp/scaleDown 允许您配置 HPA 伸缩时的行为。你可以指定伸缩的速率，以及在不同情况下使用不同的速率。

伸缩算法

HPA 使用以下公式来计算所需的副本数：

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

其中：

desiredReplicas：期望的副本数
currentReplicas：当前副本数
currentMetricValue：当前指标值
desiredMetricValue：期望的指标值

举个栗子：

假设你希望当 CPU 利用率超过 70% 时，自动增加 Pod 的数量；当 CPU 利用率低于 30% 时，自动减少 Pod 的数量。你可以配置一个 HPA，指定 CPU 利用率为目标指标，目标值为 70%，最小副本数为 2，最大副本数为 10。

第四幕：实战演练：用 YAML 征服 HPA

说了这么多理论，咱们来点实际的！下面，咱们就用 YAML 来配置一个 HPA，让大家感受一下 HPA 的魅力。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: my_custom_metric
      target:
        type: AverageValue
        averageValue: 100m #m表示千分之一
  behavior:
    scaleUp:
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60
    scaleDown:
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

代码解释：

apiVersion: autoscaling/v2: 指定 HPA 的 API 版本。
kind: HorizontalPodAutoscaler: 指定资源类型为 HPA。
metadata.name: my-hpa: 指定 HPA 的名称。
spec.scaleTargetRef: 指定 HPA 作用的目标对象，这里是一个 Deployment，名为 my-deployment。
spec.minReplicas: 2: 指定 Pod 的最小数量为 2。
spec.maxReplicas: 10: 指定 Pod 的最大数量为 10。
spec.metrics: 指定 HPA 监控的度量指标，这里包括 CPU 利用率和自定义指标。
- type: Resource: 指定度量指标类型为资源指标，例如 CPU 和内存。
- resource.name: cpu: 指定资源名称为 CPU。
- target.type: Utilization: 指定目标类型为利用率。
- target.averageUtilization: 70: 指定目标 CPU 利用率为 70%。
- type: Pods: 使用Pod级别的指标，而非对象级别的指标
- pods.metric.name: my_custom_metric: 自定义指标的名称
- pods.target.type: AverageValue: 目标类型为平均值
- pods.target.averageValue: 100m: 目标平均值为100m (m表示千分之一)
spec.behavior: 指定伸缩行为
- scaleUp: 扩容行为
- scaleDown: 缩容行为
- policies: 策略列表。
  - type: Percent: 按百分比调整
  - value: 10: 每次调整10%
  - periodSeconds: 60: 60秒内生效

操作步骤：

将上面的 YAML 代码保存为一个文件，例如 hpa.yaml。
使用 kubectl apply -f hpa.yaml 命令创建 HPA。
使用 kubectl get hpa 命令查看 HPA 的状态。

第五幕：监控与调试：让 HPA 尽在掌握

配置完 HPA 后，我们需要对其进行监控和调试，确保它能够正常工作。

监控 HPA：

可以使用以下命令来监控 HPA 的状态：

kubectl get hpa my-hpa -w

这个命令会实时显示 HPA 的状态，包括当前的 Pod 数量、目标指标值、以及伸缩事件等等。

调试 HPA：

如果 HPA 没有按照预期工作，可以使用以下方法进行调试：

查看 HPA 的事件： 使用 kubectl describe hpa my-hpa 命令查看 HPA 的事件，可以帮助你了解 HPA 为什么没有进行伸缩。
检查 Metrics Server： 确保 Metrics Server 能够正常收集应用的度量指标。
检查应用的日志： 查看应用的日志，看看是否有任何错误或异常。

尾声：HPA 的最佳实践

最后，给大家分享一些 HPA 的最佳实践：

选择合适的度量指标： 选择与应用负载密切相关的度量指标，例如请求数量、响应时间等等。
设置合理的阈值： 设置合理的阈值，避免 HPA 频繁地进行伸缩。
使用滚动更新： 在进行 HPA 配置更新时，使用滚动更新，避免影响应用的可用性。
监控 HPA 的状态： 定期监控 HPA 的状态，确保它能够正常工作。

总结：

自定义度量指标与 HPA 策略，是 Kubernetes 中非常强大的工具，它们可以帮助你构建一个自适应的应用，从而应对各种突发情况。只要你掌握了它们，就能让你的应用像变形金刚一样，所向披靡！

希望今天的分享对大家有所帮助！如果大家有什么问题，欢迎在评论区留言。

我是阿甘，咱们下期再见！👋

发表回复 取消回复

发表回复取消回复