HOOOS

Kubernetes HPA 进阶：玩转弹性伸缩，让你的应用稳如泰山

0 47 弹性老司机 KubernetesHPA自动扩缩容
Apple

前言

“喂，哥们，你听说过 HPA 吗？”

“当然，Horizontal Pod Autoscaler 嘛，Kubernetes 里的自动扩缩容神器，谁不知道？”

“那你觉得 HPA 用起来怎么样？是不是感觉有时候扩缩容不够及时，或者波动太大？”

“嗯，确实有这种感觉。有时候流量高峰来了，HPA 反应慢半拍，应用都快扛不住了才开始扩容。有时候流量明明下去了，HPA 却还维持着大量的 Pod，浪费资源。”

“哈哈，看来你也是个有故事的‘老司机’。今天咱们就来聊聊 HPA 的高级玩法，教你如何驯服这匹‘野马’，让它既能及时响应流量变化，又能避免不必要的资源浪费。”

HPA 基础回顾

在深入探讨高级配置之前，咱们先简单回顾一下 HPA 的基础知识，确保咱们在同一个频道上。

HPA 是什么？

Horizontal Pod Autoscaler（HPA）是 Kubernetes 的一个内置控制器，它可以根据观察到的 CPU 利用率、内存使用率或其他自定义指标，自动调整 Deployment、ReplicaSet 或 StatefulSet 中的 Pod 数量。

HPA 的工作原理

  1. 监控指标： HPA 定期从 Metrics Server 或自定义指标适配器（如 Prometheus Adapter）获取 Pod 的指标数据。
  2. 计算副本数： HPA 根据当前指标值、目标值以及用户配置的伸缩策略，计算出期望的 Pod 副本数。
  3. 执行伸缩： HPA 将计算出的副本数应用到 Deployment、ReplicaSet 或 StatefulSet，从而实现 Pod 的扩缩容。

HPA 的基本配置

一个典型的 HPA 配置如下所示：

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: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

这个配置表示：

  • scaleTargetRef: 指定要进行自动扩缩容的 Deployment（也可以是 ReplicaSet 或 StatefulSet）。
  • minReplicas/maxReplicas: 指定 Pod 副本数的最小值和最大值。
  • metrics: 指定用于计算副本数的指标。这里使用的是 CPU 利用率，目标值是 50%。

HPA 高级配置：驯服“野马”的缰绳

掌握了 HPA 的基础知识后，咱们就可以开始学习高级配置了。这些配置就像驯服“野马”的缰绳，可以帮助我们更好地控制 HPA 的行为，让它更符合我们的实际需求。

1. 扩缩容行为（Behavior）

Kubernetes v1.18 引入了 behavior 字段，允许我们对 HPA 的扩缩容行为进行更细粒度的控制。behavior 字段包含两个子字段：scaleUp 和 scaleDown，分别用于配置扩容和缩容的行为。

scaleUp

scaleUp 字段包含以下几个子字段：

  • stabilizationWindowSeconds： 稳定窗口期，默认值为 0。在这个时间窗口内，HPA 会考虑历史指标数据，以防止频繁的扩缩容。
  • policies： 扩容策略，可以配置多个策略，HPA 会选择能够扩容最多 Pod 的策略。
    • type： 策略类型，可以是 Pods 或 Percent。
      • Pods：表示每次扩容的 Pod 数量。
      • Percent：表示每次扩容的 Pod 数量占当前副本数的百分比。
    • value： 策略值，根据 type 的不同，表示 Pod 数量或百分比。
    • periodSeconds： 策略生效周期，表示多长时间内执行一次扩容操作。
  • selectPolicy： 策略选择方式，可以是 Max 或 Min 或Disabled。
    * Max：默认值，选择能够扩容最多 Pod 的策略。
    * Min：选择扩容最少的pod策略。
    * Disabled: 关闭扩容。

scaleDown

scaleDown 字段的配置与 scaleUp 类似，只是用于控制缩容行为。

示例

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: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30
      policies:
      - type: Pods
        value: 4
        periodSeconds: 60
      - type: Percent
        value: 10
        periodSeconds: 60
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Pods
        value: 2
        periodSeconds: 60
      - type: Percent
        value: 5
        periodSeconds: 60
      selectPolicy: Min

这个配置表示：

  • 扩容：
    • 稳定窗口期为 30 秒。
    • 有两种扩容策略：
      • 每 60 秒最多扩容 4 个 Pod。
      • 每 60 秒最多扩容当前副本数的 10%。
    • HPA 会选择能够扩容最多 Pod 的策略。
  • 缩容：
    • 稳定窗口期为 300 秒。
    • 有两种缩容策略：
      • 每 60 秒最多缩容 2 个 Pod。
      • 每 60 秒最多缩容当前副本数的 5%。
    • HPA 会选择能够缩容最少 Pod 的策略（selectPolicy: Min）。

通过合理配置 behavior 字段，我们可以让 HPA 的扩缩容行为更加平稳，避免频繁的抖动。

2. 自定义指标（Custom Metrics）

除了 CPU 和内存等资源指标外，HPA 还可以根据自定义指标进行扩缩容。这为我们提供了更大的灵活性，可以根据应用的特定需求来定制扩缩容策略。

自定义指标的类型

  • Pod 指标： 与 Pod 相关的指标，例如 Pod 处理的请求数、消息队列中的消息数等。
  • 对象指标： 与 Kubernetes 对象（如 Ingress、Service 等）相关的指标，例如 Ingress 的 QPS、Service 的连接数等。
  • 外部指标： 与 Kubernetes 集群外部的资源相关的指标，例如云服务的负载、数据库的连接数等。

使用自定义指标

要使用自定义指标，我们需要安装相应的指标适配器，例如 Prometheus Adapter。然后，在 HPA 的配置中指定自定义指标的名称和目标值即可。

示例

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: Pods
    pods:
      metric:
        name: requests_per_second
      target:
        type: AverageValue
        averageValue: 100

这个配置表示：

  • 使用名为 requests_per_second 的 Pod 指标进行扩缩容。
  • 目标值是每个 Pod 平均每秒处理 100 个请求。

3. 多指标组合

在某些情况下，我们可能需要根据多个指标来综合判断是否需要扩缩容。HPA 支持同时使用多个指标，只要其中一个指标达到目标值，就会触发扩缩容操作。

示例

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: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: requests_per_second
      target:
        type: AverageValue
        averageValue: 100

这个配置表示：

  • 同时使用 CPU 利用率和 requests_per_second 两个指标进行扩缩容。
  • 只要 CPU 利用率超过 50% 或每个 Pod 平均每秒处理的请求数超过 100，就会触发扩缩容操作。

4. 预测性扩缩容（Predictive Scaling）

预测性扩缩容是一种更高级的扩缩容方式，它利用机器学习算法来预测未来的流量趋势，并在流量高峰到来之前提前进行扩容。这样可以避免因扩容不及时而导致的应用性能下降。

实现方式

目前，Kubernetes 社区中有一些开源项目可以实现预测性扩缩容，例如：

  • KEDA (Kubernetes Event-driven Autoscaling): 基于事件驱动的自动扩缩容组件，支持多种事件源，包括 Prometheus、Kafka、RabbitMQ 等。
  • Prometheus HPA Controller: 基于 Prometheus 指标的 HPA 控制器，支持预测性扩缩容。

注意事项

  • 预测性扩缩容需要收集历史指标数据，并进行模型训练。
  • 预测的准确性受多种因素影响，例如历史数据的质量、模型的选择、参数的调优等。
  • 预测性扩缩容可能会导致资源浪费，因为预测的流量高峰可能并不会真正到来。

总结

“怎么样，哥们，现在是不是感觉对 HPA 的掌控力又提升了一个档次？”

“嗯，确实学到了不少东西。原来 HPA 还有这么多高级玩法，看来以前真是‘小瞧’它了。”

“哈哈，别客气。HPA 就像一把‘瑞士军刀’，功能强大，但需要我们花时间去学习和掌握。只有充分了解它的特性，才能更好地利用它来为我们的应用保驾护航。”

“说得对！以后我得多研究研究 HPA 的文档，争取把它用得‘炉火纯青’。”

“加油！相信你一定能成为 HPA 的‘驯服高手’！”

希望通过这篇文章，你能对 Kubernetes HPA 的高级配置有更深入的了解。记住，实践出真知，多动手尝试，才能真正掌握这些技巧。祝你在 Kubernetes 的世界里玩得开心！

点评评价

captcha
健康