一、K8s 扩缩容的背景与意义

在现代的软件开发和运维领域，应用程序的负载情况就像大海的波浪一样，时高时低。有时候，大量用户同时访问应用，导致服务器压力剧增；而在某些时间段，访问量又会大幅下降。如果我们为了应对高负载而始终保持大量的服务器资源，那在低负载时就会造成资源的浪费，增加成本；反之，如果资源配置不足，在高负载时应用就会出现响应缓慢甚至崩溃的情况。

Kubernetes（简称 K8s）的 Horizontal Pod Autoscaler（HPA）就像是一个智能的资源管理员，它可以根据应用的负载情况自动调整 Pod 的数量，从而实现资源的高效利用和应用的稳定运行。例如，一个电商网站在促销活动期间，访问量会急剧增加，HPA 可以自动增加 Pod 的数量来处理更多的请求；而在活动结束后，又会自动减少 Pod 的数量，避免资源浪费。

二、基于 CPU / 内存的扩缩容

2.1 原理

基于 CPU 和内存的扩缩容是 HPA 最常见的应用场景。K8s 会定期收集 Pod 的 CPU 和内存使用情况，并与预先设定的目标值进行比较。如果实际使用量超过了目标值，HPA 就会增加 Pod 的数量；反之，如果实际使用量低于目标值，HPA 就会减少 Pod 的数量。

2.2 示例（使用 YAML 配置，Kubernetes 技术栈）

以下是一个基于 CPU 使用率进行扩缩容的示例：

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

注释：

  • apiVersion：指定 API 版本，这里使用 autoscaling/v2beta2。
  • kind：指定资源类型为 HorizontalPodAutoscaler。
  • metadata.name：HPA 的名称。
  • scaleTargetRef：指定要进行扩缩容的目标资源，这里是一个 Deployment。
  • minReplicas：最小的 Pod 副本数。
  • maxReplicas：最大的 Pod 副本数。
  • metrics：指定扩缩容的指标，这里使用 CPU 利用率，目标值为 50%。

2.3 优缺点

优点：

  • 简单直观：CPU 和内存是最基本的资源指标，易于理解和配置。
  • 广泛适用：几乎所有的应用都可以使用 CPU 和内存作为扩缩容的依据。

缺点：

  • 不够精准：CPU 和内存使用率并不能完全反映应用的实际负载情况，例如某些应用可能对磁盘 I/O 或网络带宽更为敏感。
  • 滞后性：K8s 收集指标和进行扩缩容操作需要一定的时间，可能会导致在高负载时响应不够及时。

2.4 注意事项

  • 确保目标资源（如 Deployment）已经正确部署，并且 Pod 能够正常运行。
  • 合理设置 minReplicas 和 maxReplicas，避免过度扩缩容。
  • 定期监控 HPA 的运行情况，根据实际情况调整目标指标。

三、基于自定义指标的扩缩容

3.1 原理

除了 CPU 和内存，我们还可以使用自定义指标进行扩缩容。例如，我们可以根据应用的请求响应时间、每秒请求数等指标来动态调整 Pod 的数量。要实现基于自定义指标的扩缩容，需要使用 Prometheus 等监控系统来收集和存储指标数据，并使用 Prometheus Adapter 将指标暴露给 K8s。

3.2 示例（使用 YAML 配置，Kubernetes + Prometheus 技术栈）

以下是一个基于自定义指标（每秒请求数）进行扩缩容的示例：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-custom-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: 100

注释：

  • apiVersion、kind、metadata.name、scaleTargetRef、minReplicas 和 maxReplicas 的含义与前面的示例相同。
  • metrics：指定扩缩容的指标，这里使用自定义指标 http_requests_per_second，目标值为每秒 100 个请求。

3.3 优缺点

优点：

  • 精准度高：可以根据应用的实际业务需求选择合适的指标，更准确地反映应用的负载情况。
  • 灵活性强：可以自定义各种指标，满足不同应用的特殊需求。

缺点：

  • 配置复杂：需要额外的监控系统和 Adapter 来支持，增加了系统的复杂度。
  • 维护成本高：需要定期维护监控系统和 Adapter，确保指标数据的准确性和可用性。

3.4 注意事项

  • 确保 Prometheus 等监控系统已经正确部署，并且能够正常收集和存储指标数据。
  • 安装和配置 Prometheus Adapter，将自定义指标暴露给 K8s。
  • 对自定义指标进行充分的测试和验证，确保其准确性和可靠性。

四、应用场景

4.1 电商网站

在促销活动期间，电商网站的访问量会急剧增加，基于 CPU / 内存和自定义指标（如每秒订单数）的扩缩容可以确保网站能够处理大量的请求，避免出现卡顿和崩溃的情况。活动结束后，自动减少 Pod 的数量，降低成本。

4.2 在线游戏

在线游戏的玩家数量会随着时间和活动的不同而波动。通过 HPA 可以根据玩家在线人数、游戏服务器的响应时间等指标动态调整 Pod 的数量，保证游戏的流畅性和稳定性。

4.3 大数据处理

大数据处理任务的负载通常是不均衡的，有时需要处理大量的数据，有时则处于空闲状态。基于自定义指标（如数据处理速度）的扩缩容可以根据任务的实际负载情况自动调整资源，提高处理效率。

五、技术优缺点总结

5.1 优点

  • 提高资源利用率：根据实际负载情况动态调整 Pod 的数量，避免资源的浪费和不足。
  • 增强应用的稳定性：在高负载时自动增加 Pod 的数量，确保应用能够正常运行；在低负载时减少 Pod 的数量，降低成本。
  • 灵活性高：支持基于 CPU / 内存和自定义指标的扩缩容，满足不同应用的需求。

5.2 缺点

  • 配置复杂：特别是基于自定义指标的扩缩容，需要额外的监控系统和 Adapter 来支持。
  • 存在一定的滞后性：K8s 收集指标和进行扩缩容操作需要一定的时间，可能无法及时应对突发的高负载情况。

六、注意事项总结

  • 确保目标资源和监控系统的正常运行，避免因资源故障或指标数据不准确导致扩缩容失败。
  • 合理设置扩缩容的参数，如 minReplicas、maxReplicas 和目标指标，避免过度扩缩容。
  • 定期监控 HPA 的运行情况，根据实际情况进行调整和优化。

七、文章总结

K8s 的 Horizontal Pod Autoscaler 是一个强大的工具，它可以根据应用的负载情况自动调整 Pod 的数量，实现资源的高效利用和应用的稳定运行。基于 CPU / 内存的扩缩容简单直观，适用于大多数应用；而基于自定义指标的扩缩容则更加精准和灵活，能够满足不同应用的特殊需求。在实际应用中，我们需要根据应用的特点和需求选择合适的扩缩容方式，并注意相关的配置和维护事项，以确保 HPA 能够发挥最大的作用。