Merge pull request #32964 from 0xff-dev/main

[zh] sync horizontal-pod-autoscale.md

content/zh/docs/tasks/run-application/horizontal-pod-autoscale.md

@@ -12,61 +12,97 @@ weight: 90
 <!-- overview -->
 
 <!--
-The Horizontal Pod Autoscaler automatically scales the number of Pods
-in a replication controller, deployment, replica set or stateful set based on observed CPU utilization (or, with
-[custom metrics](https://git.k8s.io/community/contributors/design-proposals/instrumentation/custom-metrics-api.md)
-support, on some other application-provided metrics). Note that Horizontal
-Pod Autoscaling does not apply to objects that can't be scaled, for example, DaemonSets.
+In Kubernetes, a _HorizontalPodAutoscaler_ automatically updates a workload resource (such as
+a {{< glossary_tooltip text="Deployment" term_id="deployment" >}} or
+{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}), with the
+aim of automatically scaling the workload to match demand.
 -->
-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" >}}），
+目的是自动扩缩工作负载以满足需求。
 
 <!--
-The Horizontal Pod Autoscaler is implemented as a Kubernetes API resource and a controller.
-The resource determines the behavior of the controller.
-The controller periodically adjusts the number of replicas in a replication controller or deployment
-to match the observed metrics such as average CPU utilisation, average memory utilisation or any other custom metric to the target specified by the user.
+Horizontal scaling means that the response to increased load is to deploy more
+{{< glossary_tooltip text="Pods" term_id="pod" >}}.
+This is different from _vertical_ scaling, which for Kubernetes would mean
+assigning more resources (for example: memory or CPU) to the Pods that are already
+running for the workload.
+
+If the load decreases, and the number of Pods is above the configured minimum,
+the HorizontalPodAutoscaler instructs the workload resource (the Deployment, StatefulSet,
+or other similar resource) to scale back down.
 -->
-Pod 水平自动扩缩特性由 Kubernetes API 资源和控制器实现。资源决定了控制器的行为。
-控制器会周期性地调整副本控制器或 Deployment 中的副本数量，以使得类似 Pod 平均 CPU
-利用率、平均内存利用率这类观测到的度量值与用户所设定的目标值匹配。
+水平扩缩意味着对增加的负载的响应是部署更多的 {{< glossary_tooltip text="Pods" term_id="pod" >}}。
+这与 “垂直（Vertical）” 扩缩不同，对于 Kubernetes，
+垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod。
+
+如果负载减少，并且 Pod 的数量高于配置的最小值，
+HorizontalPodAutoscaler 会指示工作负载资源（ Deployment、StatefulSet 或其他类似资源）缩减。
+
+<!--
+Horizontal pod autoscaling does not apply to objects that can't be scaled (for example:
+a {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}.)
+-->
+水平 Pod 自动扩缩不适用于无法扩缩的对象（例如：{{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}。）
+
+<!--
+The HorizontalPodAutoscaler is implemented as a Kubernetes API resource and a
+{{< glossary_tooltip text="controller" term_id="controller" >}}.
+The resource determines the behavior of the controller.
+The horizontal pod autoscaling controller, running within the Kubernetes
+{{< glossary_tooltip text="control plane" term_id="control-plane" >}}, periodically adjusts the
+desired scale of its target (for example, a Deployment) to match observed metrics such as average
+CPU utilization, average memory utilization, or any other custom metric you specify.
+ -->
+HorizontalPodAutoscaler 被实现为 Kubernetes API 资源和{{< glossary_tooltip text="控制器" term_id="controller" >}}。
+
+资源决定了控制器的行为。在 Kubernetes {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}内运行的水平
+Pod 自动扩缩控制器会定期调整其目标（例如：Deployment）的所需规模，以匹配观察到的指标，
+例如，平均 CPU 利用率、平均内存利用率或你指定的任何其他自定义指标。
+
+<!--
+There is [walkthrough example](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) of using
+horizontal pod autoscaling.
+-->
+使用水平 Pod 自动扩缩[演练示例](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)。
 
 <!-- body -->
 
 <!--
-## How does the Horizontal Pod Autoscaler work?
+## How does a HorizontalPodAutoscaler work?
 -->
-## 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">}}
 
 <!--
-The Horizontal Pod Autoscaler is implemented as a control loop, with a period controlled
-by the controller manager's `--horizontal-pod-autoscaler-sync-period` flag (with a default
-value of 15 seconds).
+Kubernetes implements horizontal pod autoscaling as a control loop that runs intermittently
+(it is not a continuous process). The interval is set by the
+`--horizontal-pod-autoscaler-sync-period` parameter to the
+[`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)
+(and the default interval is 15 seconds).
 -->
-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 秒）。
 
 <!--
-During each period, the controller manager queries the resource utilization against the
-metrics specified in each HorizontalPodAutoscaler definition.  The controller manager
-obtains the metrics from either the resource metrics API (for per-pod resource metrics),
+Once during each period, the controller manager queries the resource utilization against the
+metrics specified in each HorizontalPodAutoscaler definition.  The controller manager 
+finds the target resource defined by the `scaleTargetRef`,
+then selects the pods based on the target resource's `.spec.selector` labels, and obtains the metrics from either the resource metrics API (for per-pod resource metrics),
 or the custom metrics API (for all other metrics).
 -->
-每个周期内，控制器管理器根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。
-控制器管理器可以从资源度量指标 API（按 Pod 统计的资源用量）和自定义度量指标
-API（其他指标）获取度量值。
+在每个时间段内，控制器管理器都会根据每个 HorizontalPodAutoscaler 定义中指定的指标查询资源利用率。
+控制器管理器找到由 `scaleTargetRef` 定义的目标资源，然后根据目标资源的 `.spec.selector` 标签选择 Pod，
+并从资源指标 API（针对每个 Pod 的资源指标）或自定义指标获取指标 API（适用于所有其他指标）。
 
 <!--
 * For per-pod resource metrics (like CPU), the controller fetches the metrics
   from the resource metrics API for each Pod targeted by the HorizontalPodAutoscaler.
   Then, if a target utilization value is set, the controller calculates the utilization
-  value as a percentage of the equivalent resource request on the containers in
+  value as a percentage of the equivalent [resource request](/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) on the containers in
   each Pod.  If a target raw value is set, the raw metric values are used directly.
   The controller then takes the mean of the utilization or the raw value (depending on the type
   of target specified) across all targeted Pods, and produces a ratio used to scale
@@ -74,8 +110,8 @@ API（其他指标）获取度量值。
 -->
 * 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个
   HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率，
-  控制器获取每个 Pod 中的容器资源使用情况，并计算资源使用率。
-  如果设置了 target 值，将直接使用原始数据（不再计算百分比）。
+  控制器获取每个 Pod 中的容器[资源使用](/zh/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) 情况，
+  并计算资源使用率。如果设置了 target 值，将直接使用原始数据（不再计算百分比）。
   接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。
 
   <!--
@@ -107,41 +143,34 @@ API（其他指标）获取度量值。
   在 `autoscaling/v2beta2` 版本 API 中，这个指标也可以根据 Pod 数量平分后再计算。
 
 <!--
-The HorizontalPodAutoscaler normally fetches metrics from a series of aggregated APIs (`metrics.k8s.io`,
-`custom.metrics.k8s.io`, and `external.metrics.k8s.io`).  The `metrics.k8s.io` API is usually provided by
-metrics-server, which needs to be launched separately. See
-[metrics-server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)
-for instructions. The HorizontalPodAutoscaler can also fetch metrics directly from Heapster.
+The common use for HorizontalPodAutoscaler is to configure it to fetch metrics from
+{{< glossary_tooltip text="aggregated APIs" term_id="aggregation-layer" >}}
+(`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`).  The `metrics.k8s.io` API is
+usually provided by an add-on named Metrics Server, which needs to be launched separately.
+For more information about resource metrics, see
+[Metrics Server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server).
 -->
-通常情况下，控制器将从一系列的聚合 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" >}}
-<!--
-Fetching metrics from Heapster is deprecated as of Kubernetes 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)。
 
 <!--
-See [Support for metrics APIs](#support-for-metrics-apis) for more details.
--->
-关于指标 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.
 
-<!--
-The autoscaler accesses corresponding scalable controllers (such as replication controllers, deployments, and replica sets)
-by using the scale sub-resource. Scale is an interface that allows you to dynamically set the number of replicas and examine
-each of their current states. More details on scale sub-resource can be found
-[here](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#scale-subresource).
+The HorizontalPodAutoscaler controller accesses corresponding workload resources that support scaling (such as Deployments
+and StatefulSet). These resources each have a subresource named `scale`, an interface that allows you to dynamically set the
+number of replicas and examine each of their current states.
+For general information about subresources in the Kubernetes API, see
+[Kubernetes API Concepts](/docs/reference/using-api/api-concepts/).
 -->
-自动扩缩控制器使用 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/)。
 
 <!--
 ### Algorithm Details
@@ -166,47 +195,51 @@ desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricVal
 <!--
 For example, if the current metric value is `200m`, and the desired value
 is `100m`, the number of replicas will be doubled, since `200.0 / 100.0 ==
-2.0` If the current value is instead `50m`, we'll halve the number of
-replicas, since `50.0 / 100.0 == 0.5`.  We'll skip scaling if the ratio is
-sufficiently close to 1.0 (within a globally-configurable tolerance, from
-the `--horizontal-pod-autoscaler-tolerance` flag, which defaults to 0.1).
+2.0` If the current value is instead `50m`, you'll halve the number of
+replicas, since `50.0 / 100.0 == 0.5`.  The control plane skips any scaling
+action if the ratio is sufficiently close to 1.0 (within a globally-configurable
+tolerance, 0.1 by default).
 -->
-例如，当前度量值为 `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），
+则控制平面会跳过扩缩操作。
 
 <!--
 When a `targetAverageValue` or `targetAverageUtilization` is specified,
 the `currentMetricValue` is computed by taking the average of the given
 metric across all Pods in the HorizontalPodAutoscaler's scale target.
-Before checking the tolerance and deciding on the final values, we take
-pod readiness and missing metrics into consideration, however.
+
+Before checking the tolerance and deciding on the final values, the control
+plane also considers whether any metrics are missing, and how many Pods
+are [`Ready`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions).
 -->
 如果 HorizontalPodAutoscaler 指定的是 `targetAverageValue` 或 `targetAverageUtilization`，
 那么将会把指定 Pod 度量值的平均值做为 `currentMetricValue`。
-然而，在检查容忍度和决定最终扩缩值前，我们仍然会把那些无法获取指标的 Pod 统计进去。
+
+在检查容差并决定最终值之前，控制平面还会考虑是否缺少任何指标，
+以及有多少 Pod [`已就绪`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)。
 
 <!--
-All Pods with a deletion timestamp set (i.e. Pods in the process of being
-shut down) and all failed Pods are discarded.
+All Pods with a deletion timestamp set (objects with a deletion timestamp are
+in the process of being shut down / removed) are ignored, and all failed Pods
+are discarded.
 
 If a particular Pod is missing metrics, it is set aside for later; Pods
 with missing metrics will be used to adjust the final scaling amount.
 -->
-所有被标记了删除时间戳（Pod 正在关闭过程中）的 Pod 和失败的 Pod 都会被忽略。
+所有设置了删除时间戳的 Pod（带有删除时间戳的对象正在关闭/移除的过程中）都会被忽略，
+所有失败的 Pod 都会被丢弃。
 
 如果某个 Pod 缺失度量值，它将会被搁置，只在最终确定扩缩数量时再考虑。
 
 <!--
-When scaling on CPU, if any pod has yet to become ready (i.e. it's still
-initializing) *or* the most recent metric point for the pod was before it
+When scaling on CPU, if any pod has yet to become ready (it's still
+initializing, or possibly is unhealthy) *or* the most recent metric point for the pod was before it
 became ready, that pod is set aside as well.
 -->
-当使用 CPU 指标来扩缩时，任何还未就绪（例如还在初始化）状态的 Pod *或* 最近的指标
-度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。
+当使用 CPU 指标来扩缩时，任何还未就绪（还在初始化，或者可能是不健康的）状态的 Pod **或** 
+最近的指标度量值采集于就绪状态前的 Pod，该 Pod 也会被搁置。
 
 <!--
 Due to technical constraints, the HorizontalPodAutoscaler controller
@@ -220,13 +253,11 @@ ready to be the first if it occurred within a longer, configurable time
 since it started. This value is configured with the `--horizontal-pod-autoscaler-cpu-initialization-period` flag, and its
 default is 5 minutes.
 -->
-由于受技术限制，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 分钟。
 
 <!--
 The `currentMetricValue / desiredMetricValue` base scale ratio is then
@@ -236,34 +267,33 @@ calculated using the remaining pods not set aside or discarded from above.
 计算出来。
 
 <!--
-If there were any missing metrics, we recompute the average more
+If there were any missing metrics, the control plane recomputes the average more
 conservatively, assuming those pods were consuming 100% of the desired
 value in case of a scale down, and 0% in case of a scale up.  This dampens
 the magnitude of any potential scale.
 -->
-如果缺失任何的度量值，我们会更保守地重新计算平均值，
-在需要缩小时假设这些 Pod 消耗了目标值的 100%，
-在需要放大时假设这些 Pod 消耗了 0% 目标值。
-这可以在一定程度上抑制扩缩的幅度。
+如果缺失某些度量值，控制平面会更保守地重新计算平均值，在需要缩小时假设这些 Pod 消耗了目标值的 100%，
+在需要放大时假设这些 Pod 消耗了 0% 目标值。这可以在一定程度上抑制扩缩的幅度。
 
 <!--
-Furthermore, if any not-yet-ready pods were present, and we would have
-scaled up without factoring in missing metrics or not-yet-ready pods, we
-conservatively assume the not-yet-ready pods are consuming 0% of the
-desired metric, further dampening the magnitude of a scale up.
+Furthermore, if any not-yet-ready pods were present, and the workload would have
+scaled up without factoring in missing metrics or not-yet-ready pods,
+the controller conservatively assumes that the not-yet-ready pods are consuming 0%
+of the desired metric, further dampening the magnitude of a scale up.
 -->
-此外，如果存在任何尚未就绪的 Pod，我们可以在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩，
-我们保守地假设尚未就绪的 Pod 消耗了期望指标的 0%，从而进一步降低了扩缩的幅度。
+此外，如果存在任何尚未就绪的 Pod，工作负载会在不考虑遗漏指标或尚未就绪的 Pod 的情况下进行扩缩，
+控制器保守地假设尚未就绪的 Pod 消耗了期望指标的 0%，从而进一步降低了扩缩的幅度。
 
 <!--
-After factoring in the not-yet-ready pods and missing metrics, we
-recalculate the usage ratio.  If the new ratio reverses the scale
-direction, or is within the tolerance, we skip scaling.  Otherwise, we use
-the new ratio to scale.
+After factoring in the not-yet-ready pods and missing metrics, the
+controller recalculates the usage ratio.  If the new ratio reverses the scale
+direction, or is within the tolerance, the controller doesn't take any scaling
+action. In other cases, the new ratio is used to decide any change to the
+number of Pods.
 -->
-在扩缩方向（缩小或放大）确定后，我们会把未就绪的 Pod 和缺少指标的 Pod 考虑进来再次计算使用率。
-如果新的比率与扩缩方向相反，或者在容忍范围内，则跳过扩缩。
-否则，我们使用新的扩缩比例。
+考虑到尚未准备好的 Pod 和缺失的指标后，控制器会重新计算使用率。
+如果新的比率与扩缩方向相反，或者在容差范围内，则控制器不会执行任何扩缩操作。
+在其他情况下，新比率用于决定对 Pod 数量的任何更改。
 
 <!--
 Note that the *original* value for the average utilization is reported
@@ -271,8 +301,8 @@ back via the HorizontalPodAutoscaler status, without factoring in the
 not-yet-ready pods or missing metrics, even when the new usage ratio is
 used.
 -->
-注意，平均利用率的*原始*值会通过 HorizontalPodAutoscaler 的状态体现（
-即使使用了新的使用率，也不考虑未就绪 Pod 和 缺少指标的 Pod)。
+注意，平均利用率的 **原始** 值是通过 HorizontalPodAutoscaler 状态体现的，
+而不考虑尚未准备好的 Pod 或缺少的指标，即使使用新的使用率也是如此。
 
 <!--
 If multiple metrics are specified in a HorizontalPodAutoscaler, this
@@ -307,62 +337,42 @@ fluctuating metric values.
 <!--
 ## API Object
 
-The Horizontal Pod Autoscaler is an API resource in the Kubernetes `autoscaling` API group.
-The current stable version, which only includes support for CPU autoscaling,
-can be found in the `autoscaling/v1` API version.
+The Horizontal Pod Autoscaler is an API resource in the Kubernetes
+`autoscaling` API group.  The current stable version can be found in
+the `autoscaling/v2` API version which includes support for scaling on
+memory and custom metrics. The new fields introduced in
+`autoscaling/v2` are preserved as annotations when working with
+`autoscaling/v1`.
 -->
 ## API 对象   {#api-object}
 
-HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组的资源。
-在当前稳定版本（`autoscaling/v1`）中只支持基于 CPU 指标的扩缩。
-
-<!--
-The beta version, which includes support for scaling on memory and custom metrics,
-can be found in `autoscaling/v2beta2`. The new fields introduced in `autoscaling/v2beta2`
-are preserved as annotations when working with `autoscaling/v1`.
--->
-API 的 beta 版本（`autoscaling/v2beta2`）引入了基于内存和自定义指标的扩缩。
-在 `autoscaling/v2beta2` 版本中新引入的字段在 `autoscaling/v1` 版本中以注解
-的形式得以保留。
+HorizontalPodAutoscaler 是 Kubernetes `autoscaling` API 组中的 API 资源。
+当前的稳定版本可以在 `autoscaling/v2` API 版本中找到，其中包括对基于内存和自定义指标执行扩缩的支持。
+在使用 `autoscaling/v1` 时，`autoscaling/v2` 中引入的新字段作为注释保留。
 
 <!--
 When you create a HorizontalPodAutoscaler API object, make sure the name specified is a valid
 [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
 More details about the API object can be found at
-[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling).
+[HorizontalPodAutoscaler Object](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling).
 -->
 创建 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)。
 
 <!--
-## Support for Horizontal Pod Autoscaler in kubectl
+## Stability of workload scale {#flapping}
 
-Horizontal Pod Autoscaler, like every API resource, is supported in a standard way by `kubectl`.
-We can create a new autoscaler using `kubectl create` command.
-We can list autoscalers by `kubectl get hpa` and get detailed description by `kubectl describe hpa`.
-Finally, we can delete an autoscaler using `kubectl delete hpa`.
+When managing the scale of a group of replicas using the HorizontalPodAutoscaler,
+it is possible that the number of replicas keeps fluctuating frequently due to the
+dynamic nature of the metrics evaluated. This is sometimes referred to as *thrashing*,
+or *flapping*. It's similar to the concept of *hysteresis* in cybernetics.
 -->
-## kubectl 对 Horizontal Pod Autoscaler 的支持
+## 工作量规模的稳定性 {#flapping}
 
-与其他 API 资源类似，`kubectl` 以标准方式支持 HPA。
-我们可以通过 `kubectl create` 命令创建一个 HPA 对象，
-通过 `kubectl get hpa` 命令来获取所有 HPA 对象，
-通过 `kubectl describe hpa` 命令来查看 HPA 对象的详细信息。
-最后，可以使用 `kubectl delete hpa` 命令删除对象。
-
-<!--
-In addition, there is a special `kubectl autoscale` command for creating a HorizontalPodAutoscaler.
-For instance, executing `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
-will create an autoscaler for replication set *foo*, with target CPU utilization set to `80%`
-and the number of replicas between 2 and 5.
-The detailed documentation of `kubectl autoscale` can be found [here](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
--->
-此外，还有个简便的命令 `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）** 概念。
 
 <!--
 ## Autoscaling during rolling update
@@ -391,56 +401,6 @@ similar to ReplicaSet).
 如果你对一个副本个数被自动扩缩的 StatefulSet 执行滚动更新， 该 StatefulSet
 会直接管理它的 Pod 集合 （不存在类似 ReplicaSet 这样的中间资源）。
 
-<!--
-## Support for cooldown/delay
-
-When managing the scale of a group of replicas using the Horizontal Pod Autoscaler,
-it is possible that the number of replicas keeps fluctuating frequently due to the
-dynamic nature of the metrics evaluated. This is sometimes referred to as *thrashing*.
--->
-## 冷却/延迟支持
-
-当使用 Horizontal Pod Autoscaler 管理一组副本扩缩时，
-有可能因为指标动态的变化造成副本数量频繁的变化，有时这被称为
-*抖动（Thrashing）*。
-
-<!--
-Starting from v1.6, a cluster operator can mitigate this problem by tuning
-the global HPA settings exposed as flags for the `kube-controller-manager` component:
--->
-从 v1.6 版本起，集群操作员可以调节某些 `kube-controller-manager` 的全局参数来
-缓解这个问题。
-
-<!--
-Starting from v1.12, a new algorithmic update removes the need for the
-upscale delay.
--->
-从 v1.12 开始，算法调整后，扩容操作时的延迟就不必设置了。
-
-<!--
-- `--horizontal-pod-autoscaler-downscale-stabilization`: Specifies the duration of the
-  downscale stabilization time window. Horizontal Pod Autoscaler remembers
-  this historical recommended sizes and only acts on the largest size within this time window.
-  The default value is 5 minutes (`5m0s`).
--->
-- `--horizontal-pod-autoscaler-downscale-stabilization`: 设置缩容冷却时间窗口长度。
-  水平 Pod
-扩缩器能够记住过去建议的负载规模，并仅对此时间窗口内的最大规模执行操作。
-  默认值是 5 分钟（`5m0s`）。
-
-<!--
-When tuning these parameter values, a cluster operator should be aware of the possible
-consequences. If the delay (cooldown) value is set too long, there could be complaints
-that the Horizontal Pod Autoscaler is not responsive to workload changes. However, if
-the delay value is set too short, the scale of the replicas set may keep thrashing as
-usual.
--->
-{{< note >}}
-当调整这些参数时，集群操作员需要明白其可能的影响。
-如果延迟（冷却）时间设置的太长，Horizontal Pod Autoscaler 可能会不能很好的改变负载。
-如果延迟（冷却）时间设置的太短，那么副本数量有可能跟以前一样出现抖动。
-{{< /note >}}
-
 <!--
 ## Support for resource metrics
 
@@ -497,15 +457,15 @@ pod usage is still within acceptable limits.
 {{< feature-state for_k8s_version="v1.20" state="alpha" >}}
 
 <!--
-`HorizontalPodAutoscaler` also supports a container metric source where the HPA can track the
+The HorizontalPodAutoscaler API also supports a container metric source where the HPA can track the
 resource usage of individual containers across a set of Pods, in order to scale the target resource.
 This lets you configure scaling thresholds for the containers that matter most in a particular Pod.
 For example, if you have a web application and a logging sidecar, you can scale based on the resource
 use of the web application, ignoring the sidecar container and its resource use.
 -->
-`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
+## Scaling on custom metrics
 
-Kubernetes 1.6 adds support for scaling based on multiple metrics. You can use the `autoscaling/v2beta2` API
-version to specify multiple metrics for the Horizontal Pod Autoscaler to scale on. Then, the Horizontal Pod
-Autoscaler controller will evaluate each metric, and propose a new scale based on that metric. The largest of the
-proposed scales will be used as the new scale.
--->
-## 多指标支持   {#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
-
-Kubernetes 1.2 added alpha support for scaling based on application-specific metrics using special annotations.
-Support for these annotations was removed in Kubernetes 1.6 in favor of the new autoscaling API.  While the old method for collecting
-custom metrics is still available, these metrics will not be available for use by the Horizontal Pod Autoscaler, and the former
-annotations for specifying which custom metrics to scale on are no longer honored by the Horizontal Pod Autoscaler controller.
--->
-## 自定义指标支持   {#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 adds support for making use of custom metrics in the Horizontal Pod Autoscaler.
-You can add custom metrics for the Horizontal Pod Autoscaler to use in the `autoscaling/v2beta2` API.
-Kubernetes then queries the new custom metrics API to fetch the values of the appropriate custom metrics.
--->
-自 Kubernetes 1.6 起，Horizontal Pod Autoscaler 支持使用自定义指标。
-你可以使用 `autoscaling/v2beta2` API 为 Horizontal Pod Autoscaler 指定用户自定义指标。
-Kubernetes 会通过用户自定义指标 API 来获取相应的指标。
-
-<!--
 See [Support for metrics APIs](#support-for-metrics-apis) for the requirements.
 -->
-关于指标 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
+
+(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature)
+
+Provided that you use the `autoscaling/v2` API version, you can specify multiple metrics for a
+HorizontalPodAutoscaler to scale on. Then, the HorizontalPodAutoscaler controller evaluates each metric,
+and proposes a new scale based on that metric. The HorizontalPodAutoscaler takes the maximum scale
+recommended for each metric and sets the workload to that size (provided that this isn't larger than the
+overall maximum that you configured).
+-->
+## 基于多个指标来执行扩缩 {#scaling-on-multiple-metrics}
+
+{{< feature-state for_k8s_version="v1.23" state="stable" >}}
+
+（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
+
+如果你使用 `autoscaling/v2` API 版本，你可以为 HorizontalPodAutoscaler 指定多个指标以进行扩缩。
+HorizontalPodAutoscaler 控制器评估每个指标，并根据该指标提出一个新的比例。
+HorizontalPodAutoscaler 采用为每个指标推荐的最大比例，
+并将工作负载设置为该大小（前提是这不大于你配置的总体最大值）。
 
 <!--
 ## Support for metrics APIs
@@ -629,12 +588,9 @@ APIs, cluster administrators must ensure that:
      It can be launched as a cluster addon.
 
    * For custom metrics, this is the `custom.metrics.k8s.io` API.  It's provided by "adapter" API servers provided by metrics solution vendors.
-     Check with your metrics pipeline, or the [list of known solutions](https://github.com/kubernetes/metrics/blob/master/IMPLEMENTATIONS.md#custom-metrics-api).
-     If you would like to write your own, check out the [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) to get started.
+     Check with your metrics pipeline to see if there is a Kubernetes metrics adapter available.
 
    * For external metrics, this is the `external.metrics.k8s.io` API.  It may be provided by the custom metrics adapters provided above.
-
-* The `--horizontal-pod-autoscaler-use-rest-clients` is `true` or unset.  Setting this to false switches to Heapster-based autoscaling, which is deprecated.
 -->
 * 启用了 [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 的自动扩缩，这个特性已经被弃用了。
-
 <!--  
 For more information on these different metrics paths and how they differ please see the relevant design proposals for
-[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)
-and [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md).
+[the 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)
+and [external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md).
 -->
 关于指标来源以及其区别的更多信息，请参阅相关的设计文档，
-[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)。
 
 <!--
 For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
@@ -673,24 +625,34 @@ and [the walkthrough for using external metrics](/docs/tasks/run-application/hor
 和[使用外部指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。
 
 <!--  
-## Support for configurable scaling behavior
+## Configurable scaling behavior
 
-Starting from
-[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
-the `v2beta2` API allows scaling behavior to be configured through the HPA
-`behavior` field. Behaviors are specified separately for scaling up and down in
-`scaleUp` or `scaleDown` section under the `behavior` field. A stabilization
-window can be specified for both directions which prevents the flapping of the
-number of the replicas in the scaling target. Similarly specifying scaling
-policies controls the rate of change of replicas while scaling.
+(the `autoscaling/v2beta2` API version previously provided this ability as a beta feature)
+
+If you use the `v2` HorizontalPodAutoscaler API, you can use the `behavior` field
+(see the [API reference](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec))
+to configure separate scale-up and scale-down behaviors.
+You specify these behaviours by setting `scaleUp` and / or `scaleDown`
+under the `behavior` field.
 -->
-## 支持可配置的扩缩 {#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` 来指定这些行为。
+
+<!--
+You can specify a _stabilization window_ that prevents [flapping](#flapping)
+the replica count for a scaling target. Scaling policies also let you controls the
+rate of change of replicas while scaling.
+-->
+
+你可以指定一个 “稳定窗口” ，以防止扩缩目标的副本计数发生[波动](#flapping)。
+扩缩策略还允许你在扩缩时控制副本的变化率。
 
 <!--  
 ### Scaling Policies
@@ -701,9 +663,8 @@ change is the policy which is selected by default. The following example shows t
 while scaling down:
 -->
 ### 扩缩策略 {#scaling-policies}
-在 spec 字段的 `behavior` 部分可以指定一个或多个扩缩策略。
-当指定多个策略时，默认选择允许更改最多的策略。
-下面的例子展示了缩容时的行为:
+可以在规约的 `behavior` 部分中指定一个或多个扩缩策略。当指定多个策略时，
+允许最大更改量的策略是默认选择的策略。以下示例显示了缩小时的这种行为：
 
 ```yaml
 behavior:
@@ -750,35 +711,45 @@ scaling in that direction.
 -->
 可以指定扩缩方向的 `selectPolicy` 字段来更改策略选择。
 通过设置 `Min` 的值，它将选择副本数变化最小的策略。
-将该值设置为 `Disabled` 将完全禁用该方向的缩放。
+将该值设置为 `Disabled` 将完全禁用该方向的扩缩。
 
 <!--  
 ### Stabilization Window
 
-The stabilization window is used to restrict the flapping of replicas when the metrics
-used for scaling keep fluctuating. The stabilization window is used by the autoscaling
-algorithm to consider the computed desired state from the past to prevent scaling. In
-the following example the stabilization window is specified for `scaleDown`.
+The stabilization window is used to restrict the [flapping](#flapping) of
+replicas count when the metrics used for scaling keep fluctuating. The autoscaling algorithm
+uses this window to infer a previous desired state and avoid unwanted changes to workload
+scale.
+
+For example, in the following example snippet, a stabilization window is specified for `scaleDown`.
 -->
 ### 稳定窗口 {#stabilization-window}
 
-当用于扩缩的指标持续抖动时，使用稳定窗口来限制副本数上下振动。
-自动扩缩算法使用稳定窗口来考虑过去计算的期望状态，以防止扩缩。
-在下面的例子中，稳定化窗口被指定为 `scaleDown`。
+当用于扩缩的指标不断波动时，稳定窗口用于限制副本计数的[波动](#flapping)。
+自动扩缩算法使用此窗口来推断先前的期望状态并避免对工作负载规模进行不必要的更改。
+
+例如，在以下示例代码段中，为 `scaleDown` 指定了稳定窗口。
 
 ```yaml
-scaleDown:
-  stabilizationWindowSeconds: 300
+behavior:
+  scaleDown:
+    stabilizationWindowSeconds: 300
 ```
 
 <!--  
 When the metrics indicate that the target should be scaled down the algorithm looks
-into previously computed desired states and uses the highest value from the specified
-interval. In above example all desired states from the past 5 minutes will be considered.
+into previously computed desired states, and uses the highest value from the specified
+interval. In the above example, all desired states from the past 5 minutes will be considered.
 -->
 当指标显示目标应该缩容时，自动扩缩算法查看之前计算的期望状态，并使用指定时间间隔内的最大值。
 在上面的例子中，过去 5 分钟的所有期望状态都会被考虑。
 
+<!--
+This approximates a rolling maximum, and avoids having the scaling algorithm frequently
+remove Pods only to trigger recreating an equivalent Pod just moments later.
+-->
+这近似于滚动最大值，并避免了扩缩算法频繁删除 Pod 而又触发重新创建等效 Pod。
+
 <!--  
 ### Default Behavior
 
@@ -834,7 +805,7 @@ running replicas will be added every 15 seconds till the HPA reaches its steady
 To provide a custom downscale stabilization window of 1 minute, the following
 behavior would be added to the HPA:
 --> 
-### 示例：更改缩容稳定窗口
+### 示例：更改缩容稳定窗口 {#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
 ```
+<!--
+## Support for HorizontalPodAutoscaler in kubectl
+
+HorizontalPodAutoscaler, like every API resource, is supported in a standard way by `kubectl`.
+You can create a new autoscaler using `kubectl create` command.
+You can list autoscalers by `kubectl get hpa` or get detailed description by `kubectl describe hpa`.
+Finally, you can delete an autoscaler using `kubectl delete hpa`.
+-->
+## kubectl 对 HorizontalPodAutoscaler 的支持 {#support-for-horizontalpodautoscaler-in-kubectl}
+
+与每个 API 资源一样，HorizontalPodAutoscaler 都被 `kubectl` 以标准方式支持。
+你可以使用 `kubectl create` 命令创建一个新的自动扩缩器。
+你可以通过 `kubectl get hpa` 列出自动扩缩器或通过 `kubectl describe hpa` 获取详细描述。
+最后，你可以使用 `kubectl delete hpa` 删除自动扩缩器。
+
+<!--
+In addition, there is a special `kubectl autoscale` command for creating a HorizontalPodAutoscaler object.
+For instance, executing `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80`
+will create an autoscaler for ReplicaSet *foo*, with target CPU utilization set to `80%`
+and the number of replicas between 2 and 5.
+-->
+此外，还有一个特殊的 `kubectl autoscale` 命令用于创建 HorizontalPodAutoscaler 对象。
+例如，执行 `kubectl autoscale rs foo --min=2 --max=5 --cpu-percent=80` 
+将为 ReplicaSet *foo* 创建一个自动扩缩器，目标 CPU 利用率设置为 `80%`，副本数在 2 到 5 之间。
 
 <!--
 ## Implicit maintenance-mode deactivation
@@ -913,20 +907,102 @@ stops adjusting the target (and sets the `ScalingActive` Condition on itself
 to `false`) until you reactivate it by manually adjusting the target's desired
 replica count or HPA's minimum replica count.
 -->
-## 隐式维护状态禁用
+## 隐式维护状态禁用 {#implicit-maintenance-mode-deactivation}
 
 你可以在不必更改 HPA 配置的情况下隐式地为某个目标禁用 HPA。
 如果此目标的期望副本个数被设置为 0，而 HPA 的最小副本个数大于 0，
 则 HPA 会停止调整目标（并将其自身的 `ScalingActive` 状况设置为 `false`），
 直到你通过手动调整目标的期望副本个数或 HPA 的最小副本个数来重新激活。
 
+<!--
+### Migrating Deployments and StatefulSets to horizontal autoscaling
+
+When an HPA is enabled, it is recommended that the value of `spec.replicas` of
+the Deployment and / or StatefulSet be removed from their
+{{< glossary_tooltip text="manifest(s)" term_id="manifest" >}}.  If this isn't done, any time
+a change to that object is applied, for example via `kubectl apply -f
+deployment.yaml`, this will instruct Kubernetes to scale the current number of Pods
+to the value of the `spec.replicas` key. This may not be
+desired and could be troublesome when an HPA is active.
+-->
+
+### 将 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 处于活动状态时可能会很麻烦。
+
+<!--
+Keep in mind that the removal of `spec.replicas` may incur a one-time
+degradation of Pod counts as the default value of this key is 1 (reference
+[Deployment Replicas](/docs/concepts/workloads/controllers/deployment#replicas)).
+Upon the update, all Pods except 1 will begin their termination procedures.  Any
+deployment application afterwards will behave as normal and respect a rolling
+update configuration as desired.  You can avoid this degradation by choosing one of the following two
+methods based on how you are modifying your deployments:
+-->
+请记住，删除 `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/<deployment_name>`
+2. In the editor, remove `spec.replicas`. When you save and exit the editor, `kubectl`
+    applies the update.  No changes to Pod counts happen at this step.
+3. You can now remove `spec.replicas` from the manifest. If you use source code management,
+    also commit your changes or take whatever other steps for revising the source code
+    are appropriate for how you track updates.
+4. From here on out you can run `kubectl apply -f deployment.yaml`
+-->
+1. `kubectl apply edit-last-applied deployment/<Deployment 名称>`
+2. 在编辑器中，删除 `spec.replicas`。当你保存并退出编辑器时，`kubectl` 会应用更新。
+  在此步骤中不会更改 Pod 计数。
+3. 你现在可以从清单中删除 `spec.replicas`。如果你使用源代码管理，
+  还应提交你的更改或采取任何其他步骤来修改源代码，以适应你如何跟踪更新。
+4. 从这里开始，你可以运行 `kubectl apply -f deployment.yaml`
+
+{{% /tab %}}
+{{% tab name="服务器端 apply 操作" %}}
+
+<!--
+When using the [Server-Side Apply](/docs/reference/using-api/server-side-apply/)
+you can follow the [transferring ownership](/docs/reference/using-api/server-side-apply/#transferring-ownership)
+guidelines, which cover this exact use case.
+-->
+使用[服务器端 Apply](/zh/docs/reference/using-api/server-side-apply/) 机制，
+你可以遵循[交出所有权](/zh/docs/reference/using-api/server-side-apply/#transferring-ownership) 说明，
+该指南涵盖了这个确切的用例。
+
+{{% /tab %}}
+{{< /tabs >}}
 ## {{% heading "whatsnext" %}}
 
 <!--
-* Design documentation: [Horizontal Pod Autoscaling](https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md).
-* kubectl autoscale command: [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
-* Usage example of [Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/).
+If you configure autoscaling in your cluster, you may also want to consider running a
+cluster-level autoscaler such as [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler).
+
+For more information on HorizontalPodAutoscaler:
 -->
-* 设计文档：[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 的更多信息：
+
+<!--
+* Read a [walkthrough example](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/) for horizontal pod autoscaling.
+* Read documentation for [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale).
+* If you would like to write your own custom metrics adapter, check out the
+  [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) to get started.
+* Read the [API reference](/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/) for 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/)。