[zh] sync run-single-instance-stateful-application

zhuzhenghao · zhuzhenghao · commit 12d9b2c315ba · 2023-02-25T23:29:54.000+08:00
diff --git a/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -129,7 +129,7 @@ Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路
 
 <!--
 Once during each period, the controller manager queries the resource utilization against the
-metrics specified in each HorizontalPodAutoscaler definition.  The controller manager 
+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).
@@ -144,7 +144,7 @@ or the custom metrics API (for all other metrics).
   Then, if a target utilization value is set, the controller calculates the utilization
   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.
+  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
   the number of desired replicas.
@@ -184,7 +184,7 @@ or the custom metrics API (for all other metrics).
 <!--
 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
+(`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/debug-cluster/resource-metrics-pipeline/#metrics-server).
@@ -235,7 +235,7 @@ 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`, you'll halve the number of
-replicas, since `50.0 / 100.0 == 0.5`.  The control plane skips any scaling
+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).
 -->
@@ -274,7 +274,7 @@ with missing metrics will be used to adjust the final scaling amount.
 
 <!--
 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
+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 **或**
@@ -287,7 +287,7 @@ determining whether to set aside certain CPU metrics. Instead, it
 considers a Pod "not yet ready" if it's unready and transitioned to
 ready within a short, configurable window of time since it started.
 This value is configured with the `--horizontal-pod-autoscaler-initial-readiness-delay` flag, and its default is 30
-seconds.  Once a pod has become ready, it considers any transition to
+seconds. Once a pod has become ready, it considers any transition to
 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.
@@ -308,7 +308,7 @@ calculated using the remaining pods not set aside or discarded from above.
 <!--
 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
+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%，
@@ -325,7 +325,7 @@ of the desired metric, further dampening the magnitude of a scale up.
 
 <!--
 After factoring in the not-yet-ready pods and missing metrics, the
-controller recalculates the usage ratio.  If the new ratio reverses the scale
+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.
@@ -335,7 +335,7 @@ number of Pods.
 在其他情况下，新比率用于决定对 Pod 数量的任何更改。
 
 <!--
-Note that the *original* value for the average utilization is reported
+Note that the _original_ value for the average utilization is reported
 back via the HorizontalPodAutoscaler status, without factoring in the
 not-yet-ready pods or missing metrics, even when the new usage ratio is
 used.
@@ -360,7 +360,7 @@ the current value.
 这表示，如果一个或多个指标给出的 `desiredReplicas` 值大于当前值，HPA 仍然能实现扩容。
 
 <!--
-Finally, right before HPA scales the target, the scale recommendation is recorded.  The
+Finally, right before HPA scales the target, the scale recommendation is recorded. The
 controller considers all recommendations within a configurable window choosing the
 highest recommendation from within that window. This value can be configured using the `--horizontal-pod-autoscaler-downscale-stabilization` flag, which defaults to 5 minutes.
 This means that scaledowns will occur gradually, smoothing out the impact of rapidly
@@ -377,7 +377,7 @@ fluctuating metric values.
 ## API Object
 
 The Horizontal Pod Autoscaler is an API resource in the Kubernetes
-`autoscaling` API group.  The current stable version can be found in
+`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
@@ -405,8 +405,8 @@ More details about the API object can be found at
 
 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.
+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.
 -->
 ## 工作量规模的稳定性 {#flapping}
 
@@ -614,7 +614,7 @@ HorizontalPodAutoscaler 采用为每个指标推荐的最大比例，
 <!--
 ## Support for metrics APIs
 
-By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs.  In order for it to access these
+By default, the HorizontalPodAutoscaler controller retrieves metrics from a series of APIs. In order for it to access these
 APIs, cluster administrators must ensure that:
 -->
 ## 对 Metrics API 的支持   {#support-for-metrics-apis}
@@ -628,25 +628,25 @@ APIs, cluster administrators must ensure that:
 * The corresponding APIs are registered:
 
    * For resource metrics, this is the `metrics.k8s.io` API, generally provided by [metrics-server](https://github.com/kubernetes-sigs/metrics-server).
-     It can be launched as a cluster add-on.
+    It can be launched as a cluster add-on.
 
    * 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 to see if there is a Kubernetes metrics adapter available.
+    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.
 -->
 * 启用了 [API 聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
 
 * 相应的 API 已注册：
 
-   * 对于资源指标，将使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。
+  * 对于资源指标，将使用 `metrics.k8s.io` API，一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。
      它可以作为集群插件启动。
 
-   * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
+  * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。
      它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。
      检查你的指标管道以查看是否有可用的 Kubernetes 指标适配器。
 
-   * 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。
+  * 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。
 
 <!--
 For more information on these different metrics paths and how they differ please see the relevant design proposals for
@@ -918,6 +918,7 @@ behavior:
   scaleDown:
     selectPolicy: Disabled
 ```
+
 <!--
 ## Support for HorizontalPodAutoscaler in kubectl
 
@@ -936,7 +937,7 @@ Finally, you can delete an autoscaler using `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%`
+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 对象。
@@ -948,7 +949,7 @@ and the number of replicas between 2 and 5.
 
 You can implicitly deactivate the HPA for a target without the
 need to change the HPA configuration itself. If the target's desired replica count
-is set to 0, and the HPA's minimum replica count is greater than 0, the HPA 
+is set to 0, and the HPA's minimum replica count is greater than 0, the HPA
 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.
@@ -965,7 +966,7 @@ replica count or HPA's minimum replica count.
 
 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
+{{< 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
@@ -984,9 +985,9 @@ Deployment 和/或 StatefulSet 的 `spec.replicas` 的值。
 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
+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
+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
@@ -1000,10 +1001,10 @@ methods based on how you are modifying your deployments:
 <!--
 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.
+   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.
+   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 名称>`
@@ -1053,4 +1054,3 @@ For more information on HorizontalPodAutoscaler:
 * 如果你想编写自己的自定义指标适配器，
   请查看 [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) 以开始使用。
 * 阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/)。
-
diff --git a/content/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application.md b/content/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application.md
@@ -36,7 +36,7 @@ application is MySQL.
 <!--
 You can run a stateful application by creating a Kubernetes Deployment
 and connecting it to an existing PersistentVolume using a
-PersistentVolumeClaim.  For example, this YAML file describes a
+PersistentVolumeClaim. For example, this YAML file describes a
 Deployment that runs MySQL and references the PersistentVolumeClaim. The file
 defines a volume mount for /var/lib/mysql, and then creates a
 PersistentVolumeClaim that looks for a 20G volume. This claim is
@@ -60,22 +60,28 @@ for a secure solution.
 {{< codenew file="application/mysql/mysql-deployment.yaml" >}}
 {{< codenew file="application/mysql/mysql-pv.yaml" >}}
 
-1. <!--Deploy the PV and PVC of the YAML file-->
-   部署 YAML 文件中定义的 PV 和 PVC：
+<!--
+1. Deploy the PV and PVC of the YAML file:
+-->
+1. 部署 YAML 文件中定义的 PV 和 PVC：
 
    ```shell
    kubectl apply -f https://k8s.io/examples/application/mysql/mysql-pv.yaml
    ```
 
-1. <!-- Deploy the contents of the YAML file -->
-   部署 YAML 文件中定义的 Deployment：
+<!--
+1. Deploy the contents of the YAML file:
+-->
+2. 部署 YAML 文件中定义的 Deployment：
 
    ```shell
    kubectl apply -f https://k8s.io/examples/application/mysql/mysql-deployment.yaml
    ```
 
-1. <!-- Display information about the Deployment -->
-   展示 Deployment 相关信息:
+<!--
+1. Display information about the Deployment:
+-->
+3. 展示 Deployment 相关信息:
 
    ```shell
    kubectl describe deployment mysql
@@ -111,21 +117,23 @@ for a secure solution.
        Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
        ClaimName:  mysql-pv-claim
        ReadOnly:   false
-       Conditions:
-         Type          Status  Reason
-         ----          ------  ------
-         Available     False   MinimumReplicasUnavailable
-         Progressing   True    ReplicaSetUpdated
-         OldReplicaSets:       <none>
-         NewReplicaSet:        mysql-63082529 (1/1 replicas created)
-         Events:
-           FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
-           ---------    --------    -----    ----                -------------    --------    ------            -------
-           33s          33s         1        {deployment-controller }             Normal      ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
+   Conditions:
+     Type          Status  Reason
+     ----          ------  ------
+     Available     False   MinimumReplicasUnavailable
+     Progressing   True    ReplicaSetUpdated
+   OldReplicaSets:       <none>
+   NewReplicaSet:        mysql-63082529 (1/1 replicas created)
+   Events:
+     FirstSeen    LastSeen    Count    From                SubobjectPath    Type        Reason            Message
+     ---------    --------    -----    ----                -------------    --------    ------            -------
+     33s          33s         1        {deployment-controller }             Normal      ScalingReplicaSet Scaled up replica set mysql-63082529 to 1
    ```
 
-1. <!-- List the pods created by the Deployment -->
-   列举出 Deployment 创建的 pods:
+<!--
+1. List the pods created by the Deployment:
+-->
+4. 列举出 Deployment 创建的 pods:
 
    ```shell
    kubectl get pods -l app=mysql
@@ -141,8 +149,10 @@ for a secure solution.
    mysql-63082529-2z3ki   1/1       Running   0          3m
    ```
 
-1. <!-- Inspect the PersistentVolumeClaim -->
-   查看 PersistentVolumeClaim：
+<!--
+1. Inspect the PersistentVolumeClaim:
+-->
+5. 查看 PersistentVolumeClaim：
 
    ```shell
    kubectl describe pvc mysql-pv-claim
@@ -180,14 +190,13 @@ Run a MySQL client to connect to the server:
 -->
 ## 访问 MySQL 实例   {#accessing-the-mysql-instance}
 
-
 前面 YAML 文件中创建了一个允许集群内其他 Pod 访问的数据库服务。该服务中选项
 `clusterIP: None` 让服务 DNS 名称直接解析为 Pod 的 IP 地址。
 当在一个服务下只有一个 Pod 并且不打算增加 Pod 的数量这是最好的.
 
 运行 MySQL 客户端以连接到服务器:
 
-```
+```shell
 kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword
 ```
 
@@ -246,7 +255,7 @@ Delete the deployed objects by name:
 
 通过名称删除部署的对象:
 
-```
+```shell
 kubectl delete deployment,svc mysql
 kubectl delete pvc mysql-pv-claim
 kubectl delete pv mysql-pv-volume
@@ -282,5 +291,3 @@ PersistentVolume 将被自动删除。
 * 参阅 [kubectl run 文档](/docs/reference/generated/kubectl/kubectl-commands/#run)
 
 * 参阅[卷](/zh-cn/docs/concepts/storage/volumes/)和[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)
-
-
