whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[zh]Update tasks pages(part-6) for links with '/zh/' prefix, using new prefix '/zh-cn/'

Browse Source
This commit is contained in:
howieyuen
2022-06-23 20:05:55 +08:00
parent e0d6f94bf6
commit 0b113f23aa
29 changed files with 128 additions and 128 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh-cn/docs/tasks/run-application/access-api-from-pod.md
+4 -4
View File
@@ -40,7 +40,7 @@ one of the official [client libraries](/docs/reference/using-api/client-librarie
libraries can automatically discover the API server and authenticate.
-->
从 Pod 使用 Kubernetes API 的最简单的方法就是使用官方的
[客户端库](/zh/docs/reference/using-api/client-libraries/)。
[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)。
这些库可以自动发现 API 服务器并进行身份验证。
<!--
@@ -73,7 +73,7 @@ securely with the API server.
函数 `config.load_incluster_config()` 自动处理 API 主机的发现和身份认证。
参见[这里的一个例子](https://github.com/kubernetes-client/python/blob/master/examples/in_cluster_config.py)。
- 还有一些其他可用的客户端库，请参阅[客户端库](/zh/docs/reference/using-api/client-libraries/)页面。
- 还有一些其他可用的客户端库，请参阅[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)页面。
在以上场景中，客户端库都使用 Pod 的服务账号凭据来与 API 服务器安全地通信。
@@ -100,7 +100,7 @@ service account is placed into the filesystem tree of each container in that Pod
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
-->
向 API 服务器进行身份认证的推荐做法是使用
[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)凭据。
[服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)凭据。
默认情况下，每个 Pod 与一个服务账号关联，该服务账户的凭证（令牌）放置在此 Pod 中
每个容器的文件系统树中的 `/var/run/secrets/kubernetes.io/serviceaccount/token` 处。
@@ -132,7 +132,7 @@ in the Pod can use it directly.
#### 使用 kubectl proxy {#use-kubectl-proxy}
如果你希望不使用官方客户端库就完成 API 查询，可以将 `kubectl proxy` 作为
[command](/zh/docs/tasks/inject-data-application/define-command-argument-container/)
[command](/zh-cn/docs/tasks/inject-data-application/define-command-argument-container/)
在 Pod 中启动一个边车（Sidecar）容器。这样，`kubectl proxy` 自动完成对 API
的身份认证，并将其暴露到 Pod 的 `localhost` 接口，从而 Pod 中的其他容器可以
直接使用 API。
content/zh-cn/docs/tasks/run-application/configure-pdb.md
+4 -4
View File
@@ -37,9 +37,9 @@ nodes.
Pod Disruption Budgets.
-->
* 你是 Kubernetes 集群中某应用的所有者，该应用有高可用要求。
* 你应了解如何部署[无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
和/或[有状态应用](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。
* 你应当已经阅读过关于 [Pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) 的文档。
* 你应了解如何部署[无状态应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)
和/或[有状态应用](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)。
* 你应当已经阅读过关于 [Pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/) 的文档。
* 用户应当与集群所有者或服务提供者确认其遵从 Pod 干扰预算（Pod Disruption Budgets）的规则。
<!-- steps -->
@@ -87,7 +87,7 @@ selector goes into the PDBs `.spec.selector`.
From version 1.15 PDBs support custom controllers where the [scale subresource](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource) is enabled.
-->
从 1.15 版本开始，PDB 支持启用
[scale 子资源](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)
[scale 子资源](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)
的自定义控制器。
<!--
content/zh-cn/docs/tasks/run-application/delete-stateful-set.md
+3 -3
View File
@@ -97,7 +97,7 @@ Deleting the Pods in a StatefulSet will not delete the associated volumes. This
### 持久卷 {#persistent-volumes}
删除 StatefulSet 管理的 Pod 并不会删除关联的卷。这是为了确保你有机会在删除卷之前从卷中复制数据。
在 Pod 离开[终止状态](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
在 Pod 离开[终止状态](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)
后删除 PVC 可能会触发删除背后的 PV 持久卷，具体取决于存储类和回收策略。
永远不要假定在 PVC 删除后仍然能够访问卷。
@@ -140,13 +140,13 @@ If you find that some pods in your StatefulSet are stuck in the 'Terminating' or
如果你发现 StatefulSet 的某些 Pod 长时间处于 'Terminating' 或者 'Unknown' 状态，
则可能需要手动干预以强制从 API 服务器中删除这些 Pod。
这是一项有点危险的任务。详细信息请阅读
[删除 StatefulSet 类型的 Pods](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)。
[删除 StatefulSet 类型的 Pods](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/)。
## {{% heading "whatsnext" %}}
<!--
Learn more about [force deleting StatefulSet Pods](/docs/tasks/run-application/force-delete-stateful-set-pod/).
-->
进一步了解[强制删除 StatefulSet 的 Pods](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)。
进一步了解[强制删除 StatefulSet 的 Pods](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/)。
content/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod.md
+5 -5
View File
@@ -41,7 +41,7 @@ In normal operation of a StatefulSet, there is **never** a need to force delete
## StatefulSet 注意事项
在 StatefulSet 的正常操作中，**永远不**需要强制删除 StatefulSet 管理的 Pod。
[StatefulSet 控制器](/zh/docs/concepts/workloads/controllers/statefulset/)负责创建、
[StatefulSet 控制器](/zh-cn/docs/concepts/workloads/controllers/statefulset/)负责创建、
扩缩和删除 StatefulSet 管理的 Pods。它尝试确保指定数量的从序数 0 到 N-1 的 Pod
处于活跃状态并准备就绪。StatefulSet 确保在任何时候，集群中最多只有一个具有给定标识的 Pod。
这就是所谓的由 StatefulSet 提供的*最多一个（At Most One）*的语义。
@@ -73,7 +73,7 @@ For the above to lead to graceful termination, the Pod **must not** specify a `p
为了让上面操作能够体面地终止 Pod，Pod **一定不能** 设置 `pod.Spec.TerminationGracePeriodSeconds` 为 0。
将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0s 的做法是不安全的，强烈建议 StatefulSet 类型的
Pod 不要使用。体面删除是安全的，并且会在 kubelet 从 API 服务器中删除资源名称之前确保
[体面地结束 pod ](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
[体面地结束 pod ](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。
<!--
A Pod is not deleted automatically when a Node is unreachable.
@@ -85,7 +85,7 @@ The only ways in which a Pod in such a state can be removed from the apiserver a
-->
当某个节点不可达时，不会引发自动删除 Pod。
在无法访问的节点上运行的 Pod 在
[超时](/zh/docs/concepts/architecture/nodes/#condition)
[超时](/zh-cn/docs/concepts/architecture/nodes/#condition)
后会进入'Terminating' 或者 'Unknown' 状态。
当用户尝试体面地删除无法访问的节点上的 Pod 时 Pod 也可能会进入这些状态。
从 API 服务器上删除处于这些状态 Pod 的仅有可行方法如下：
@@ -95,7 +95,7 @@ The only ways in which a Pod in such a state can be removed from the apiserver a
* The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver.<br/>
* Force deletion of the Pod by the user.
-->
* 删除 Node 对象（要么你来删除, 要么[节点控制器](/zh/docs/concepts/architecture/nodes/#node-controller)
* 删除 Node 对象（要么你来删除, 要么[节点控制器](/zh-cn/docs/concepts/architecture/nodes/#node-controller)
来删除）
* 无响应节点上的 kubelet 开始响应，杀死 Pod 并从 API 服务器上移除 Pod 对象
* 用户强制删除 pod
@@ -171,6 +171,6 @@ Always perform force deletion of StatefulSet Pods carefully and with complete kn
<!--
Learn more about [debugging a StatefulSet](/docs/tasks/debug/debug-application/debug-statefulset/).
-->
进一步了解[调试 StatefulSet](/zh/docs/tasks/debug/debug-application/debug-statefulset/)。
进一步了解[调试 StatefulSet](/zh-cn/docs/tasks/debug/debug-application/debug-statefulset/)。
content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+5 -5
View File
@@ -32,7 +32,7 @@ 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.
-->
[HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) （简称 HPA ）
[HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) （简称 HPA ）
自动更新工作负载资源（例如 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或者
{{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}}），
目的是自动扩缩工作负载以满足需求。
@@ -66,7 +66,7 @@ release of Kubernetes, refer to the version of the documentation for that releas
[available documentation versions](/docs/home/supported-doc-versions/)).
-->
如果你运行的是旧版本的 Kubernetes，请参阅该版本的文档版本
（[可用的文档版本](/zh/docs/home/supported-doc-versions/)）。
（[可用的文档版本](/zh-cn/docs/home/supported-doc-versions/)）。
<!--
To follow this walkthrough, you also need to use a cluster that has a
@@ -83,8 +83,8 @@ To learn how to deploy the Metrics Server, see the
按照本演练进行操作，你需要一个部署并配置了
[Metrics Server](https://github.com/kubernetes-sigs/metrics-server#readme) 的集群。
Kubernetes Metrics Server 从集群中的 {{<glossary_tooltip term_id="kubelet" text="kubelets">}} 收集资源指标，
并通过 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) 公开这些指标，
使用 [APIService](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 添加代表指标读数的新资源。
并通过 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/) 公开这些指标，
使用 [APIService](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 添加代表指标读数的新资源。
要了解如何部署 Metrics Server，请参阅
[metrics-server 文档](https://github.com/kubernetes-sigs/metrics-server#deployment)。
@@ -188,7 +188,7 @@ Deployment 然后更新 ReplicaSet —— 这是所有 Deployment 在 Kubernetes
由于每个 Pod 通过 `kubectl run` 请求 200 milli-cores，这意味着平均 CPU 使用率为 100 milli-cores。
有关算法的更多详细信息，
请参阅[算法详细信息](/zh/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)。
请参阅[算法详细信息](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details)。
<!-- Create the HorizontalPodAutoscaler: -->
content/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale.md
+15 -15
View File
@@ -65,7 +65,7 @@ Pod 自动扩缩控制器会定期调整其目标（例如：Deployment）的所
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/)。
使用水平 Pod 自动扩缩[演练示例](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)。
<!-- body -->
@@ -84,7 +84,7 @@ Kubernetes implements horizontal pod autoscaling as a control loop that runs int
(and the default interval is 15 seconds).
-->
Kubernetes 将水平 Pod 自动扩缩实现为一个间歇运行的控制回路（它不是一个连续的过程）。间隔由
[`kube-controller-manager`](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
[`kube-controller-manager`](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
的 `--horizontal-pod-autoscaler-sync-period` 参数设置（默认间隔为 15 秒）。
<!--
@@ -110,7 +110,7 @@ or the custom metrics API (for all other metrics).
-->
* 对于按 Pod 统计的资源指标（如 CPU），控制器从资源指标 API 中获取每一个
HorizontalPodAutoscaler 指定的 Pod 的度量值，如果设置了目标使用率，
控制器获取每个 Pod 中的容器[资源使用](/zh/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) 情况，
控制器获取每个 Pod 中的容器[资源使用](/zh-cn/docs/concepts/configuration/manage-resources-containers/#requests-and-limits) 情况，
并计算资源使用率。如果设置了 target 值，将直接使用原始数据（不再计算百分比）。
接下来，控制器根据平均的资源使用率或原始值计算出扩缩的比例，进而计算出目标副本数。
@@ -153,7 +153,7 @@ For more information about resource metrics, see
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/debug-cluster/resource-metrics-pipeline/#metrics-server)。
请参阅 [Metrics Server](/zh-cn/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server)。
<!--
[Support for metrics APIs](#support-for-metrics-apis) explains the stability guarantees and support status for these
@@ -170,7 +170,7 @@ For general information about subresources in the Kubernetes API, see
HorizontalPodAutoscaler 控制器访问支持扩缩的相应工作负载资源（例如：Deployments 和 StatefulSet）。
这些资源每个都有一个名为 `scale` 的子资源，该接口允许你动态设置副本的数量并检查它们的每个当前状态。
有关 Kubernetes API 子资源的一般信息，
请参阅 [Kubernetes API 概念](/zh/docs/reference/using-api/api-concepts/)。
请参阅 [Kubernetes API 概念](/zh-cn/docs/reference/using-api/api-concepts/)。
<!--
### Algorithm Details
@@ -218,7 +218,7 @@ are [`Ready`](/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions).
那么将会把指定 Pod 度量值的平均值做为 `currentMetricValue`。
在检查容差并决定最终值之前，控制平面还会考虑是否缺少任何指标，
以及有多少 Pod [`已就绪`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)。
以及有多少 Pod [`已就绪`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)。
<!--
All Pods with a deletion timestamp set (objects with a deletion timestamp are
@@ -357,7 +357,7 @@ More details about the API object can be found at
[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)。
[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
有关 API 对象的更多信息，请查阅
[HorizontalPodAutoscaler 对象设计文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v2-autoscaling)。
@@ -592,7 +592,7 @@ APIs, cluster administrators must ensure that:
* For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above.
-->
* 启用了 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
* 启用了 [API 聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
* 相应的 API 已注册：
@@ -621,8 +621,8 @@ For examples of how to use them see [the walkthrough for using custom metrics](/
and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects).
-->
关于如何使用它们的示例，请参考
[使用自定义指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
和[使用外部指标的教程](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。
[使用自定义指标的教程](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
和[使用外部指标的教程](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects)。
<!--
## Configurable scaling behavior
@@ -642,7 +642,7 @@ under the `behavior` field.
（之前的 `autoscaling/v2beta2` API 版本将此功能作为 beta 功能提供）
如果你使用 `v2` HorizontalPodAutoscaler API，你可以使用 `behavior` 字段
（请参阅 [API 参考](/zh/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec)）
（请参阅 [API 参考](/zh-cn/docs/reference/kubernetes-api/workload-resources/horizontal-pod-autoscaler-v2/#HorizontalPodAutoscalerSpec)）
来配置单独的放大和缩小行为。你可以通过在行为字段下设置 `scaleUp` 和/或 `scaleDown` 来指定这些行为。
<!--
@@ -944,7 +944,7 @@ update configuration as desired. You can avoid this degradation by choosing one
methods based on how you are modifying your deployments:
-->
请记住，删除 `spec.replicas` 可能会导致 Pod 计数一次性降级，因为此键的默认值为 1
（参考 [Deployment Replicas](/zh/docs/concepts/workloads/controllers/deployment#replicas)）。
（参考 [Deployment Replicas](/zh-cn/docs/concepts/workloads/controllers/deployment#replicas)）。
更新后，除 1 之外的所有 Pod 都将开始其终止程序。之后的任何部署应用程序都将正常运行，
并根据需要遵守滚动更新配置。你可以根据修改部署的方式选择以下两种方法之一来避免这种降级：
@@ -975,8 +975,8 @@ 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) 说明，
使用[服务器端 Apply](/zh-cn/docs/reference/using-api/server-side-apply/) 机制，
你可以遵循[交出所有权](/zh-cn/docs/reference/using-api/server-side-apply/#transferring-ownership) 说明，
该指南涵盖了这个确切的用例。
{{% /tab %}}
@@ -1001,7 +1001,7 @@ For more information on HorizontalPodAutoscaler:
[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/)。
* 阅读水平 Pod 自动扩缩的[演练示例](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)。
* 阅读 [`kubectl autoscale`](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 的文档。
* 如果你想编写自己的自定义指标适配器，
请查看 [boilerplate](https://github.com/kubernetes-sigs/custom-metrics-apiserver) 以开始使用。
content/zh-cn/docs/tasks/run-application/run-replicated-stateful-application.md
+13 -13
View File
@@ -25,7 +25,7 @@ This application is a replicated MySQL database. The example topology has a
single primary server and multiple replicas, using asynchronous row-based
replication.
-->
本页展示如何使用 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)
本页展示如何使用 [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)
控制器运行一个有状态的应用程序。此例是多副本的 MySQL 数据库。
示例应用的拓扑结构有一个主服务器和多个副本，使用异步的基于行（Row-Based）
的数据复制。
@@ -58,11 +58,11 @@ on general patterns for running stateful applications in Kubernetes.
* You are using the default namespace or another namespace that does not contain any conflicting objects.
-->
* 本教程假定你熟悉
[PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/)
与 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/),
以及其他核心概念，例如 [Pod](/zh/docs/concepts/workloads/pods/)、
[服务](/zh/docs/concepts/services-networking/service/) 与
[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/).
[PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/)
与 [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/),
以及其他核心概念，例如 [Pod](/zh-cn/docs/concepts/workloads/pods/)、
[服务](/zh-cn/docs/concepts/services-networking/service/) 与
[ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/).
* 熟悉 MySQL 会有所帮助，但是本教程旨在介绍对其他系统应该有用的常规模式。
* 你正在使用默认命名空间或不包含任何冲突对象的另一个命名空间。
@@ -256,7 +256,7 @@ in the order defined.
### 生成配置
在启动 Pod 规约中的任何容器之前，Pod 首先按顺序运行所有的
[Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。
[Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)。
<!--
The first Init Container, named `init-mysql`, generates special MySQL config
@@ -296,7 +296,7 @@ replicating.
因此脚本仅将序数 `0` 指定为主节点，而将其他所有节点指定为副本节点。
与 StatefulSet 控制器的
[部署顺序保证](/zh/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)
[部署顺序保证](/zh-cn/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)
相结合，
可以确保 MySQL 主服务器在创建副本服务器之前已准备就绪，以便它们可以开始复制。
@@ -502,7 +502,7 @@ to make sure the server is up and able to execute queries.
### 破坏就绪态探测
`mysql` 容器的
[就绪态探测](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
[就绪态探测](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes)
运行命令 `mysql -h 127.0.0.1 -e 'SELECT 1'`，以确保服务器已启动并能够执行查询。
<!--
@@ -855,9 +855,9 @@ kubectl delete pvc data-mysql-4
* Look in the [Helm Charts repository](https://artifacthub.io/)
for other stateful application examples.
-->
* 进一步了解[为 StatefulSet 扩缩容](/zh/docs/tasks/run-application/scale-stateful-set/).
* 进一步了解[调试 StatefulSet](/zh/docs/tasks/debug/debug-application/debug-statefulset/).
* 进一步了解[删除 StatefulSet](/zh/docs/tasks/run-application/delete-stateful-set/).
* 进一步了解[强制删除 StatefulSet Pods](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/).
* 进一步了解[为 StatefulSet 扩缩容](/zh-cn/docs/tasks/run-application/scale-stateful-set/).
* 进一步了解[调试 StatefulSet](/zh-cn/docs/tasks/debug/debug-application/debug-statefulset/).
* 进一步了解[删除 StatefulSet](/zh-cn/docs/tasks/run-application/delete-stateful-set/).
* 进一步了解[强制删除 StatefulSet Pods](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/).
* 在 [Helm Charts 仓库](https://artifacthub.io/)中查找其他有状态的应用程序示例。
content/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application.md
+5 -5
View File
@@ -55,7 +55,7 @@ Note: The password is defined in the config yaml, and this is insecure. See
for a secure solution.
-->
注意：在配置的 YAML 文件中定义密码的做法是不安全的。具体安全解决方案请参考
[Kubernetes Secrets](/zh/docs/concepts/configuration/secret/).
[Kubernetes Secrets](/zh-cn/docs/concepts/configuration/secret/).
{{< codenew file="application/mysql/mysql-deployment.yaml" >}}
{{< codenew file="application/mysql/mysql-pv.yaml" >}}
@@ -231,7 +231,7 @@ Deployment 中镜像或其他部分同往常一样可以通过 `kubectl apply`
-->
* 不要对应用进行规模扩缩。这里的设置仅适用于单实例应用。下层的 PersistentVolume
仅只能挂载到一个 Pod 上。对于集群级有状态应用，请参考
[StatefulSet 文档](/zh/docs/concepts/workloads/controllers/statefulset/).
[StatefulSet 文档](/zh-cn/docs/concepts/workloads/controllers/statefulset/).
* 在 Deployment 的 YAML 文件中使用 `strategy:` `type: Recreate`。
该选项指示 Kubernetes _不_ 使用滚动升级。滚动升级无法工作，因为这里一次不能
运行多个 Pod。在使用更新的配置文件创建新的 Pod 前，`Recreate` 策略将
@@ -276,11 +276,11 @@ PersistentVolume 将被自动删除。
* [Volumes](/docs/concepts/storage/volumes/) and [Persistent Volumes](/docs/concepts/storage/persistent-volumes/)
-->
* 欲进一步了解 Deployment 对象，请参考 [Deployment 对象](/zh/docs/concepts/workloads/controllers/deployment/)
* 进一步了解[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
* 欲进一步了解 Deployment 对象，请参考 [Deployment 对象](/zh-cn/docs/concepts/workloads/controllers/deployment/)
* 进一步了解[部署应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)
* 参阅 [kubectl run 文档](/docs/reference/generated/kubectl/kubectl-commands/#run)
* 参阅[卷](/zh/docs/concepts/storage/volumes/)和[持久卷](/zh/docs/concepts/storage/persistent-volumes/)
* 参阅[卷](/zh-cn/docs/concepts/storage/volumes/)和[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)
content/zh-cn/docs/tasks/run-application/run-stateless-application-deployment.md
+2 -2
View File
@@ -231,7 +231,7 @@ added to Kubernetes, replicated applications were configured using a
创建一个多副本应用首选方法是使用 Deployment，Deployment 内部使用 ReplicaSet。
在 Deployment 和 ReplicaSet 被引入到 Kubernetes 之前，多副本应用通过
[ReplicationController](/zh/docs/concepts/workloads/controllers/replicationcontroller/)
[ReplicationController](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/)
来配置。
## {{% heading "whatsnext" %}}
@@ -239,5 +239,5 @@ added to Kubernetes, replicated applications were configured using a
<!--
* Learn more about [Deployment objects](/docs/concepts/workloads/controllers/deployment/).
-->
* 进一步了解 [Deployment 对象](/zh/docs/concepts/workloads/controllers/deployment/)。
* 进一步了解 [Deployment 对象](/zh-cn/docs/concepts/workloads/controllers/deployment/)。
content/zh-cn/docs/tasks/run-application/scale-stateful-set.md
+4 -4
View File
@@ -24,8 +24,8 @@ This task shows how to scale a StatefulSet. Scaling a StatefulSet refers to incr
* StatefulSets 仅适用于 Kubernetes 1.5 及以上版本。
* 不是所有 Stateful 应用都能很好地执行扩缩操作。
如果你不是很确定是否要扩缩你的 StatefulSet，可先参阅
[StatefulSet 概念](/zh/docs/concepts/workloads/controllers/statefulset/)
或者 [StatefulSet 教程](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。
[StatefulSet 概念](/zh-cn/docs/concepts/workloads/controllers/statefulset/)
或者 [StatefulSet 教程](/zh-cn/docs/tutorials/stateful-application/basic-stateful-set/)。
* 仅当你确定你的有状态应用的集群是完全健康的，才可执行扩缩操作.
@@ -75,7 +75,7 @@ update `.spec.replicas` of the StatefulSet manifests, and then do a `kubectl app
-->
### 对 StatefulSet 执行就地更新
另外, 你可以[就地更新](/zh/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) StatefulSet。
另外, 你可以[就地更新](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) StatefulSet。
如果你的 StatefulSet 最初通过 `kubectl apply` 或 `kubectl create --save-config` 创建,
你可以更新 StatefulSet 清单中的 `.spec.replicas`, 然后执行命令 `kubectl apply`:
@@ -163,5 +163,5 @@ Stateful 应用的集群是完全健康时才执行扩缩操作。
<!--
* Learn more about [deleting a StatefulSet](/docs/tasks/run-application/delete-stateful-set/).
-->
* 进一步了解[删除 StatefulSet](/zh/docs/tasks/run-application/delete-stateful-set/)
* 进一步了解[删除 StatefulSet](/zh-cn/docs/tasks/run-application/delete-stateful-set/)