Kubernetes的水平自动扩展(HPA v2)

首先

在Kubernetes 1.23中,终于将正式发布Horizontail Pod Autoscaler(HPA) v2版。为了庆祝这一事件?我打算以以前写的主要关于HPA v1的文章为基础,与v1(v2beta1)版本的区别一起介绍HPA v2版的概述。
(仍然偶尔会看到一些过时的信息感到有些尴尬?)

水平Pod自动缩放器是什么。

水平Pod自动缩放器根据设置的内容和基于度量标准计算的值,将Pod的数量调整为维护有Deployment、ReplicaSet、StatefulSet等Scale子资源的资源1。可使用各种度量标准,如CPU、内存、自定义度量标准等来进行该缩放的判定。水平Pod自动缩放器作为Kubernetes API对象和控制器实现。该控制器会定期比较用户设置的阈值和度量标准的值,并调整Pod的数量。

只要通过HPA调整,这意味着只能调整Pod的数量。请注意,节点本身的扩展以及Pod的资源大小的增减需要使用其他机制(如cluster-autoscaler、VerticalPodAutoscaler等)。

水平Pod自动缩放器的操作方式

水平Pod自动缩放器的控制器(HorizontalPodAutoscalerController)作为ControllerManager中的一个控制器实现,并且默认情况下,控制循环(收集指标值并调整副本数的处理循环)以15秒间隔2进行周期性处理。可以通过ControllerManager的–horizontal-pod-autoscaler-sync-period标志来更改此间隔。

在这个循环中,根据指定给HPA对象的配置,汇总指标数据,并基于这些值计算副本数。
更详细的算法描述请参考https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details。

在一些度量类型中,使用Pod的平均值进行计算,具体的计算公式如下所示。

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

API版本

请注意,HorizontalPodAutoscaler目前已经发布了以下版本,并且每个版本的spec和行为都有所不同。
HPA是autoscaling API组的对象,并且以下API版本已经发布。

    • v1

 

    • v2beta1

 

    • v2beta2

 

    v2 (v1.23.0から追加予定)

如果没有特殊情况,建议您使用最新版本的v2或v2beta2。

水平Pod自动伸缩功能所支持的指标类型

目前可用的类型如下所示。3

PodResource: 各 Pod のリソースのメトリクス(v2beta2ではResource)

例: PodのCPU、メモリ使用率など
このケースの場合pod.spec.containers.resource.requestが指定されていないと機能しないため設定が必須
値は目標値と比較する前に平均化されます

Object: Kubernetes Objectに関連したメトリクス

例: Ingressの秒間リクエスト数など

Pods: 現在のスケールターゲットの各Pod単位で生成されるメトリクス

例: 秒間処理数など
値は目標値と比較する前に平均化されます

リソース使用量以外のPod単位で出力されるメトリクスなどを利用する場合に利用するようです。

External: どのKubernetesオブジェクトにも関連付けられていないグローバルメトリクス

例: メッセージングサービスのキューの長さや、クラスタ外のロードバランサーからのQPSなど
クラスタ外のコンポーネントからの情報に基づいてオートスケーリングを行うことができます

ContainerResource: 各コンテナのリソースのメトリクス4

例: コンテナのCPU、メモリ使用率など
このケースの場合pod.spec.containers.resource.requestが指定されていないと機能しないため設定が必須
値は目標値と比較する前に平均化されます

Pod単位だとサイドカーなどのコンテナのリソースがノイズになってしまうことがあるため、コンテナ単体のリソースを対象にできるように最近追加されました

在指定这些指标时,至少需要指定一个。如果指定了多个,将在所有指标类型上进行计算,并选择最大值作为采用的值。
即使在某些情况下无法获取到某些指标,也会基于最大大小进行扩容操作,但不会进行缩小操作。

水平Pod自动缩放控制器收集指标的方法。

有以下三种选择可供您选择。

    • metrics-server5 から収集する方法

 

    • Custom Metrics API: https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md

External Metrics API: https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md

这些API需要使用Kubernetes的apiserver中的聚合层来将不在apiserver中提供的API嵌入到apiserver中,以便能够从apiserver中收集指标。

具体而言,您可以通过设置apiserver的一些标志来添加名为APIService的资源,并将请求流转至提供API的Service。
例如,对于metrics-server,您可以添加类似于https://github.com/kubernetes-sigs/metrics-server/blob/master/manifests/base/apiservice.yaml的资源。

如果使用自定义度量标准,可以使用Prometheus适配器(Prometheus Adapter)将Prometheus的度量标准用作自定义度量标准。该适配器会添加一些资源,例如https://github.com/kubernetes-sigs/prometheus-adapter/blob/v0.9.1/deploy/manifests/custom-metrics-apiservice.yaml。有关Prometheus适配器的详细使用方法,请参考@Ladicle的文档,链接如下:https://qiita.com/Ladicle/items/5ff251b89df2f1ebb821

使用方式

不同的指标类型有不同的使用方法。在这里,我将介绍最常见的PodResource指标的使用方法。
不过,官方文档中有更详细的说明,我建议您查看那里的详细说明。
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/

从中摘录并介绍简单的使用方法。
官方文件的示例中,使用简单的PHP创建了一个Web服务,该服务通过一个部署(Deployment)和一个服务(Service)进行创建。我们将创建一个HPA,以使所有Pod的CPU利用率保持在大约50%左右。另外,为了防止过度扩展,我们希望给Pod设置一个最大值为10的限制。

如果只需对HPA进行设置,且已在环境中部署了metrics-server,则只需创建以下命令或HorizontalPodAutoscaler对象即可使用(假设已部署了要进行扩展的服务)。

$ kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: PodResource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

以上是结束了。如果想要体验一下简单负载时Pod数量的上下变化,请参考官方文档,尝试施加负载是个不错的想法。

设定这种配置本身非常简单,但是找到最佳配置值并不容易。对于这一点,筆者也不知道有什么最佳实践,只能通过持续进行负载测试和实际度量等来进行调整。

调整规模行为

Kubernetes 1.18版本新增了HPA的behavior字段。以前,只能在整个Kubernetes中设置调整规模升级和降级的频率和间隔等,现在可以在HPA的spec中进行描述,并且可以在HPA单位进行调整。
这使得可以对应用程序单位进行调整扩展速度。如果不进行此设置,则会使用ControllerManager中设置的群集默认值。

如果您想了解设定方法或详细信息,请参考官方文件或KEP。

公式文档:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#支持可配置的缩放行为
KEP:https://github.com/kubernetes/enhancements/tree/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity

v2的改动从v2beta2版本开始。

由於筆者尚未實際測試,因此以下內容僅基於文件和問題說明進行推測總結。請注意可能存在錯誤部分。

HPA v2beta2 到 v2 的变更不是很多,只有以下这些规范的变更:

    • メトリクスタイプ(spec.metrics.type)のResourceがPodResourceに変更されました

DisabledからScalingDisabledに変更されました
behaviorのselectPolicy(spec.behavior.scaleUp/Down.selectPolicy)の値が次のように変更されました

Max -> MaxChange

Min -> MinChange

如果使用了相关的规范(spec),则按照上述方式进行更改,并将版本更改为v2,迁移将完成。
只有规范的设置值发生了更改,似乎没有更改HPA本身的行为。

请参阅 KEP 获取更详细的信息:https://github.com/kubernetes/enhancements/issues/2702。

v1的时候,只能针对特定的资源,但是我忘记了从什么时候起,只要有Scale子资源,就可以针对任何资源,并且还可以针对通过CRD创建的自定义资源。
以前是30秒,但我记得扩容速度成为一个问题,变得更短了。
这个定义在这个文件中:https://github.com/kubernetes/kubernetes/blob/bd8e8507093095bbe411fd501ea5971f5b077b3b/staging/src/k8s.io/api/autoscaling/v2/types.go#L97
看起来还在alpha版本上。KEP: https://github.com/kubernetes/enhancements/tree/master/keps/sig-autoscaling/1610-container-resource-autoscaling
以前我们使用heapster,但现在推荐使用metrics-server。
https://kubernetes.io/docs/tasks/extend-kubernetes/configure-aggregation-layer/
广告
将在 10 秒后关闭
bannerAds