From d430cf1a3410770fca3d1a2fb49aa633961d61f5 Mon Sep 17 00:00:00 2001 From: 0xff-dev Date: Fri, 15 Apr 2022 21:50:47 +0800 Subject: [PATCH] [zh] sync horizontal-pod-autoscale.md --- .../horizontal-pod-autoscale.md | 680 ++++++++++-------- 1 file changed, 378 insertions(+), 302 deletions(-) diff --git a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md index b71841d7e2..8cc8dc42f4 100644 --- a/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -12,61 +12,97 @@ weight: 90 -Pod 水平自动扩缩（Horizontal Pod Autoscaler） -可以基于 CPU 利用率自动扩缩 ReplicationController、Deployment、ReplicaSet 和 -StatefulSet 中的 Pod 数量。 -除了 CPU 利用率，也可以基于其他应程序提供的 -[自定义度量指标](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md) -来执行自动扩缩。 -Pod 自动扩缩不适用于无法扩缩的对象，比如 DaemonSet。 +在 Kubernetes 中，_HorizontalPodAutoscaler_ 自动更新工作负载资源 +（例如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或者 +{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}）， +目的是自动扩缩工作负载以满足需求。 -Pod 水平自动扩缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。 -控制器会周期性地调整副本控制器或 Deployment 中的副本数量，以使得类似 Pod 平均 CPU -利用率、平均内存利用率这类观测到的度量值与用户所设定的目标值匹配。 +水平扩缩意味着对增加的负载的响应是部署更多的 {{< glossary_tooltip text="Pods" term_id="pod" >}}。 +这与 “垂直（Vertical）” 扩缩不同，对于 Kubernetes， +垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod。 + +如果负载减少，并且 Pod 的数量高于配置的最小值， +HorizontalPodAutoscaler 会指示工作负载资源（ Deployment、StatefulSet 或其他类似资源）缩减。 + + +水平 Pod 自动扩缩不适用于无法扩缩的对象（例如：{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}。） + + +HorizontalPodAutoscaler 被实现为 Kubernetes API 资源和{{< glossary_tooltip text="控制器" term_id="controller" >}}。 + +资源决定了控制器的行为。在 Kubernetes {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}内运行的水平 +Pod 自动扩缩控制器会定期调整其目标（例如：Deployment）的所需规模，以匹配观察到的指标， +例如，平均 CPU 利用率、平均内存利用率或你指定的任何其他自定义指标。 + + +使用水平 Pod 自动扩缩[演练示例](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)。 -## Pod 水平自动扩缩工作机制 +## HorizontalPodAutoscaler 是如何工作的？ {#how-does-a-horizontalpodautoscaler-work} -![水平自动扩缩示意图](/images/docs/horizontal-pod-autoscaler.svg) +{{< figure src="/images/docs/horizontal-pod-autoscaler.svg" caption="HorizontalPodAutoscaler 控制 Deployment 及其 ReplicaSet 的规模" class="diagram-medium">}} -Pod 水平自动扩缩器的实现是一个控制回路，由控制器管理器的 `--horizontal-pod-autoscaler-sync-period` 参数指定周期（默认值为 15 秒）。 +Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路（它不是一个连续的过程）。间隔由 +[`kube-controller-manager`](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) +的 `--horizontal-pod-autoscaler-sync-period` 参数设置（默认间隔为 15 秒）。 -每个周期内，控制器管理器根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。 -控制器管理器可以从资源度量指标 API（按 Pod 统计的资源用量）和自定义度量指标 -API（其他指标）获取度量值。 +在每个时间段内，控制器管理器都会根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。 +控制器管理器找到由 `scaleTargetRef` 定义的目标资源，然后根据目标资源的 `.spec.selector` 标签选择 Pod， +并从资源指标 API（针对每个 Pod 的资源指标）或自定义指标获取指标 API（适用于所有其他指标）。 * 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个 HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率， - 控制器获取每个 Pod 中的容器资源使用情况，并计算资源使用率。 - 如果设置了 target 值，将直接使用原始数据（不再计算百分比）。 + 控制器获取每个 Pod 中的容器[资源使用](/zh/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) 情况， + 并计算资源使用率。如果设置了 target 值，将直接使用原始数据（不再计算百分比）。 接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。 -通常情况下，控制器将从一系列的聚合 API（`metrics.k8s.io`、`custom.metrics.k8s.io` -和 `external.metrics.k8s.io`）中获取度量值。 -`metrics.k8s.io` API 通常由 Metrics 服务器（需要额外启动）提供。 -可以从 [metrics-server](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server) 获取更多信息。 -另外，控制器也可以直接从 Heapster 获取指标。 - -{{< note >}} -{{< feature-state state="deprecated" for_k8s_version="1.11" >}} - -自 Kubernetes 1.11 起，从 Heapster 获取指标特性已废弃。 -{{< /note >}} +HorizontalPodAutoscaler 的常见用途是将其配置为从{{< glossary_tooltip text="聚合 API" term_id="aggregation-layer" >}} +（`metrics.k8s.io`、`custom.metrics.k8s.io` 或 `external.metrics.k8s.io`）获取指标。 +`metrics.k8s.io` API 通常由名为 Metrics Server 的插件提供，需要单独启动。有关资源指标的更多信息， +请参阅 [Metrics Server](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)。 -关于指标 API 更多信息，请参考[度量值指标 API 的支持](#support-for-metrics-apis)。 +[Support for metrics APIs](#support-for-metrics-apis) explains the stability guarantees and support status for these +different APIs. - -自动扩缩控制器使用 scale 子资源访问相应可支持扩缩的控制器（如副本控制器、 -Deployment 和 ReplicaSet）。 -`scale` 是一个可以动态设定副本数量和检查当前状态的接口。 -关于 scale 子资源的更多信息，请参考[这里](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource). +对 [Metrics API 的支持](#support-for-metrics-apis)解释了这些不同 API 的稳定性保证和支持状态 + +HorizontalPodAutoscaler 控制器访问支持扩缩的相应工作负载资源（例如：Deployments 和 StatefulSet）。 +这些资源每个都有一个名为 `scale` 的子资源，该接口允许你动态设置副本的数量并检查它们的每个当前状态。 +有关 Kubernetes API 子资源的一般信息， +请参阅 [Kubernetes API 概念](/zh/docs/reference/using-api/api-concepts/)。 -例如，当前度量值为 `200m`，目标设定值为 `100m`，那么由于 `200.0/100.0 == 2.0`， -副本数量将会翻倍。 -如果当前指标为 `50m`，副本数量将会减半，因为`50.0/100.0 == 0.5`。 -如果计算出的扩缩比例接近 1.0 -（根据`--horizontal-pod-autoscaler-tolerance` 参数全局配置的容忍值，默认为 0.1）， -将会放弃本次扩缩。 +例如，如果当前指标值为 `200m`，而期望值为 `100m`，则副本数将加倍， +因为 `200.0 / 100.0 == 2.0` 如果当前值为 `50m`，则副本数将减半， +因为 `50.0 / 100.0 == 0.5`。如果比率足够接近 1.0（在全局可配置的容差范围内，默认为 0.1）， +则控制平面会跳过扩缩操作。 如果 HorizontalPodAutoscaler 指定的是 `targetAverageValue` 或 `targetAverageUtilization`， 那么将会把指定 Pod 度量值的平均值做为 `currentMetricValue`。 -然而，在检查容忍度和决定最终扩缩值前，我们仍然会把那些无法获取指标的 Pod 统计进去。 + +在检查容差并决定最终值之前，控制平面还会考虑是否缺少任何指标， +以及有多少 Pod [`已就绪`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)。 -所有被标记了删除时间戳（Pod 正在关闭过程中）的 Pod 和失败的 Pod 都会被忽略。 +所有设置了删除时间戳的 Pod（带有删除时间戳的对象正在关闭/移除的过程中）都会被忽略， +所有失败的 Pod 都会被丢弃。 如果某个 Pod 缺失度量值，它将会被搁置，只在最终确定扩缩数量时再考虑。 -当使用 CPU 指标来扩缩时，任何还未就绪（例如还在初始化）状态的 Pod *或* 最近的指标 -度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。 +当使用 CPU 指标来扩缩时，任何还未就绪（还在初始化，或者可能是不健康的）状态的 Pod **或** +最近的指标度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。 -由于受技术限制，Pod 水平扩缩控制器无法准确的知道 Pod 什么时候就绪， -也就无法决定是否暂时搁置该 Pod。 -`--horizontal-pod-autoscaler-initial-readiness-delay` 参数（默认为 30s）用于设置 Pod 准备时间， -在此时间内的 Pod 统统被认为未就绪。 -`--horizontal-pod-autoscaler-cpu-initialization-period` 参数（默认为5分钟） -用于设置 Pod 的初始化时间， -在此时间内的 Pod，CPU 资源度量值将不会被采纳。 +由于技术限制，HorizontalPodAutoscaler 控制器在确定是否保留某些 CPU 指标时无法准确确定 Pod 首次就绪的时间。 +相反，如果 Pod 未准备好并在其启动后的一个可配置的短时间窗口内转换为未准备好，它会认为 Pod “尚未准备好”。 +该值使用 `--horizontal-pod-autoscaler-initial-readiness-delay` 标志配置，默认值为 30 秒。 +一旦 Pod 准备就绪，如果它发生在自启动后较长的、可配置的时间内，它就会认为任何向准备就绪的转换都是第一个。 +该值由 `-horizontal-pod-autoscaler-cpu-initialization-period` 标志配置，默认为 5 分钟。 -如果缺失任何的度量值，我们会更保守地重新计算平均值， -在需要缩小时假设这些 Pod 消耗了目标值的 100%， -在需要放大时假设这些 Pod 消耗了 0% 目标值。 -这可以在一定程度上抑制扩缩的幅度。 +如果缺失某些度量值，控制平面会更保守地重新计算平均值，在需要缩小时假设这些 Pod 消耗了目标值的 100%， +在需要放大时假设这些 Pod 消耗了 0% 目标值。这可以在一定程度上抑制扩缩的幅度。 -此外，如果存在任何尚未就绪的 Pod，我们可以在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩， -我们保守地假设尚未就绪的 Pod 消耗了期望指标的 0%，从而进一步降低了扩缩的幅度。 +此外，如果存在任何尚未就绪的 Pod，工作负载会在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩， +控制器保守地假设尚未就绪的 Pod 消耗了期望指标的 0%，从而进一步降低了扩缩的幅度。 -在扩缩方向（缩小或放大）确定后，我们会把未就绪的 Pod 和缺少指标的 Pod 考虑进来再次计算使用率。 -如果新的比率与扩缩方向相反，或者在容忍范围内，则跳过扩缩。 -否则，我们使用新的扩缩比例。 +考虑到尚未准备好的 Pod 和缺失的指标后，控制器会重新计算使用率。 +如果新的比率与扩缩方向相反，或者在容差范围内，则控制器不会执行任何扩缩操作。 +在其他情况下，新比率用于决定对 Pod 数量的任何更改。 -注意，平均利用率的*原始*值会通过 HorizontalPodAutoscaler 的状态体现（ -即使使用了新的使用率，也不考虑未就绪 Pod 和 缺少指标的 Pod)。 +注意，平均利用率的 **原始** 值是通过 HorizontalPodAutoscaler 状态体现的， +而不考虑尚未准备好的 Pod 或缺少的指标，即使使用新的使用率也是如此。 ## API 对象 {#api-object} -HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组的资源。 -在当前稳定版本（`autoscaling/v1`）中只支持基于 CPU 指标的扩缩。 - - -API 的 beta 版本（`autoscaling/v2beta2`）引入了基于内存和自定义指标的扩缩。 -在 `autoscaling/v2beta2` 版本中新引入的字段在 `autoscaling/v1` 版本中以注解 -的形式得以保留。 +HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组中的 API 资源。 +当前的稳定版本可以在 `autoscaling/v2` API 版本中找到，其中包括对基于内存和自定义指标执行扩缩的支持。 +在使用 `autoscaling/v1` 时，`autoscaling/v2` 中引入的新字段作为注释保留。 创建 HorizontalPodAutoscaler 对象时，需要确保所给的名称是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 有关 API 对象的更多信息，请查阅 -[HorizontalPodAutoscaler 对象设计文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)。 +[HorizontalPodAutoscaler 对象设计文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling)。 -## kubectl 对 Horizontal Pod Autoscaler 的支持 +## 工作量规模的稳定性 {#flapping} -与其他 API 资源类似，`kubectl` 以标准方式支持 HPA。 -我们可以通过 `kubectl create` 命令创建一个 HPA 对象， -通过 `kubectl get hpa` 命令来获取所有 HPA 对象， -通过 `kubectl describe hpa` 命令来查看 HPA 对象的详细信息。 -最后，可以使用 `kubectl delete hpa` 命令删除对象。 - - -此外，还有个简便的命令 `kubectl autoscale` 来创建 HPA 对象。 -例如，命令 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` 将会为名 -为 *foo* 的 ReplicationSet 创建一个 HPA 对象， -目标 CPU 使用率为 `80%`，副本数量配置为 2 到 5 之间。 +在使用 HorizontalPodAutoscaler 管理一组副本的规模时，由于评估的指标的动态特性， +副本的数量可能会经常波动。这有时被称为 **抖动（thrashing）** 或 **波动（flapping）**。它类似于控制论中的 **滞后（hysteresis）** 概念。 -## 冷却/延迟支持 - -当使用 Horizontal Pod Autoscaler 管理一组副本扩缩时， -有可能因为指标动态的变化造成副本数量频繁的变化，有时这被称为 -*抖动（Thrashing）*。 - - -从 v1.6 版本起，集群操作员可以调节某些 `kube-controller-manager` 的全局参数来 -缓解这个问题。 - - -从 v1.12 开始，算法调整后，扩容操作时的延迟就不必设置了。 - - -- `--horizontal-pod-autoscaler-downscale-stabilization`: 设置缩容冷却时间窗口长度。 - 水平 Pod -扩缩器能够记住过去建议的负载规模，并仅对此时间窗口内的最大规模执行操作。 - 默认值是 5 分钟（`5m0s`）。 - - -{{< note >}} -当调整这些参数时，集群操作员需要明白其可能的影响。 -如果延迟（冷却）时间设置的太长，Horizontal Pod Autoscaler 可能会不能很好的改变负载。 -如果延迟（冷却）时间设置的太短，那么副本数量有可能跟以前一样出现抖动。 -{{< /note >}} - -`HorizontalPodAutoscaler` 也支持容器指标源，这时 HPA 可以跟踪记录一组 Pods 中各个容器的 +HorizontalPodAutoscaler API 也支持容器指标源，这时 HPA 可以跟踪记录一组 Pods 中各个容器的 资源用量，进而触发扩缩目标对象的操作。 -容器资源指标的支持使得你可以为特定 Pod 中最重要的容器配置规模缩放阈值。 +容器资源指标的支持使得你可以为特定 Pod 中最重要的容器配置规模扩缩阈值。 例如，如果你有一个 Web 应用和一个执行日志操作的边车容器，你可以基于 Web 应用的 资源用量来执行扩缩，忽略边车容器的存在及其资源用量。 @@ -517,7 +477,7 @@ of the pods then those pods are ignored and the recommendation is recalculated. for more details about the calculation. To use container resources for autoscaling define a metric source as follows: --> -如果你更改缩放目标对象，令其使用新的、包含一组不同的容器的 Pod 规约，你就需要 +如果你更改扩缩目标对象，令其使用新的、包含一组不同的容器的 Pod 规约，你就需要 修改 HPA 的规约才能基于新添加的容器来执行规模扩缩操作。 如果指标源中指定的容器不存在或者仅存在于部分 Pods 中，那么这些 Pods 会被忽略， HPA 会重新计算资源用量值。参阅[算法](#algorithm-details)小节进一步了解计算细节。 @@ -563,51 +523,50 @@ the old container name from the HPA specification. {{< /note >}} -## 多指标支持 {#support-for-multiple-metrics} +(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature) -Kubernetes 1.6 开始支持基于多个度量值进行扩缩。 -你可以使用 `autoscaling/v2beta2` API 来为 Horizontal Pod Autoscaler 指定多个指标。 -Horizontal Pod Autoscaler 会根据每个指标计算，并生成一个扩缩建议。 -幅度最大的扩缩建议会被采纳。 +Provided that you use the `autoscaling/v2` API version, you can configure a HorizontalPodAutoscaler +to scale based on a custom metric (that is not built in to Kubernetes or any Kubernetes component). +The HorizontalPodAutoscaler controller then queries for these custom metrics from the Kubernetes +API. - -## 自定义指标支持 {#support-for-custom-metrics} - -{{< note >}} -在 Kubernetes 1.2 增加了支持基于使用特殊注解表达的、特定于具体应用的扩缩能力， -此能力处于 Alpha 阶段。 -从 Kubernetes 1.6 起，由于新的 autoscaling API 的引入，这些 annotation 就被废弃了。 -虽然收集自定义指标的旧方法仍然可用，Horizontal Pod Autoscaler 调度器将不会再使用这些度量值。 -同时，Horizontal Pod Autoscaler 也不再使用之前用于指定用户自定义指标的注解。 -{{< /note >}} - - -自 Kubernetes 1.6 起，Horizontal Pod Autoscaler 支持使用自定义指标。 -你可以使用 `autoscaling/v2beta2` API 为 Horizontal Pod Autoscaler 指定用户自定义指标。 -Kubernetes 会通过用户自定义指标 API 来获取相应的指标。 - - -关于指标 API 的要求，请参阅[对 Metrics API 的支持](#support-for-metrics-apis)。 +## 扩展自定义指标 {#scaling-on-custom-metrics} + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供） + +如果你使用 `autoscaling/v2` API 版本，则可以将 HorizontalPodAutoscaler +配置为基于自定义指标（未内置于 Kubernetes 或任何 Kubernetes 组件）进行扩缩。 +HorizontalPodAutoscaler 控制器能够从 Kubernetes API 查询这些自定义指标。 + +有关要求，请参阅对 [Metrics APIs 的支持](#support-for-metrics-apis)。 + + +## 基于多个指标来执行扩缩 {#scaling-on-multiple-metrics} + +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供） + +如果你使用 `autoscaling/v2` API 版本，你可以为 HorizontalPodAutoscaler 指定多个指标以进行扩缩。 +HorizontalPodAutoscaler 控制器评估每个指标，并根据该指标提出一个新的比例。 +HorizontalPodAutoscaler 采用为每个指标推荐的最大比例， +并将工作负载设置为该大小（前提是这不大于你配置的总体最大值）。 * 启用了 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) @@ -645,24 +601,20 @@ APIs, cluster administrators must ensure that: * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。 它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。 - 确认你的指标流水线，或者查看[已知方案列表](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api)。 - 如果你想自己编写，请从 [boilerplate](https://github.com/kubernetes-sigs/custommetrics-apiserver)开始。 + 检查你的指标管道以查看是否有可用的 Kubernetes 指标适配器。 * 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。 -* `--horizontal-pod-autoscaler-use-rest-clients` 参数设置为 `true` 或者不设置。 - 如果设置为 false，则会切换到基于 Heapster 的自动扩缩，这个特性已经被弃用了。 - 关于指标来源以及其区别的更多信息，请参阅相关的设计文档， -[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md)、 -[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md) 和 -[external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md)。 +[HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md)， +[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md) 和 +[external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md)。 -## 支持可配置的扩缩 {#support-for-configurable-scaling-behaviour} +## 可配置的扩缩行为 {#configurable-scaling-behavior} -从 [v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md) -开始，`v2beta2` API 允许通过 HPA 的 `behavior` 字段配置扩缩行为。 -在 `behavior` 字段中的 `scaleUp` 和 `scaleDown` 分别指定扩容和缩容行为。 -可以两个方向指定一个稳定窗口，以防止扩缩目标中副本数量的波动。 -类似地，指定扩缩策略可以控制扩缩时副本数的变化率。 +{{< feature-state for_k8s_version="v1.23" state="stable" >}} + +（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供） + +如果你使用 `v2` HorizontalPodAutoscaler API，你可以使用 `behavior` 字段 +（请参阅 [API 参考](/zh/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec)） +来配置单独的放大和缩小行为。你可以通过在行为字段下设置 `scaleUp` 和/或 `scaleDown` 来指定这些行为。 + + + +你可以指定一个 “稳定窗口” ，以防止扩缩目标的副本计数发生[波动](#flapping)。 +扩缩策略还允许你在扩缩时控制副本的变化率。 ### 扩缩策略 {#scaling-policies} -在 spec 字段的 `behavior` 部分可以指定一个或多个扩缩策略。 -当指定多个策略时，默认选择允许更改最多的策略。 -下面的例子展示了缩容时的行为: +可以在规约的 `behavior` 部分中指定一个或多个扩缩策略。当指定多个策略时， +允许最大更改量的策略是默认选择的策略。以下示例显示了缩小时的这种行为： ```yaml behavior: @@ -750,35 +711,45 @@ scaling in that direction. --> 可以指定扩缩方向的 `selectPolicy` 字段来更改策略选择。 通过设置 `Min` 的值，它将选择副本数变化最小的策略。 -将该值设置为 `Disabled` 将完全禁用该方向的缩放。 +将该值设置为 `Disabled` 将完全禁用该方向的扩缩。 ### 稳定窗口 {#stabilization-window} -当用于扩缩的指标持续抖动时，使用稳定窗口来限制副本数上下振动。 -自动扩缩算法使用稳定窗口来考虑过去计算的期望状态，以防止扩缩。 -在下面的例子中，稳定化窗口被指定为 `scaleDown`。 +当用于扩缩的指标不断波动时，稳定窗口用于限制副本计数的[波动](#flapping)。 +自动扩缩算法使用此窗口来推断先前的期望状态并避免对工作负载规模进行不必要的更改。 + +例如，在以下示例代码段中，为 `scaleDown` 指定了稳定窗口。 ```yaml -scaleDown: - stabilizationWindowSeconds: 300 +behavior: + scaleDown: + stabilizationWindowSeconds: 300 ``` 当指标显示目标应该缩容时，自动扩缩算法查看之前计算的期望状态，并使用指定时间间隔内的最大值。 在上面的例子中，过去 5 分钟的所有期望状态都会被考虑。 + +这近似于滚动最大值，并避免了扩缩算法频繁删除 Pod 而又触发重新创建等效 Pod。 + -### 示例：更改缩容稳定窗口 +### 示例：更改缩容稳定窗口 {#example-change-downscale-stabilization-window} 将下面的 behavior 配置添加到 HPA 中，可提供一个 1 分钟的自定义缩容稳定窗口： @@ -850,7 +821,7 @@ behavior: To limit the rate at which pods are removed by the HPA to 10% per minute, the following behavior would be added to the HPA: --> -### 示例：限制缩容速率 +### 示例：限制缩容速率 {#example-limit-scale-down-rate} 将下面的 behavior 配置添加到 HPA 中，可限制 Pod 被 HPA 删除速率为每分钟 10%： @@ -868,8 +839,7 @@ To ensure that no more than 5 Pods are removed per minute, you can add a second policy with a fixed size of 5, and set `selectPolicy` to minimum. Setting `selectPolicy` to `Min` means that the autoscaler chooses the policy that affects the smallest number of Pods: --> -为了确保每分钟删除的 Pod 数不超过 5 个，可以添加第二个缩容策略，大小固定为 5， -并将 `selectPolicy` 设置为最小值。 +为了确保每分钟删除的 Pod 数不超过 5 个，可以添加第二个缩容策略，大小固定为 5，并将 `selectPolicy` 设置为最小值。 将 `selectPolicy` 设置为 `Min` 意味着 autoscaler 会选择影响 Pod 数量最小的策略: ```yaml @@ -892,7 +862,7 @@ The `selectPolicy` value of `Disabled` turns off scaling the given direction. So to prevent downscaling the following policy would be used: --> -### 示例：禁用缩容 +### 示例：禁用缩容 {#example-disable-scale-down} `selectPolicy` 的值 `Disabled` 会关闭对给定方向的缩容。 因此使用以下策略，将会阻止缩容： @@ -902,6 +872,30 @@ behavior: scaleDown: selectPolicy: Disabled ``` + +## kubectl 对 HorizontalPodAutoscaler 的支持 {#support-for-horizontalpodautoscaler-in-kubectl} + +与每个 API 资源一样，HorizontalPodAutoscaler 都被 `kubectl` 以标准方式支持。 +你可以使用 `kubectl create` 命令创建一个新的自动扩缩器。 +你可以通过 `kubectl get hpa` 列出自动扩缩器或通过 `kubectl describe hpa` 获取详细描述。 +最后，你可以使用 `kubectl delete hpa` 删除自动扩缩器。 + + +此外，还有一个特殊的 `kubectl autoscale` 命令用于创建 HorizontalPodAutoscaler 对象。 +例如，执行 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` +将为 ReplicaSet *foo* 创建一个自动扩缩器，目标 CPU 利用率设置为 `80%`，副本数在 2 到 5 之间。 -## 隐式维护状态禁用 +## 隐式维护状态禁用 {#implicit-maintenance-mode-deactivation} 你可以在不必更改 HPA 配置的情况下隐式地为某个目标禁用 HPA。 如果此目标的期望副本个数被设置为 0，而 HPA 的最小副本个数大于 0， 则 HPA 会停止调整目标（并将其自身的 `ScalingActive` 状况设置为 `false`）， 直到你通过手动调整目标的期望副本个数或 HPA 的最小副本个数来重新激活。 + + +### 将 Deployment 和 StatefulSet 迁移到水平自动扩缩 {#migrating-deployments-and-statefulsets-to-horizontal-autoscaling} + +当启用 HPA 时，建议从它们的{{< glossary_tooltip text="清单" term_id="manifest" >}}中 +删除 Deployment 和/或 StatefulSet 的 `spec.replicas` 的值。 +如果不这样做，则只要应用对该对象的更改，例如通过 `kubectl apply -f deployment.yaml`， +这将指示 Kubernetes 将当前 Pod 数量扩缩到 `spec.replicas` 键的值。这可能不是所希望的， +并且当 HPA 处于活动状态时可能会很麻烦。 + + +请记住，删除 `spec.replicas` 可能会导致 Pod 计数一次性降级，因为此键的默认值为 1 +（参考 [Deployment Replicas](/zh/docs/concepts/workloads/controllers/deployment#replicas)）。 +更新后，除 1 之外的所有 Pod 都将开始其终止程序。之后的任何部署应用程序都将正常运行， +并根据需要遵守滚动更新配置。你可以根据修改部署的方式选择以下两种方法之一来避免这种降级： + +{{< tabs name="fix_replicas_instructions" >}} +{{% tab name="客户端 apply 操作（默认行为）" %}} + + +1. `kubectl apply edit-last-applied deployment/` +2. 在编辑器中，删除 `spec.replicas`。当你保存并退出编辑器时，`kubectl` 会应用更新。 + 在此步骤中不会更改 Pod 计数。 +3. 你现在可以从清单中删除 `spec.replicas`。如果你使用源代码管理， + 还应提交你的更改或采取任何其他步骤来修改源代码，以适应你如何跟踪更新。 +4. 从这里开始，你可以运行 `kubectl apply -f deployment.yaml` + +{{% /tab %}} +{{% tab name="服务器端 apply 操作" %}} + + +使用[服务器端 Apply](/zh/docs/reference/using-api/server-side-apply/) 机制， +你可以遵循[交出所有权](/zh/docs/reference/using-api/server-side-apply/#transferring-ownership) 说明， +该指南涵盖了这个确切的用例。 + +{{% /tab %}} +{{< /tabs >}} ## {{% heading "whatsnext" %}} -* 设计文档：[Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md) -* `kubectl autoscale` 命令：[kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale). -* 使用示例：[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/). +如果你在集群中配置自动扩缩，你可能还需要考虑运行集群级别的自动扩缩器， +例如 [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)。 + +有关 HorizontalPodAutoscaler 的更多信息： + + +* 阅读水平 Pod 自动扩缩的[演练示例](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)。 +* 阅读 [`kubectl autoscale`](/zh/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 的文档。 +* 如果你想编写自己的自定义指标适配器， + 请查看 [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) 以开始使用。 +* 阅读 [API 参考](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/)。