From 6c7c1b80a80c66198e17efcd4e00dac622b432f3 Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Mon, 2 Oct 2023 13:54:55 +0800 Subject: [PATCH] [zh-cn] sync tasks/run-application/* Signed-off-by: xin.li --- .../tasks/run-application/configure-pdb.md | 6 +- .../run-application/delete-stateful-set.md | 4 +- .../force-delete-stateful-set-pod.md | 4 +- .../horizontal-pod-autoscale-walkthrough.md | 4 +- .../horizontal-pod-autoscale.md | 62 +++++++++++-------- .../run-replicated-stateful-application.md | 12 ++-- ...un-single-instance-stateful-application.md | 4 +- .../run-stateless-application-deployment.md | 6 +- .../run-application/scale-stateful-set.md | 2 +- 9 files changed, 57 insertions(+), 47 deletions(-) diff --git a/content/zh-cn/docs/tasks/run-application/configure-pdb.md b/content/zh-cn/docs/tasks/run-application/configure-pdb.md index 76c87c868a..385ef4a20e 100644 --- a/content/zh-cn/docs/tasks/run-application/configure-pdb.md +++ b/content/zh-cn/docs/tasks/run-application/configure-pdb.md @@ -311,14 +311,14 @@ Example PDB Using minAvailable: --> 使用 minAvailable 的 PDB 示例： -{{% code file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" %}} +{{% code_sample file="policy/zookeeper-pod-disruption-budget-minavailable.yaml" %}} 使用 maxUnavailable 的 PDB 示例： -{{% code file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" %}} +{{% code_sample file="policy/zookeeper-pod-disruption-budget-maxunavailable.yaml" %}} -- 只能够使用 `.spec.minAvailable`，而不能够使用 `.spec.maxUnavailable。` +- 只能够使用 `.spec.minAvailable`，而不能够使用 `.spec.maxUnavailable`。 - 只能够使用整数作为 `.spec.minAvailable` 的值，而不能使用百分比。 -删除 StatefulSet 之后，你可能需要单独删除关联的无头服务。 +删除 StatefulSet 之后，你可能需要单独删除关联的无头服务（Headless Service）。 ```shell -kubectl delete service <服务名称> +kubectl delete service ``` ## 删除 Pod {#delete-pods} -你可以使用下面的命令执行体面地删除 Pod: +你可以使用下面的命令执行体面地删除 Pod： ```shell kubectl delete pods @@ -187,7 +187,7 @@ kubectl delete pods --grace-period=0 If even after these commands the pod is stuck on `Unknown` state, use the following command to remove the pod from the cluster: --> -如果在执行这些命令后 Pod 仍处于 `Unknown` 状态，请使用以下命令从集群中删除 Pod: +如果在执行这些命令后 Pod 仍处于 `Unknown` 状态，请使用以下命令从集群中删除 Pod： ```shell kubectl patch pod -p '{"metadata":{"finalizers":null}}' diff --git a/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md index 9398388183..ccfc0a7a44 100644 --- a/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md +++ b/content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md @@ -104,7 +104,7 @@ using the following manifest: 为了演示 HorizontalPodAutoscaler，你将首先启动一个 Deployment 用 `hpa-example` 镜像运行一个容器， 然后使用以下清单文件将其暴露为一个 {{< glossary_tooltip term_id="service">}}： -{{% code file="application/php-apache.yaml" %}} +{{% code_sample file="application/php-apache.yaml" %}} 除了使用 `kubectl autoscale` 命令，也可以使用以下清单以声明方式创建 HorizontalPodAutoscaler： -{{% code file="application/hpa/php-apache.yaml" %}} +{{% code_sample file="application/hpa/php-apache.yaml" %}} 水平扩缩意味着对增加的负载的响应是部署更多的 {{< glossary_tooltip text="Pod" term_id="pod" >}}。 -这与 “垂直（Vertical）” 扩缩不同，对于 Kubernetes， +这与“垂直（Vertical）”扩缩不同，对于 Kubernetes， 垂直扩缩意味着将更多资源（例如：内存或 CPU）分配给已经为工作负载运行的 Pod。 如果负载减少，并且 Pod 的数量高于配置的最小值， @@ -131,7 +131,8 @@ Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路 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), +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 定义中指定的指标查询资源利用率。 @@ -277,8 +278,8 @@ 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 也会被搁置。 由于技术限制，HorizontalPodAutoscaler 控制器在确定是否保留某些 CPU 指标时无法准确确定 Pod 首次就绪的时间。 @@ -340,7 +343,7 @@ 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 状态体现的， +注意，平均利用率的**原始**值是通过 HorizontalPodAutoscaler 状态体现的， 而不考虑尚未准备好的 Pod 或缺少的指标，即使使用新的使用率也是如此。 @@ -439,7 +443,7 @@ replicas, the StatefulSet directly manages its set of Pods (there is no intermed similar to ReplicaSet). --> 如果你对一个副本个数被自动扩缩的 StatefulSet 执行滚动更新，该 StatefulSet -会直接管理它的 Pod 集合 （不存在类似 ReplicaSet 这样的中间资源）。 +会直接管理它的 Pod 集合（不存在类似 ReplicaSet 这样的中间资源）。 ## 对资源指标的支持 {#support-for-resource-metrics} -HPA 的任何目标资源都可以基于其中的 Pods 的资源用量来实现扩缩。 +HPA 的任何目标资源都可以基于其中的 Pod 的资源用量来实现扩缩。 在定义 Pod 规约时，类似 `cpu` 和 `memory` 这类资源请求必须被设定。 这些设定值被用来确定资源利用量并被 HPA 控制器用来对目标资源完成扩缩操作。 要使用基于资源利用率的扩缩，可以像下面这样指定一个指标源： @@ -614,8 +618,8 @@ HorizontalPodAutoscaler 采用为每个指标推荐的最大比例， ## 对 Metrics API 的支持 {#support-for-metrics-apis} @@ -627,26 +631,31 @@ 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. + * For resource metrics, this is the `metrics.k8s.io` [API](/docs/reference/external-api/metrics.v1beta1/), + generally provided by [metrics-server](https://github.com/kubernetes-sigs/metrics-server). + 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. + * For custom metrics, this is the `custom.metrics.k8s.io` [API](/docs/reference/external-api/metrics.v1beta1/). + 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. - * For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above. + * For external metrics, this is the `external.metrics.k8s.io` [API](/docs/reference/external-api/metrics.v1beta1/). + 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](/zh-cn/docs/reference/external-api/metrics.v1beta1/)， + 一般由 [metrics-server](https://github.com/kubernetes-incubator/metrics-server) 提供。 + 它可以作为集群插件启动。 - * 对于自定义指标，将使用 `custom.metrics.k8s.io` API。 - 它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。 - 检查你的指标管道以查看是否有可用的 Kubernetes 指标适配器。 + * 对于自定义指标，将使用 `custom.metrics.k8s.io` [API](/zh-cn/docs/reference/external-api/metrics.v1beta1/)。 + 它由其他度量指标方案厂商的“适配器（Adapter）” API 服务器提供。 + 检查你的指标管道以查看是否有可用的 Kubernetes 指标适配器。 - * 对于外部指标，将使用 `external.metrics.k8s.io` API。可能由上面的自定义指标适配器提供。 + * 对于外部指标，将使用 `external.metrics.k8s.io` [API](/zh-cn/docs/reference/external-api/metrics.v1beta1/)。 + 可能由上面的自定义指标适配器提供。 关于如何使用它们的示例， @@ -696,7 +706,7 @@ the replica count for a scaling target. Scaling policies also let you control th rate of change of replicas while scaling. --> -你可以指定一个 “稳定窗口”，以防止扩缩目标的副本计数发生[波动](#flapping)。 +你可以指定一个“稳定窗口”，以防止扩缩目标的副本计数发生[波动](#flapping)。 扩缩策略还允许你在扩缩时控制副本的变化率。 此外，控制器为每个 Pod 分配一个唯一、稳定的名称，形如 `-<序数索引>`， -其结果是 Pods 名为 `mysql-0`、`mysql-1` 和 `mysql-2`。 +其结果是 Pod 名为 `mysql-0`、`mysql-1` 和 `mysql-2`。 -现在去掉节点保护（Uncordon），使其恢复为正常模式: +现在去掉节点保护（Uncordon），使其恢复为正常模式： ```shell kubectl uncordon <节点名称> 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 index 05652227c9..deeec47dff 100644 --- 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 @@ -58,8 +58,8 @@ for a secure solution. 注意：在配置的 YAML 文件中定义密码的做法是不安全的。具体安全解决方案请参考 [Kubernetes Secrets](/zh-cn/docs/concepts/configuration/secret/)。 -{{% code file="application/mysql/mysql-deployment.yaml" %}} -{{% code file="application/mysql/mysql-pv.yaml" %}} +{{% code_sample file="application/mysql/mysql-deployment.yaml" %}} +{{% code_sample file="application/mysql/mysql-pv.yaml" %}} -- 进一步了解[删除 StatefulSet](/zh-cn/docs/tasks/run-application/delete-stateful-set/) +- 进一步了解[删除 StatefulSet](/zh-cn/docs/tasks/run-application/delete-stateful-set/)。