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

[zh] Fix links in zh localization (1)

Browse Source
This commit is contained in:
Qiming Teng
2020-12-04 14:10:01 +08:00
parent dcdf3f0bac
commit 482351ef2a
20 changed files with 229 additions and 180 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/zh/docs/concepts/workloads/controllers/daemonset.md
+1 -1
View File
@@ -236,7 +236,7 @@ DaemonSet 确保所有符合条件的节点都运行该 Pod 的一个副本。
* Pod 行为的不一致性：正常 Pod 在被创建后等待调度时处于 `Pending` 状态，
DaemonSet Pods 创建后不会处于 `Pending` 状态下。这使用户感到困惑。
* [Pod 抢占](/docs/concepts/configuration/pod-priority-preemption/)
* [Pod 抢占](/zh/docs/concepts/configuration/pod-priority-preemption/)
由默认调度器处理。启用抢占后，DaemonSet 控制器将在不考虑 Pod 优先级和抢占
的情况下制定调度决策。
content/zh/docs/concepts/workloads/controllers/replicaset.md
+1 -1
View File
@@ -405,7 +405,7 @@ be rejected by the API.
### Pod 选择算符 {#pod-selector}
`.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。
如前文中[所讨论的](how-a-replicaset-works)，这些是用来标识要被获取的 Pods
如前文中[所讨论的](#how-a-replicaset-works)，这些是用来标识要被获取的 Pods
的标签。在签名的 `frontend.yaml` 示例中，选择算符为：
```yaml
content/zh/docs/concepts/workloads/controllers/statefulset.md
+69 -32
View File
@@ -50,7 +50,12 @@ that provides a set of stateless replicas.
[Deployment](/docs/concepts/workloads/controllers/deployment/) or
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) may be better suited to your stateless needs.
-->
在上面，稳定意味着 Pod 调度或重调度的整个过程是有持久性的。如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者 [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 可能更适用于您的无状态应用部署需要。
在上面描述中，“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的。
如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用
由一组无状态的副本控制器提供的工作负载来部署应用程序，比如
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者
[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)
可能更适用于你的无状态应用部署需要。
<!--
## Limitations
@@ -67,11 +72,19 @@ that provides a set of stateless replicas.
it's possible to get into a broken state that requires
[manual intervention to repair](#forced-rollback).
-->
* 给定 Pod 的存储必须由 [PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) 基于所请求的 `storage class` 来提供，或者由管理员预先提供。
* 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
* StatefulSet 当前需要[无头服务](/zh/docs/concepts/services-networking/service/#headless-services) 来负责 Pod 的网络标识。您需要负责创建此服务。
* 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。为了实现 StatefulSet 中的 Pod 可以有序和优雅的终止，可以在删除之前将 StatefulSet 缩放为 0。
* 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates)，可能进入需要 [人工干预](#forced-rollback) 才能修复的损坏状态。
* 给定 Pod 的存储必须由
[PersistentVolume 驱动](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)
基于所请求的 `storage class` 来提供，或者由管理员预先提供。
* 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。
这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
* StatefulSet 当前需要[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
来负责 Pod 的网络标识。你需要负责创建此服务。
* 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。
为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止，可以在删除之前将 StatefulSet
缩放为 0。
* 在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用
[滚动更新](#rolling-updates)，可能进入需要[人工干预](#forced-rollback)
才能修复的损坏状态。
<!--
## Components
@@ -140,7 +153,7 @@ spec:
* 名为 `nginx` 的 Headless Service 用来控制网络域名。
* 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
* `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
[PersistentVolumes](/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
[PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
<!--
## Pod Selector
@@ -150,7 +163,10 @@ spec:
<!--
You must set the `.spec.selector` field of a StatefulSet to match the labels of its `.spec.template.metadata.labels`. Prior to Kubernetes 1.8, the `.spec.selector` field was defaulted when omitted. In 1.8 and later versions, failing to specify a matching Pod Selector will result in a validation error during StatefulSet creation.
-->
您必须设置 StatefulSet 的 `.spec.selector` 字段，使之匹配其在 `.spec.template.metadata.labels` 中设置的标签。在 Kubernetes 1.8 版本之前，被忽略 `.spec.selector` 字段会获得默认设置值。在 1.8 和以后的版本中，未指定匹配的 Pod 选择器将在创建 StatefulSet 期间导致验证错误。
你必须设置 StatefulSet 的 `.spec.selector` 字段，使之匹配其在
`.spec.template.metadata.labels` 中设置的标签。在 Kubernetes 1.8 版本之前，
被忽略 `.spec.selector` 字段会获得默认设置值。
在 1.8 和以后的版本中，未指定匹配的 Pod 选择器将在创建 StatefulSet 期间导致验证错误。
<!--
## Pod Identity
@@ -161,7 +177,8 @@ regardless of which node it's (re)scheduled on.
-->
## Pod 标识 {#pod-identity}
StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。该标识和 Pod 是绑定的，不管它被调度在哪个节点上。
StatefulSet Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。
该标识和 Pod 是绑定的，不管它被调度在哪个节点上。
<!--
### Ordinal Index
@@ -171,7 +188,8 @@ assigned an integer ordinal, from 0 up through N-1, that is unique over the Set.
-->
### 有序索引 {#ordinal-index}
对于具有 N 个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号，从 0 到 N-1，该序号在 StatefulSet 上是唯一的。
对于具有 N 个副本的 StatefulSet，StatefulSet 中的每个 Pod 将被分配一个整数序号，
从 0 到 N-1，该序号在 StatefulSet 上是唯一的。
<!--
### Stable Network ID
@@ -191,8 +209,9 @@ by the `serviceName` field on the StatefulSet.
### 稳定的网络 ID {#stable-network-id}
StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。
组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。
StatefulSet 可以使用 [headless 服务](/zh/docs/concepts/services-networking/service/#headless-services)
组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。
上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。
StatefulSet 可以使用 [无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
控制它的 Pod 的网络域。管理域的这个服务的格式为：
`$(服务名称).$(命名空间).svc.cluster.local`，其中 `cluster.local` 是集群域。
一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为：
@@ -232,7 +251,7 @@ This must be done manually.
-->
### 稳定的存储 {#stable-storage}
Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolumes](/docs/concepts/storage/persistent-volumes/)。
Kubernetes 为每个 VolumeClaimTemplate 创建一个 [PersistentVolume](/zh/docs/concepts/storage/persistent-volumes/)。
在上面的 nginx 示例中，每个 Pod 将会得到基于 StorageClass `my-storage-class` 提供的
1 Gib 的 PersistentVolume。如果没有声明 StorageClass，就会使用默认的 StorageClass。
当一个 Pod 被调度（重新调度）到节点上时，它的 `volumeMounts` 会挂载与其
@@ -250,7 +269,9 @@ the StatefulSet.
-->
### Pod 名称标签 {#pod-name-label}
当 StatefulSet {{< glossary_tooltip term_id="controller" >}} 创建 Pod 时，它会添加一个标签 `statefulset.kubernetes.io/pod-name`，该标签设置为 Pod 名称。这个标签允许您给 StatefulSet 中的特定 Pod 绑定一个 Service。
当 StatefulSet {{< glossary_tooltip term_id="controller" >}} 创建 Pod 时，
它会添加一个标签 `statefulset.kubernetes.io/pod-name`，该标签值设置为 Pod 名称。
这个标签允许你给 StatefulSet 中的特定 Pod 绑定一个 Service。
<!--
## Deployment and Scaling Guarantees
@@ -296,8 +317,10 @@ is fully shutdown and deleted. If web-0 were to fail after web-2 has been termin
is completely shutdown, but prior to web-1's termination, web-1 would not be terminated
until web-0 is Running and Ready.
-->
如果用户想将示例中的 StatefulSet 收缩为 `replicas=1`，首先被终止的是 web-2。在 web-2 没有被完全停止和删除前，web-1 不会被终止。当 web-2 已被终止和删除、web-1 尚未被终止，如果在此期间发生 web-0 运行失败，那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。
如果用户想将示例中的 StatefulSet 收缩为 `replicas=1`，首先被终止的是 web-2。
在 web-2 没有被完全停止和删除前，web-1 不会被终止。
当 web-2 已被终止和删除、web-1 尚未被终止，如果在此期间发生 web-0 运行失败，
那么就不会终止 web-1，必须等到 web-0 进入 Running 和 Ready 状态后才会终止 web-1。
<!--
### Pod Management Policies
@@ -307,8 +330,8 @@ preserving its uniqueness and identity guarantees via its `.spec.podManagementPo
-->
### Pod 管理策略 {#pod-management-policies}
在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您不要求其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。
在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许您放宽其排序保证，同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。
在 Kubernetes 1.7 及以后的版本中，StatefulSet 允许你放宽其排序保证，
同时通过它的 `.spec.podManagementPolicy` 域保持其唯一性和身份保证。
<!--
#### OrderedReady Pod Management
@@ -318,7 +341,8 @@ described [above](#deployment-and-scaling-guarantees).
-->
#### OrderedReady Pod 管理
`OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了[上面](#deployment-and-scaling-guarantees)描述的功能。
`OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了
[上面](#deployment-and-scaling-guarantees)描述的功能。
<!--
#### Parallel Pod Management
@@ -342,7 +366,8 @@ annotations for the Pods in a StatefulSet.
-->
## 更新策略 {#update-strategies}
在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让您可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。
在 Kubernetes 1.7 及以后的版本中，StatefulSet 的 `.spec.updateStrategy` 字段让
你可以配置和禁用掉自动滚动更新 Pod 的容器、标签、资源请求或限制、以及注解。
<!--
### On Delete
@@ -354,8 +379,11 @@ create new Pods that reflect modifications made to a StatefulSet's `.spec.templa
-->
### 关于删除策略 {#on-delete}
`OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的 `.spec.updateStrategy.type` 设置为 `OnDelete` 时，它的控制器将不会自动更新 StatefulSet 中的 Pod。用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的 `.spec.template` 的变动作出反应。
`OnDelete` 更新策略实现了 1.6 及以前版本的历史遗留行为。当 StatefulSet 的
`.spec.updateStrategy.type` 设置为 `OnDelete` 时，它的控制器将不会自动更新
StatefulSet 中的 Pod。
用户必须手动删除 Pod 以便让控制器创建新的 Pod，以此来对 StatefulSet 的
`.spec.template` 的变动作出反应。
<!--
### Rolling Updates
@@ -369,9 +397,12 @@ updating its predecessor.
-->
### 滚动更新 {#rolling-updates}
`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。在没有声明 `.spec.updateStrategy` 时，`RollingUpdate` 是默认配置。
当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时，StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。
它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。它会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。
`RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。
在没有声明 `.spec.updateStrategy` 时，`RollingUpdate` 是默认配置。
当 StatefulSet 的 `.spec.updateStrategy.type` 被设置为 `RollingUpdate` 时，
StatefulSet 控制器会删除和重建 StatefulSet 中的每个 Pod。
它将按照与 Pod 终止相同的顺序（从最大序号到最小序号）进行，每次更新一个 Pod。
它会等到被更新的 Pod 进入 Running 和 Ready 状态，然后再更新其前身。
<!--
#### Partitions
@@ -388,8 +419,15 @@ update, roll out a canary, or perform a phased roll out.
-->
#### 分区 {#partitions}
通过声明 `.spec.updateStrategy.rollingUpdate.partition` 的方式，`RollingUpdate` 更新策略可以实现分区。如果声明了一个分区，当 StatefulSet 的 `.spec.template` 被更新时，所有序号大于等于该分区序号的 Pod 都会被更新。所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的 `.spec.replicas`，对它的 `.spec.template` 的更新将不会传递到它的 Pod。
在大多数情况下，您不需要使用分区，但如果您希望进行阶段更新、执行金丝雀或执行分阶段展开，则这些分区会非常有用。
通过声明 `.spec.updateStrategy.rollingUpdate.partition` 的方式，`RollingUpdate`
更新策略可以实现分区。
如果声明了一个分区，当 StatefulSet 的 `.spec.template` 被更新时，
所有序号大于等于该分区序号的 Pod 都会被更新。
所有序号小于该分区序号的 Pod 都不会被更新，并且，即使他们被删除也会依据之前的版本进行重建。
如果 StatefulSet 的 `.spec.updateStrategy.rollingUpdate.partition` 大于它的
`.spec.replicas`，对它的 `.spec.template` 的更新将不会传递到它的 Pod。
在大多数情况下，你不需要使用分区，但如果你希望进行阶段更新、执行金丝雀或执行
分阶段上线，则这些分区会非常有用。
<!--
#### Forced Rollback
@@ -404,9 +442,11 @@ StatefulSet will stop the rollout and wait.
-->
#### 强制回滚 {#forced-rollback}
在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 时使用 [滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。
在默认 [Pod 管理策略](#pod-management-policies)(`OrderedReady`) 下使用
[滚动更新](#rolling-updates) ，可能进入需要人工干预才能修复的损坏状态。
如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件或应用程序级配置错误），StatefulSet 将停止回滚并等待。
如果更新后 Pod 模板配置进入无法运行或就绪的状态（例如，由于错误的二进制文件
或应用程序级配置错误），StatefulSet 将停止回滚并等待。
<!--
In this state, it's not enough to revert the Pod template to a good configuration.
@@ -433,10 +473,7 @@ StatefulSet 才会开始使用被还原的模板来重新创建 Pod。
* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
* Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
-->
* 示例一：[部署有状态应用](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。
* 示例二：[使用 StatefulSet 部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/)。
* 示例三：[运行多副本的有状态应用程序](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。