Horizontal Pod Autoscaler

Pod 水平自动伸缩

Pod 水平自动伸缩(Horizontal Pod Autoscaler)特性, 可以基于CPU利用率自动伸缩 replication controller、deployment和 replica set 中的 pod 数量,(除了 CPU 利用率)也可以 基于其他应程序提供的度量指标custom metrics。 pod 自动缩放不适用于无法缩放的对象,比如 DaemonSets。

Pod 水平自动伸缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。 控制器会周期性的获取平均 CPU 利用率,并与目标值相比较后来调整 replication controller 或 deployment 中的副本数量。

Pod 水平自动伸缩工作机制

水平自动伸缩示意图

Pod 水平自动伸缩的实现是一个控制循环,由 controller manager 的 --horizontal-pod-autoscaler-sync-period 参数 指定周期(默认值为15秒)。

每个周期内,controller manager 根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。 controller manager 可以从 resource metrics API(每个pod 资源指标)和 custom metrics API(其他指标)获取指标。

  • 对于每个 pod 的资源指标(如 CPU),控制器从资源指标 API 中获取每一个 HorizontalPodAutoscaler 指定 的 pod 的指标,然后,如果设置了目标使用率,控制器获取每个 pod 中的容器资源使用情况,并计算资源使用率。 如果使用原始值,将直接使用原始数据(不再计算百分比)。 然后,控制器根据平均的资源使用率或原始值计算出缩放的比例,进而计算出目标副本数。

需要注意的是,如果 pod 某些容器不支持资源采集,那么控制器将不会使用该 pod 的 CPU 使用率。 下面的算法细节章节将会介绍详细的算法。

  • 如果 pod 使用自定义指示,控制器机制与资源指标类似,区别在于自定义指标只使用原始值,而不是使用率。

  • 如果pod 使用对象指标和外部指标(每个指标描述一个对象信息)。 这个指标将直接跟据目标设定值相比较,并生成一个上面提到的缩放比例。在 autoscaling/v2beta2 版本API中, 这个指标也可以根据 pod 数量平分后再计算。

通常情况下,控制器将从一系列的聚合 API(metrics.k8s.iocustom.metrics.k8s.ioexternal.metrics.k8s.io) 中获取指标数据。 metrics.k8s.io API 通常由 metrics-server(需要额外启动)提供。 可以从metrics-server 获取更多信息。 另外,控制器也可以直接从 Heapster 获取指标。

注意:

FEATURE STATE: Kubernetes 1.11 废弃

自 Kubernetes 1.11起,从 Heapster 获取指标特性已废弃。

关于指标 API 更多信息,请参考Support for metrics APIs

自动缩放控制器使用 scale sub-resource 访问相应可支持缩放的控制器(如replication controllers、deployments 和 replica sets)。 scale 是一个可以动态设定副本数量和检查当前状态的接口。 更多关于 scale sub-resource 的信息,请参考这里.

算法细节

从最基本的角度来看,pod 水平自动缩放控制器跟据当前指标和期望指标来计算缩放比例。

期望副本数 = ceil[当前副本数 * ( 当前指标 / 期望指标 )]

例如,当前指标为200m,目标设定值为100m,那么由于200.0 / 100.0 == 2.0, 副本数量将会翻倍。 如果当前指标为50m,副本数量将会减半,因为50.0 / 100.0 == 0.5。 如果计算出的缩放比例接近1.0(跟据--horizontal-pod-autoscaler-tolerance 参数全局配置的容忍值,默认为0.1), 将会放弃本次缩放。

如果 HorizontalPodAutoscaler 指定的是targetAverageValuetargetAverageUtilization, 那么将会把指定pod的平均指标做为currentMetricValue。 然而,在检查容忍度和决定最终缩放值前,我们仍然会把那些无法获取指标的pod统计进去。

所有被标记了删除时间戳(Pod正在关闭过程中)的 pod 和 失败的 pod 都会被忽略。

如果某个 pod 缺失指标信息,它将会被搁置,只在最终确定缩值时再考虑。

当使用 CPU 指标来缩放时,任何还未就绪(例如还在初始化)状态的 pod 最近的指标为就绪状态前的 pod, 也会被搁置

由于受技术限制,pod 水平缩放控制器无法准确的知道 pod 什么时候就绪, 也就无法决定是否暂时搁置该 pod。 --horizontal-pod-autoscaler-initial-readiness-delay 参数(默认为30s),用于设置 pod 准备时间, 在此时间内的 pod 统统被认为未就绪。 --horizontal-pod-autoscaler-cpu-initialization-period参数(默认为5分钟),用于设置 pod 的初始化时间, 在此时间内的 pod,CPU 资源指标将不会被采纳。

在排除掉被搁置的 pod 后,缩放比例就会跟据currentMetricValue / desiredMetricValue计算出来。

如果有任何 pod 的指标缺失,我们会更保守地重新计算平均值, 在需要缩小时假设这些 pod 消耗了目标值的 100%, 在需要放大时假设这些 pod 消耗了0%目标值。 这可以在一定程度上抑制伸缩的幅度。

此外,如果存在任何尚未就绪的pod,我们可以在不考虑遗漏指标或尚未就绪的pods的情况下进行伸缩, 我们保守地假设尚未就绪的pods消耗了试题指标的0%,从而进一步降低了伸缩的幅度。

在缩放方向(缩小或放大)确定后,我们会把未就绪的 pod 和缺少指标的 pod 考虑进来再次计算使用率。 如果新的比率与缩放方向相反,或者在容忍范围内,则跳过缩放。 否则,我们使用新的缩放比例。

注意,平均利用率的*原始*值会通过 HorizontalPodAutoscaler 的状态体现( 即使使用了新的使用率,也不考虑未就绪 pod 和 缺少指标的 pod)。

如果创建 HorizontalPodAutoscaler 时指定了多个指标, 那么会按照每个指标分别计算缩放副本数,取最大的进行缩放。 如果任何一个指标无法顺利的计算出缩放副本数(比如,通过 API 获取指标时出错), 那么本次缩放会被跳过。

最后,在 HPA 控制器执行缩放操作之前,会记录缩放建议信息(scale recommendation)。 控制器会在操作时间窗口中考虑所有的建议信息,并从中选择得分最高的建议。 这个值可通过 kube-controller-manager 服务的启动参数 --horizontal-pod-autoscaler-downscale-stabilization 进行配置, 默认值为 5min。 这个配置可以让系统更为平滑地进行缩容操作,从而消除短时间内指标值快速波动产生的影响。

API 对象

HorizontalPodAutoscaler 是 Kubernetes autoscaling API 组的资源。 在当前稳定版本(autoscaling/v1)中只支持基于CPU指标的缩放。

在 beta 版本(autoscaling/v2beta2),引入了基于内存和自定义指标的缩放。 在autoscaling/v2beta2版本中新引入的字段在autoscaling/v1版本中基于 annotation 实现。

更多有关 API 对象的信息,请查阅HorizontalPodAutoscaler Object

使用 kubectl 操作 Horizontal Pod Autoscaler

与其他 API 资源类似,kubectl 也标准支持 Pod 自动伸缩。 我们可以通过 kubectl create 命令创建一个自动伸缩对象, 通过 kubectl get hpa 命令来获取所有自动伸缩对象, 通过 kubectl describe hpa 命令来查看自动伸缩对象的详细信息。 最后,可以使用 kubectl delete hpa 命令删除对象。

此外,还有个简便的命令 kubectl autoscale 来创建自动伸缩对象。 例如,命令 kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80 将会为名 为 foo 的 replication set 创建一个自动伸缩对象, 对象目标CPU使用率为 80%,副本数量配置为 2 到 5 之间。

滚动升级时缩放

目前在 Kubernetes 中,可以针对 replication controllers 或 deployment 执行 滚动升级rolling update,他们会为你管理底层副本数。 Pod 水平缩放只支持后一种:Horizontal Pod Autoscaler 会被绑定到 deployment 对象中,Horizontal Pod Autoscaler 设置副本数量时, deployment 会设置底层副本数。

当使用 replication controllers 执行滚动升级时, Horizontal Pod Autoscaler 不能工作, 也就是说你不能将 Horizontal Pod Autoscaler 绑定到某个 replication controller 再执行滚动升级(例如使用 kubectl rolling-update 命令)。 Horizontal Pod Autoscaler 不能工作的原因是,Horizontal Pod Autoscaler 无法绑定到滚动升级时创建的新副本。

冷却/延迟

当使用 Horizontal Pod Autoscaler 管理一组副本缩放时, 有可能因为指标动态的变化造成副本数量频繁的变化,有时这被称为 *抖动*。

从 v1.6 版本起,集群操作员可以开启某些 kube-controller-manager 全局的参数来缓和这个问题。

从 v1.12 开始,算法调整后,就不用这么做了。

  • --horizontal-pod-autoscaler-downscale-stabilization: 这个 kube-controller-manager 的参数表示缩容冷却时间。 即自从上次缩容执行结束后,多久可以再次执行缩容,默认时间是5分钟(5m0s)。

注意:

当启用这个参数时,集群操作员需要明白其可能的影响。 如果延迟(冷却)时间设置的太长,那么 Horizontal Pod Autoscaler 可能会不能很好的改变负载。 如果延迟(冷却)时间设备的太短,那么副本数量有可能跟以前一样抖动。

多指标支持

在 Kubernetes 1.6 支持了基于多个指标进行缩放。 你可以使用 autoscaling/v2beta2 API 来为 Horizontal Pod Autoscaler 指定多个指标。 Horizontal Pod Autoscaler 会跟据每个指标计算,并生成一个缩放建议。 幅度最大的缩放建议会被采纳。

自定义指标支持

注意:

在 Kubernetes 1.2 增加的 alpha 的缩放支持基于特定的 annotation。 自从 Kubernetes 1.6 起,由于缩放 API 的引入,这些 annotation 就不再支持了。 虽然收集自定义指标的旧方法仍然可用,但是 Horizontal Pod Autoscaler 调度器将不会再使用这些指标, 同时,Horizontal Pod Autoscaler 也不再使用之前的用于指定用户自定义指标的 annotation 了。

自 Kubernetes 1.6 起,Horizontal Pod Autoscaler 支持使用自定义指标。 你可以使用 autoscaling/v2beta2 API 为 Horizontal Pod Autoscaler 指定用户自定义指标。 Kubernetes 会通过用户自定义指标 API 来获取相应的指标。

关于指标 API 的要求,请查阅 Support for metrics APIs

指标 API

默认情况下,HorizontalPodAutoscaler 控制器会从一系列的 API 中请求指标数据。 集群管理员需要确保下述条件,以保证这些 API 可以访问:

  • API aggregation layer 已开启

  • 相应的 API 已注册:

    • 资源指标会使用 metrics.k8s.io API,一般由 metrics-server 提供。 它可以做为集群组件启动。
    • 用户指标会使用 custom.metrics.k8s.io API。 它由其他厂商的“适配器”API 服务器提供。 确认你的指标管道,或者查看 list of known solutions
    • 外部指标会使用 external.metrics.k8s.io API。可能由上面的用户指标适配器提供。
  • --horizontal-pod-autoscaler-use-rest-clients 参数设置为 true 或者不设置。 如果设置为 false,则会切换到基于 Heapster 的自动缩放,这个特性已经被弃用了。

更多关于指标来源以及其区别,请参阅相关的设计文档, the HPA V2custom.metrics.k8s.ioexternal.metrics.k8s.io

如何使用它们的示例,请参考 the walkthrough for using custom metricsthe walkthrough for using external metrics

接下来

反馈

此页是否对您有帮助?

是 否


Analytics

报告 GitHub 问题 修改本页面

页面最后一次修改于 December 25, 2019 at 8:51 AM PST 由: ZH-trans: merge release1.16-temporary to master (#18217) (页面历史)

Horizontal Pod Autoscaler演练

Horizontal Pod Autoscaler 可以根据CPU利用率自动伸缩 replication controller、deployment 或者 replica set 中的Pod数量 (也可以基于其他应用程序提供的度量指标,目前这一功能处于 beta 版本)。

本文将引导您了解如何为 php-apache 服务器配置和使用 Horizontal Pod Autoscaler。 更多 Horizontal Pod Autoscaler 的信息请参阅 Horizontal Pod Autoscaler user guide

准备开始

本文示例需要一个1.2或者更高版本的可运行的 Kubernetes 集群以及 kubectl。 metrics-server 也需要部署到集群中, 它可以通过 resource metrics API 对外提供度量数据,Horizontal Pod Autoscaler 正是根据此 API 来获取度量数据,部署方法请参考 metrics-server 。 如果你正在使用GCE,按照 getting started on GCE guide 操作,metrics-server 会默认启动。

如果需要为 Horizontal Pod Autoscaler 指定多种资源度量指标,您的 Kubernetes 集群以及 kubectl 至少需要达到1.6版本。 此外,如果要使用自定义度量指标,您的Kubernetes 集群还必须能够与提供这些自定义指标的API服务器通信。 最后,如果要使用与 Kubernetes 对象无关的度量指标,则 Kubernetes 集群版本至少需要达到1.10版本,同样,需要保证集群能够与提供这些外部指标的API服务器通信。 更多详细信息,请参阅Horizontal Pod Autoscaler user guide

第一步:运行 php-apache 服务器并暴露服务

为了演示 Horizontal Pod Autoscaler,我们将使用一个基于 php-apache 镜像的定制 Docker 镜像。 Dockerfile 内容如下:

FROM php:5-apache
ADD index.php /var/www/html/index.php
RUN chmod a+rx index.php

它定义一个 index.php 页面来执行一些 CPU 密集型计算:

<?php
  $x = 0.0001;
  for ($i = 0; $i <= 1000000; $i++) {
    $x += sqrt($x);
  }
  echo "OK!";
?>

首先,我们先启动一个 deployment 来运行这个镜像并暴露一个服务:

kubectl run php-apache --image=k8s.gcr.io/hpa-example --requests=cpu=200m --expose --port=80
service/php-apache created
deployment.apps/php-apache created

创建 Horizontal Pod Autoscaler

现在,php-apache服务器已经运行,我们将通过 kubectl autoscale 命令创建 Horizontal Pod Autoscaler。 以下命令将创建一个 Horizontal Pod Autoscaler 用于控制我们上一步骤中创建的 deployment,使 Pod 的副本数量在维持在1到10之间。 大致来说,HPA 将通过增加或者减少 Pod 副本的数量(通过 Deployment )以保持所有 Pod 的平均CPU利用率在50%以内 (由于每个 Pod 通过 kubectl run 申请了200 milli-cores CPU,所以50%的 CPU 利用率意味着平均 CPU 利用率为100 milli-cores)。 相关算法的详情请参阅here

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
horizontalpodautoscaler.autoscaling/php-apache autoscaled

我们可以通过以下命令查看 autoscaler 的状态:

kubectl get hpa
NAME         REFERENCE                     TARGET    MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache/scale   0% / 50%  1         10        1          18s

请注意在上面的命令输出中,当前的CPU利用率是0%,这是由于我们尚未发送任何请求到服务器 (CURRENT 列显示了相应 deployment 所控制的所有 Pod 的平均 CPU 利用率)。

增加负载

现在,我们将看到 autoscaler 如何对增加负载作出反应。 我们将启动一个容器,并通过一个循环向 php-apache 服务器发送无限的查询请求(请在另一个终端中运行以下命令):

kubectl run -i --tty load-generator --image=busybox /bin/sh

Hit enter for command prompt

while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done

在几分钟时间内,通过以下命令,我们可以看到CPU负载升高了:

kubectl get hpa
NAME         REFERENCE                     TARGET      CURRENT   MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache/scale   305% / 50%  305%      1         10        1          3m

这时,由于请求增多,CPU利用率已经升至305%。 可以看到,deployment 的副本数量已经增长到了7:

kubectl get deployment php-apache
NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
php-apache   7         7         7            7           19m

注意: 有时最终副本的数量可能需要几分钟才能稳定下来。 由于环境的差异,不同环境中最终的副本数量可能与本示例中的数量不同。

停止负载

我们将通过停止负载来结束我们的示例。

在我们创建 busybox 容器的终端中,输入+ C来终止负载的产生。

然后我们可以再次查看负载状态(等待几分钟时间):

kubectl get hpa
NAME         REFERENCE                     TARGET       MINPODS   MAXPODS   REPLICAS   AGE
php-apache   Deployment/php-apache/scale   0% / 50%     1         10        1          11m
kubectl get deployment php-apache
NAME         DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
php-apache   1         1         1            1           27m

这时,CPU利用率已经降到0,所以 HPA 将自动缩减副本数量至1。

注意: 自动伸缩完成副本数量的改变可能需要几分钟的时间。

基于多项度量指标和自定义度量指标自动伸缩

利用autoscaling/v2beta2API版本,您可以在自动伸缩 php-apache 这个 Deployment 时引入其他度量指标。

首先,获取autoscaling/v2beta2格式的 HorizontalPodAutoscaler 的YAML文件:

kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml

在编辑器中打开/tmp/hpa-v2.yaml

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
status:
  observedGeneration: 1
  lastScaleTime: <some-time>
  currentReplicas: 1
  desiredReplicas: 1
  currentMetrics:
  - type: Resource
    resource:
      name: cpu
      current:
        averageUtilization: 0
        averageValue: 0

需要注意的是,targetCPUUtilizationPercentage 字段已经被名为 metrics 的数组所取代。 CPU利用率这个度量指标是一个resource metric(资源度量指标),因为它表示容器上指定资源的百分比。 除CPU外,您还可以指定其他资源度量指标。默认情况下,目前唯一支持的其他资源度量指标为内存。 只要metrics.k8s.io API存在,这些资源度量指标就是可用的,并且他们不会在不同的Kubernetes集群中改变名称。

您还可以指定资源度量指标使用绝对数值,而不是百分比,你需要将target类型AverageUtilization替换成AverageValue,同时 将target.averageUtilization替换成target.averageValue并设定相应的值。

还有两种其他类型的度量指标,他们被认为是*custom metrics*(自定义度量指标): 即 Pod 度量指标和对象度量指标(pod metrics and object metrics)。 这些度量指标可能具有特定于集群的名称,并且需要更高级的集群监控设置。

第一种可选的度量指标类型是 Pod 度量指标。这些指标从某一方面描述了Pod,在不同Pod之间进行平均,并通过与一个目标值比对来确定副本的数量。 它们的工作方式与资源度量指标非常相像,差别是它们仅支持target 类型为AverageValue

Pod 度量指标通过如下代码块定义:

type: Pods
pods:
  metric:
    name: packets-per-second
  target:
    type: AverageValue
    averageValue: 1k

第二种可选的度量指标类型是对象度量指标。相对于描述 Pod,这些度量指标用于描述一个在相同名字空间(namespace)中的其他对象。 请注意这些度量指标用于描述这些对象,并非从对象中获取。 对象度量指标支持的target类型包括ValueAverageValue。如果是Value类型,target值将直接与API返回的度量指标比较, 而AverageValue类型,API返回的度量指标将按照 Pod 数量拆分,然后再与target值比较。 下面的 YAML 文件展示了一个表示requests-per-second的度量指标。

type: Object
object:
  metric:
    name: requests-per-second
  describedObject:
    apiVersion: networking.k8s.io/v1beta1
    kind: Ingress
    name: main-route
  target:
    type: Value
    value: 2k

如果您指定了多个上述类型的度量指标,HorizontalPodAutoscaler 将会依次考量各个指标。 HorizontalPodAutoscaler 将会计算每一个指标所提议的副本数量,然后最终选择一个最高值。

比如,如果您的监控系统能够提供网络流量数据,您可以通过kubectl edit命令将上述 Horizontal Pod Autoscaler 的定义更改为:

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: AverageUtilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      targetAverageValue: 1k
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1beta1
        kind: Ingress
        name: main-route
      target:
        kind: Value
        value: 10k
status:
  observedGeneration: 1
  lastScaleTime: <some-time>
  currentReplicas: 1
  desiredReplicas: 1
  currentMetrics:
  - type: Resource
    resource:
      name: cpu
    current:
      averageUtilization: 0
      averageValue: 0
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: networking.k8s.io/v1beta1
        kind: Ingress
        name: main-route
      current:
        value: 10k

然后,您的 HorizontalPodAutoscaler 将会尝试确保每个Pod的CPU利用率在50%以内,每秒能够服务1000个数据包请求, 并确保所有在Ingress后的Pod每秒能够服务的请求总数达到10000个。

多个度量指标下伸缩

许多度量管道允许您通过名称或附加的_labels_来描述度量指标。对于所有非资源类型度量指标(pod、object和后面将介绍的external), ,可以额外指定一个标签选择器。例如,如果你希望收集包含verb标签的http_requests度量指标, 你可以在 GET 请求中指定需要的度量指标,如下所示:

type: Object
object:
  metric:
    name: `http_requests`
    selector: `verb=GET`

这个选择器使用与 Kubernetes 标签选择器相同的语法。 如果名称和标签选择器匹配到多个系列,监测管道会决定如何将多个系列合并成单个值。 选择器是附加的,它不会选择目标以外的对象(类型为Pods的目标和类型为Object的目标)。

基于Kubernetes以外的度量指标伸缩

运行在 Kubernetes 上的应用程序可能需要基于与 Kubernetes 集群中的任何对象没有明显关系的度量指标进行自动伸缩, 例如那些描述不在 Kubernetes 任何 namespaces 服务的度量指标。

使用外部的度量指标,需要了解你使用的监控系统,相关的设置与使用自定义试题指标类似。 External metrics 可以使用你的监控系统的任何指标来自动伸缩你的集群。你只需要在metric块中提供nameselector,同时将类型由Object改为External。 如果metricSelector匹配到多个度量指标,HorizontalPodAutoscaler 将会把它们加和。 External metrics 同时支持ValueAverageValue类型,这与Object类型的度量指标相同。

例如,如果你的应用程序处理主机上的消息队列, 为了让每30个任务有1个worker,你可以将下面的内容添加到 HorizontalPodAutoscaler 的配置中。

- type: External
  external:
    metric:
      name: queue_messages_ready
      selector: "queue=worker_tasks"
    target:
      type: AverageValue
      averageValue: 30

如果可能,还是推荐 custom metric 而不是 external metrics,因为这便于让系统管理员加固 custom metrics API。 而 external metrics API 可以允许访问所有的度量指标,当暴露这些服务时,系统管理员需要仔细考虑这个问题。

附录:Horizontal Pod Autoscaler状态条件

当使用autoscaling/v2beta2格式的 HorizontalPodAutoscaler 时,您将可以看到 Kubernetes 为 HorizongtalPodAutoscaler 设置的状态条件(status conditions)。 这些状态条件可以显示当前 HorizontalPodAutoscaler 是否能够执行伸缩以及是否受到一定的限制。

status.conditions字段展示了这些状态条件。 可以通过kubectl describe hpa命令查看当前影响 HorizontalPodAutoscaler 的各种状态条件信息:

kubectl describe hpa cm-test
Name:                           cm-test
Namespace:                      prom
Labels:                         <none>
Annotations:                    <none>
CreationTimestamp:              Fri, 16 Jun 2017 18:09:22 +0000
Reference:                      ReplicationController/cm-test
Metrics:                        ( current / target )
  "http_requests" on pods:      66m / 500m
Min replicas:                   1
Max replicas:                   4
ReplicationController pods:     1 current / 1 desired
Conditions:
  Type                  Status  Reason                  Message
  ----                  ------  ------                  -------
  AbleToScale           True    ReadyForNewScale        the last scale time was sufficiently old as to warrant a new scale
  ScalingActive         True    ValidMetricFound        the HPA was able to successfully calculate a replica count from pods metric http_requests
  ScalingLimited        False   DesiredWithinRange      the desired replica count is within the acceptable range
Events:

对于上面展示的这个 HorizontalPodAutoscaler,我们可以看出有若干状态条件处于健康状态。 首先,AbleToScale 表明 HPA 是否可以获取和更新伸缩信息,以及是否存在阻止伸缩的各种回退条件。 其次,ScalingActive 表明HPA是否被启用(即目标的副本数量不为零) 以及是否能够完成伸缩计算。 当这一状态为 False 时,通常表明获取度量指标存在问题。 最后一个条件 ScalingLimitted 表明所需伸缩的值被 HorizontalPodAutoscaler 所定义的最大或者最小值所限制(即已经达到最大或者最小伸缩值)。 这通常表明您可能需要调整 HorizontalPodAutoscaler 所定义的最大或者最小副本数量的限制了。

附录:Quantities

HorizontalPodAutoscaler 和 metrics api 中的所有的度量指标使用 Kubernetes 中称为 quantity ()殊整数表示。 例如,数量10500m用十进制表示为10.5。 如果可能的话,metrics api 将返回没有后缀的整数,否则返回以千分单位的数量。 这意味着您可能会看到您的度量指标在11500m之间波动,或者在十进制记数法中的11.5。 更多信息,请参阅度量术语

附录:其他可能的情况

使用YAML文件创建 autoscaler

除了使用 kubectl autoscale 命令,也可以文件创建 HorizontalPodAutoscaler :

application/hpa/php-apache.yaml Copy application/hpa/php-apache.yaml to clipboard
apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: php-apache namespace: default spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: php-apache minReplicas: 1 maxReplicas: 10 targetCPUUtilizationPercentage: 50

使用如下命令创建 autoscaler:

kubectl create -f https://k8s.io/examples/application/hpa/php-apache.yaml
horizontalpodautoscaler.autoscaling/php-apache created

反馈

此页是否对您有帮助?

是 否


Analytics

报告 GitHub 问题 修改本页面

页面最后一次修改于 December 25, 2019 at 8:51 AM PST 由: ZH-trans: merge release1.16-temporary to master (#18217) (页面历史)

这些信息有用吗?
Do you have any suggestions for improvement?

Thanks for your feedback!