Merge pull request #51079 from my-git9/npa-15846

[zh-cn]sync horizontal-pod-autoscale.md

Author: k8s-ci-robot

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

@@ -164,6 +164,7 @@ or the custom metrics API (for all other metrics).
   not take any action for that metric. See the [algorithm details](#algorithm-details) section below
   for more information about how the autoscaling algorithm works.
   -->
+
   需要注意的是，如果 Pod 某些容器不支持资源采集，那么控制器将不会使用该 Pod 的 CPU 使用率。
   下面的[算法细节](#algorithm-details)章节将会介绍详细的算法。
 
@@ -306,7 +307,7 @@ default is 5 minutes.
 相反，如果 Pod 未准备好并在其启动后的一个可配置的短时间窗口内转换为准备好，它会认为 Pod “尚未准备好”。
 该值使用 `--horizontal-pod-autoscaler-initial-readiness-delay` 标志配置，默认值为 30 秒。
 一旦 Pod 准备就绪，如果它发生在自启动后较长的、可配置的时间内，它就会认为任何向准备就绪的转换都是第一个。
-该值由 `-horizontal-pod-autoscaler-cpu-initialization-period` 标志配置，默认为 5 分钟。
+该值由 `--horizontal-pod-autoscaler-cpu-initialization-period` 标志配置，默认为 5 分钟。
 
 <!--
 The \\( currentMetricValue \over desiredMetricValue \\) base scale ratio is then
@@ -384,6 +385,85 @@ fluctuating metric values.
 默认值为 5 分钟。
 这个配置可以让系统更为平滑地进行缩容操作，从而消除短时间内指标值快速波动产生的影响。
 
+<!--
+### Pod readiness and autoscaling metrics
+
+The HorizontalPodAutoscaler (HPA) controller includes two flags that influence how CPU metrics are collected from Pods during startup:
+-->
+### Pod 准备就绪和自动伸缩指标
+
+HorizontalPodAutoscaler（HPA）控制器有两个标志会影响 Pod 启动期间如何收集其 CPU 指标：
+
+<!--
+1. `--horizontal-pod-autoscaler-cpu-initialization-period` (default: 5 minutes)
+
+  This defines the time window after a Pod starts during which its **CPU usage is ignored** unless:
+    - The Pod is in a `Ready` state **and**
+    - The metric sample was taken entirely during the period it was `Ready`.
+-->
+1. `--horizontal-pod-autoscaler-cpu-initialization-period`（默认：5 分钟）
+
+   此标志所定义的是 Pod 启动后的一个时间窗口，在此期间内其 **CPU 使用率被忽略**，除非：
+     - Pod 处于 `Ready` 状态**且**
+     - 指标样本完全是在它处于 `Ready` 状态期间采集的。
+
+   <!--
+   This flag helps **exclude misleading high CPU usage** from initializing Pods (e.g., Java apps warming up) in HPA scaling decisions.
+   -->
+
+   此标志有助于**排除初始化 Pod 中的误导性高 CPU 使用率**
+   （例如，Java 应用程序预热）对 HPA 扩缩决策的影响。
+
+<!--
+2. `--horizontal-pod-autoscaler-initial-readiness-delay` (default: 30 seconds)
+
+  This defines a short delay period after a Pod starts during which the HPA controller treats Pods that are currently `Unready` as still initializing, **even if they have previously transitioned to `Ready` briefly**.
+-->
+2. `--horizontal-pod-autoscaler-initial-readiness-delay`（默认：30 秒）
+
+   这定义了一个短暂的延迟期，在 Pod 启动后，HPA 控制器将当前为 `Unready`
+   的 Pod 视为仍在初始化中，**即使它们之前曾短暂转变为 `Ready`**。
+
+   <!--
+   It is designed to:
+   - Avoid including Pods that rapidly fluctuate between `Ready` and `Unready` during startup.
+   - Ensure stability in the initial readiness signal before HPA considers their metrics valid.
+   -->
+   其设计目的是：
+   - 避免包含在启动期间快速在 `Ready` 和 `Unready` 之间波动的 Pod。
+   - 确保在 HPA 认为它们的指标有效之前，初始就绪信号的稳定性。
+
+<!--
+**Key behaviors:**
+- If a Pod is `Ready` and remains `Ready`, it can be counted as contributing metrics even within the delay.
+- If a Pod rapidly toggles between `Ready` and `Unready`, metrics are ignored until it’s considered stably `Ready`.
+-->
+**关键行为：**
+
+- 如果一个 Pod 是 `Ready` 状态并且保持 `Ready`，即使在延迟期间，
+  它也可以被视为贡献指标。
+- 如果一个 Pod 在 `Ready` 和 `Unready` 之间快速切换，那么它的指标将被忽略，
+  直到它被认为稳定在 `Ready` 状态。
+
+<!--
+#### Best Practice:
+If your Pod has a startup phase with high CPU usage, configure both:
+- `--horizontal-pod-autoscaler-cpu-initialization-period` to **cover the startup duration**.
+- Ensure your **readinessProbe** only reports `Ready` **after the CPU spike subsides**, using `initialDelaySeconds`.
+-->
+#### 最佳实践
+
+如果你的 Pod 有一个 CPU 使用率较高的启动阶段，可以配置以下两项：
+
+- `--horizontal-pod-autoscaler-cpu-initialization-period`
+  以**覆盖启动持续时间**。
+- 通过使用 `initialDelaySeconds`，确保你的 **readinessProbe** 在 CPU 峰值消退后才报告 `Ready`。
+
+<!--
+This avoids scaling based on temporary spikes that do not reflect long-term workload needs.
+-->
+这样做可以避免基于临时峰值的缩放动作，这些峰值不反映长时间工作负载需求。
+
 <!--
 ## API Object
 
@@ -483,7 +563,7 @@ target at 60%. Utilization is the ratio between the current usage of resource to
 resources of the pod. See [Algorithm](#algorithm-details) for more details about how the utilization
 is calculated and averaged.
 -->
-基于这一指标设定，HPA 控制器会维持扩缩目标中的 Pods 的平均资源利用率在 60%。
+基于这一指标设定，HPA 控制器会维持扩缩目标中的 Pod 的平均资源利用率在 60%。
 利用率是 Pod 的当前资源用量与其请求值之间的比值。
 关于如何计算利用率以及如何计算平均值的细节可参考[算法](#algorithm-details)小节。
 
@@ -590,7 +670,7 @@ See [Support for metrics APIs](#support-for-metrics-apis) for the requirements.
 
 {{< feature-state for_k8s_version="v1.23" state="stable" >}}
 
-（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
+（之前的 `autoscaling/v2beta2` API 版本将此功能作为 Beta 功能提供）
 
 如果你使用 `autoscaling/v2` API 版本，则可以将 HorizontalPodAutoscaler
 配置为基于自定义指标（未内置于 Kubernetes 或任何 Kubernetes 组件）进行扩缩。
@@ -615,7 +695,7 @@ overall maximum that you configured).
 
 {{< feature-state for_k8s_version="v1.23" state="stable" >}}
 
-（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
+（之前的 `autoscaling/v2beta2` API 版本将此功能作为 Beta 功能提供）
 
 如果你使用 `autoscaling/v2` API 版本，你可以为 HorizontalPodAutoscaler 指定多个指标以进行扩缩。
 HorizontalPodAutoscaler 控制器评估每个指标，并根据该指标提出一个新的比例。
@@ -701,7 +781,7 @@ under the `behavior` field.
 
 {{< feature-state for_k8s_version="v1.23" state="stable" >}}
 
-（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
+（之前的 `autoscaling/v2beta2` API 版本将此功能作为 Beta 功能提供）
 
 如果你使用 `v2` HorizontalPodAutoscaler API，你可以使用 `behavior` 字段
 （请参阅 [API 参考](/zh-cn/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec)）
@@ -748,7 +828,13 @@ behavior:
 The maximum value that you can set for `periodSeconds` is 1800 (half an hour).
 The first policy _(Pods)_ allows at most 4 replicas to be scaled down in one minute. The second policy
 _(Percent)_ allows at most 10% of the current replicas to be scaled down in one minute.
+-->
+`periodSeconds` 表示在过去的多长时间内要求策略值为真。
+你可以设置 `periodSeconds` 的最大值为 1800（半小时）。
+第一个策略（Pods）允许在一分钟内最多缩容 4 个副本。第二个策略（Percent）
+允许在一分钟内最多缩容当前副本个数的百分之十。
 
+<!--
 Since by default the policy which allows the highest amount of change is selected, the second policy will
 only be used when the number of pod replicas is more than 40. With 40 or less replicas, the first policy will be applied.
 For instance if there are 80 replicas and the target has to be scaled down to 10 replicas
@@ -758,11 +844,6 @@ the autoscaler controller the number of pods to be change is re-calculated based
 of current replicas. When the number of replicas falls below 40 the first policy _(Pods)_ is applied
 and 4 replicas will be reduced at a time.
 -->
-`periodSeconds` 表示在过去的多长时间内要求策略值为真。
-你可以设置 `periodSeconds` 的最大值为 1800（半小时）。
-第一个策略（Pods）允许在一分钟内最多缩容 4 个副本。第二个策略（Percent）
-允许在一分钟内最多缩容当前副本个数的百分之十。
-
 由于默认情况下会选择容许更大程度作出变更的策略，只有 Pod 副本数大于 40 时，
 第二个策略才会被采用。如果副本数为 40 或者更少，则应用第一个策略。
 例如，如果有 80 个副本，并且目标必须缩小到 10 个副本，那么在第一步中将减少 8 个副本。
@@ -950,7 +1031,7 @@ policy with a fixed size of 5, and set `selectPolicy` to minimum. Setting `selec
 that the autoscaler chooses the policy that affects the smallest number of Pods:
 -->
 为了确保每分钟删除的 Pod 数不超过 5 个，可以添加第二个缩容策略，大小固定为 5，并将 `selectPolicy` 设置为最小值。
-将 `selectPolicy` 设置为 `Min` 意味着 autoscaler 会选择影响 Pod 数量最小的策略:
+将 `selectPolicy` 设置为 `Min` 意味着 autoscaler 会选择影响 Pod 数量最小的策略：
 
 ```yaml
 behavior: