kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #34507 from howieyuen/concept-pages-4 

[zh]Update concepts pages(part-4) for links with '/zh/' prefix, using new prefix '/zh-cn/'
pull/34555/head
Kubernetes Prow Robot 2022-06-23 20:33:19 -07:00 committed by GitHub
parent d16f4daeb1 3ecfa2da5a
commit 43da11bfc7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
25 changed files with 309 additions and 309 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
content/zh-cn/docs/concepts/storage/dynamic-provisioning.md
View File

@ -23,7 +23,7 @@ automatically provisions storage when it is requested by users.
动态卷供应允许按需创建存储卷。
如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷，
然后在 Kubernetes 集群创建
[`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。
[`PersistentVolume` 对象](/zh-cn/docs/concepts/storage/persistent-volumes/)来表示这些卷。
动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。
<!-- body -->
@ -58,7 +58,7 @@ have the ability to select from multiple storage options.
More information on storage classes can be found
[here](/docs/concepts/storage/storage-classes/).
-->
点击[这里](/zh/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。
点击[这里](/zh-cn/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。
<!--
## Enabling Dynamic Provisioning
@ -78,7 +78,7 @@ disk-like persistent disks.
-->
要启用动态供应功能，集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。
`StorageClass` 对象定义当动态供应被调用时，哪一个驱动将被使用和哪些参数将被传递给驱动。
StorageClass 对象的名字必须是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
StorageClass 对象的名字必须是一个合法的 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
以下清单创建了一个 `StorageClass` 存储类 "slow"，它提供类似标准磁盘的永久磁盘。
```yaml
@ -172,7 +172,7 @@ can enable this behavior by:
is enabled on the API server.
-->
- 标记一个 `StorageClass` 为 *默认*；
- 确保 [`DefaultStorageClass` 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。
- 确保 [`DefaultStorageClass` 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。
<!--
An administrator can mark a specific `StorageClass` as default by adding the
@ -205,7 +205,7 @@ Zones in a Region. Single-Zone storage backends should be provisioned in the Zon
Pods are scheduled. This can be accomplished by setting the [Volume Binding
Mode](/docs/concepts/storage/storage-classes/#volume-binding-mode).
-->
在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
在[多区域](/zh-cn/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。
单区域存储后端应该被供应到 Pod 被调度到的区域。
这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。
这可以通过设置[卷绑定模式](/zh-cn/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。

38
content/zh-cn/docs/concepts/storage/ephemeral-volumes.md
View File

@ -23,7 +23,7 @@ with [volumes](/docs/concepts/storage/volumes/) is suggested, in
particular PersistentVolumeClaim and PersistentVolume.
-->
本文档描述 Kubernetes 中的 _临时卷（Ephemeral Volume）_。
建议先了解[卷](/zh/docs/concepts/storage/volumes/)，特别是 PersistentVolumeClaim 和 PersistentVolume。
建议先了解[卷](/zh-cn/docs/concepts/storage/volumes/)，特别是 PersistentVolumeClaim 和 PersistentVolume。
<!-- body -->
<!--
@ -80,13 +80,13 @@ different purposes:
can be provided by all storage drivers that also support persistent volumes
-->
Kubernetes 为了不同的目的，支持几种不同类型的临时卷：
- [emptyDir](/zh/docs/concepts/storage/volumes/#emptydir)：
- [emptyDir](/zh-cn/docs/concepts/storage/volumes/#emptydir)：
Pod 启动时为空，存储空间来自本地的 kubelet 根目录（通常是根磁盘）或内存
- [configMap](/zh/docs/concepts/storage/volumes/#configmap)、
[downwardAPI](/zh/docs/concepts/storage/volumes/#downwardapi)、
[secret](/zh/docs/concepts/storage/volumes/#secret)：
- [configMap](/zh-cn/docs/concepts/storage/volumes/#configmap)、
[downwardAPI](/zh-cn/docs/concepts/storage/volumes/#downwardapi)、
[secret](/zh-cn/docs/concepts/storage/volumes/#secret)：
将不同类型的 Kubernetes 数据注入到 Pod 中
- [CSI 临时卷](/zh/docs/concepts/storage/volumes/#csi-ephemeral-volumes)：
- [CSI 临时卷](/zh-cn/docs/concepts/storage/volumes/#csi-ephemeral-volumes)：
类似于前面的卷类型，但由专门[支持此特性](https://kubernetes-csi.github.io/docs/drivers.html)
的指定
[CSI 驱动程序](https://github.com/container-storage-interface/spec/blob/master/spec.md)提供
@ -103,7 +103,7 @@ CSI ephemeral volumes *must* be provided by third-party CSI storage
drivers.
-->
`emptyDir`、`configMap`、`downwardAPI`、`secret` 是作为
[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)
[本地临时存储](/zh-cn/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)
提供的。它们由各个节点上的 kubelet 管理。
CSI 临时卷 *必须* 由第三方 CSI 存储驱动程序提供。
@ -144,7 +144,7 @@ shows which drivers support ephemeral volumes.
-->
该特性需要启用参数 `CSIInlineVolume`
[特性门控（feature gate）](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控（feature gate）](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
该参数从 Kubernetes 1.16 开始默认启用。
{{< note >}}
@ -171,7 +171,7 @@ Here's an example manifest for a Pod that uses CSI ephemeral storage:
从概念上讲，CSI 临时卷类似于 `configMap`、`downwardAPI` 和 `secret` 类型的卷：
其存储在每个节点本地管理，并在将 Pod 调度到节点后与其他本地资源一起创建。
在这个阶段，Kubernetes 没有重新调度 Pods 的概念。卷创建不太可能失败，否则 Pod 启动将会受阻。
特别是，这些卷 **不** 支持[感知存储容量的 Pod 调度](/zh/docs/concepts/storage/storage-capacity/)。
特别是，这些卷 **不** 支持[感知存储容量的 Pod 调度](/zh-cn/docs/concepts/storage/storage-capacity/)。
它们目前也没包括在 Pod 的存储资源使用限制中，因为 kubelet 只能对它自己管理的存储强制执行。
下面是使用 CSI 临时存储的 Pod 的示例清单：
@ -226,7 +226,7 @@ CSI 临时卷允许用户直接向 CSI 驱动程序提供 `volumeAttributes`，
例如，通常在 StorageClass 中定义的参数不应通过使用内联临时卷向用户公开。
作为一个集群管理员，你可以使用
[PodSecurityPolicy](/zh/docs/concepts/security/pod-security-policy/)
[PodSecurityPolicy](/zh-cn/docs/concepts/security/pod-security-policy/)
来控制在 Pod 中可以使用哪些 CSI 驱动程序，
具体则是通过 [`allowedCSIDrivers` 字段](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy)
指定。
@ -239,7 +239,7 @@ allowed to be used as inline volumes within a Pod spec may do so by:
-->
如果集群管理员需要限制 CSI 驱动程序在 Pod 规约中被作为内联卷使用，可以这样做：
- 从 CSIDriver 规约的 `volumeLifecycleModes` 中删除 `Ephemeral`，这可以防止驱动程序被用作内联临时卷。
- 使用[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
- 使用[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)
来限制如何使用此驱动程序。
<!--
@ -275,10 +275,10 @@ Example:
- 卷可以有固定的大小，Pod 不能超量使用。
- 卷可能有一些初始数据，这取决于驱动程序和参数。
- 当驱动程序支持，卷上的典型操作将被支持，包括
（[快照](/zh/docs/concepts/storage/volume-snapshots/)、
[克隆](/zh/docs/concepts/storage/volume-pvc-datasource/)、
[调整大小](/zh/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)和
[存储容量跟踪](/zh/docs/concepts/storage/storage-capacity/)）。
（[快照](/zh-cn/docs/concepts/storage/volume-snapshots/)、
[克隆](/zh-cn/docs/concepts/storage/volume-pvc-datasource/)、
[调整大小](/zh-cn/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)和
[存储容量跟踪](/zh-cn/docs/concepts/storage/storage-capacity/)）。
示例：
@ -357,7 +357,7 @@ storage classes is to delete volumes. You can create quasi-ephemeral local stora
using a StorageClass with a reclaim policy of `retain`: the storage outlives the Pod,
and in this case you need to ensure that volume clean up happens separately.
-->
就[资源所有权](/zh/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)而言，
就[资源所有权](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)而言，
拥有通用临时存储的 Pod 是提供临时存储 (ephemeral storage) 的 PersistentVolumeClaim 的所有者。
当 Pod 被删除时，Kubernetes 垃圾收集器会删除 PVC，
然后 PVC 通常会触发卷的删除，因为存储类的默认回收策略是删除卷。
@ -436,7 +436,7 @@ use an [admission webhook](/docs/reference/access-authn-authz/extensible-admissi
启用 GenericEphemeralVolume 特性会导致那些没有 PVCs 创建权限的用户，
在创建 Pods 时，被允许间接的创建 PVCs。
集群管理员必须意识到这一点。
如果这不符合他们的安全模型，他们应该使用一个[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/)
如果这不符合他们的安全模型，他们应该使用一个[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)
拒绝包含通用临时卷的 Pods。
<!--
@ -444,7 +444,7 @@ The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#sto
even if users are allowed to use this new mechanism, they cannot use
it to circumvent other policies.
-->
[为 PVC 卷所设置的逐名字空间的配额](/zh/docs/concepts/policy/resource-quotas/#storage-resource-quota)
[为 PVC 卷所设置的逐名字空间的配额](/zh-cn/docs/concepts/policy/resource-quotas/#storage-resource-quota)
仍然有效，因此即使允许用户使用这种新机制，他们也不能使用它来规避其他策略。
## {{% heading "whatsnext" %}}
@ -456,7 +456,7 @@ See [local ephemeral storage](/docs/concepts/configuration/manage-resources-cont
-->
### kubelet 管理的临时卷 {#ephemeral-volumes-managed-by-kubelet}
参阅[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)。
参阅[本地临时存储](/zh-cn/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)。
<!--
### CSI ephemeral volumes

86
content/zh-cn/docs/concepts/storage/persistent-volumes.md
View File

@ -32,7 +32,7 @@ weight: 20
This document describes _persistent volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
-->
本文描述 Kubernetes 中的 _持久卷（Persistent Volume）_ 。
建议先熟悉[卷（Volume）](/zh/docs/concepts/storage/volumes/)的概念。
建议先熟悉[卷（Volume）](/zh-cn/docs/concepts/storage/volumes/)的概念。
<!-- body -->
@ -52,7 +52,7 @@ PersistentVolumeClaim。
A _PersistentVolume_ (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.
-->
持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者
使用[存储类（Storage Class）](/zh/docs/concepts/storage/storage-classes/)来动态供应。
使用[存储类（Storage Class）](/zh-cn/docs/concepts/storage/storage-classes/)来动态供应。
持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样，也是使用
卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。
此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。
@ -77,7 +77,7 @@ See the [detailed walkthrough with working examples](/docs/tasks/configure-pod-c
仅限于卷大小和访问模式，同时又不能将卷是如何实现的这些细节暴露给用户。
为了满足这类需求，就有了 _存储类（StorageClass）_ 资源。
参见[基于运行示例的详细演练](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。
参见[基于运行示例的详细演练](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。
<!--
## Lifecycle of a volume and claim
@ -123,7 +123,7 @@ dynamic provisioning for themselves.
如果管理员所创建的所有静态 PV 卷都无法与用户的 PersistentVolumeClaim 匹配，
集群可以尝试为该 PVC 申领动态供应一个存储卷。
这一供应操作是基于 StorageClass 来实现的：PVC 申领必须请求某个
[存储类](/zh/docs/concepts/storage/storage-classes/)，同时集群管理员必须
[存储类](/zh-cn/docs/concepts/storage/storage-classes/)，同时集群管理员必须
已经创建并配置了该类，这样动态供应卷的动作才会发生。
如果 PVC 申领指定存储类为 `""`，则相当于为自身禁止使用动态供应的卷。
@ -136,11 +136,11 @@ the API server component. For more information on API server command-line flags,
check [kube-apiserver](/docs/admin/kube-apiserver/) documentation.
-->
为了基于存储类完成动态的存储供应，集群管理员需要在 API 服务器上启用
`DefaultStorageClass` [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)。
`DefaultStorageClass` [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)。
举例而言，可以通过保证 `DefaultStorageClass` 出现在 API 服务器组件的
`--enable-admission-plugins` 标志值中实现这点；该标志的值可以是逗号
分隔的有序列表。关于 API 服务器标志的更多信息，可以参考
[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
[kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)
文档。
<!--
@ -317,7 +317,7 @@ Cinder 卷）中移除所关联的存储资产。
动态供应的卷会继承[其 StorageClass 中设置的回收策略](#reclaim-policy)，该策略默认
为 `Delete`。
管理员需要根据用户的期望来配置 StorageClass；否则 PV 卷被创建之后必须要被
编辑或者修补。参阅[更改 PV 卷的回收策略](/zh/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
编辑或者修补。参阅[更改 PV 卷的回收策略](/zh-cn/docs/tasks/administer-cluster/change-pv-reclaim-policy/).
<!--
#### Recycle
@ -343,7 +343,7 @@ The custom recycler Pod template must contain a `volumes` specification, as
shown in the example below:
-->
不过，管理员可以按
[参考资料](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
[参考资料](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
中所述，使用 Kubernetes 控制器管理器命令行参数来配置一个定制的回收器（Recycler）
Pod 模板。此定制的回收器 Pod 模板必须包含一个 `volumes` 规约，如下例所示：
@ -484,7 +484,7 @@ The control plane still checks that [storage class](/docs/concepts/storage/stora
-->
绑定操作不会考虑某些卷匹配条件是否满足，包括节点亲和性等等。
控制面仍然会检查
[存储类](/zh/docs/concepts/storage/storage-classes/)、访问模式和所请求的
[存储类](/zh-cn/docs/concepts/storage/storage-classes/)、访问模式和所请求的
存储尺寸都是合法的。
```yaml
@ -720,7 +720,7 @@ Recovery from failing PVC expansion by users is available as an alpha feature si
{{< note >}}
Kubernetes 从 1.23 版本开始将允许用户恢复失败的 PVC 扩展这一能力作为
alpha 特性支持。 `RecoverVolumeExpansionFailure` 必须被启用以允许使用此特性。
可参考[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
可参考[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
文档了解更多信息。
{{< /note >}}
@ -787,23 +787,23 @@ PV 持久卷是用插件的形式来实现的。Kubernetes 目前支持以下插
* [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume
* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume
-->
* [`awsElasticBlockStore`](/zh/docs/concepts/storage/volumes/#awselasticblockstore) - AWS 弹性块存储（EBS）
* [`azureDisk`](/zh/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
* [`azureFile`](/zh/docs/concepts/storage/volumes/#azurefile) - Azure File
* [`cephfs`](/zh/docs/concepts/storage/volumes/#cephfs) - CephFS volume
* [`csi`](/zh/docs/concepts/storage/volumes/#csi) - 容器存储接口 (CSI)
* [`fc`](/zh/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 存储
* [`gcePersistentDisk`](/zh/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE 持久化盘
* [`glusterfs`](/zh/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 卷
* [`hostPath`](/zh/docs/concepts/storage/volumes/#hostpath) - HostPath 卷
* [`awsElasticBlockStore`](/zh-cn/docs/concepts/storage/volumes/#awselasticblockstore) - AWS 弹性块存储（EBS）
* [`azureDisk`](/zh-cn/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
* [`azureFile`](/zh-cn/docs/concepts/storage/volumes/#azurefile) - Azure File
* [`cephfs`](/zh-cn/docs/concepts/storage/volumes/#cephfs) - CephFS volume
* [`csi`](/zh-cn/docs/concepts/storage/volumes/#csi) - 容器存储接口 (CSI)
* [`fc`](/zh-cn/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 存储
* [`gcePersistentDisk`](/zh-cn/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE 持久化盘
* [`glusterfs`](/zh-cn/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 卷
* [`hostPath`](/zh-cn/docs/concepts/storage/volumes/#hostpath) - HostPath 卷
（仅供单节点测试使用；不适用于多节点集群；
请尝试使用 `local` 卷作为替代）
* [`iscsi`](/zh/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) 存储
* [`local`](/zh/docs/concepts/storage/volumes/#local) - 节点上挂载的本地存储设备
* [`nfs`](/zh/docs/concepts/storage/volumes/#nfs) - 网络文件系统 (NFS) 存储
* [`portworxVolume`](/zh/docs/concepts/storage/volumes/#portworxvolume) - Portworx 卷
* [`rbd`](/zh/docs/concepts/storage/volumes/#rbd) - Rados 块设备 (RBD) 卷
* [`vsphereVolume`](/zh/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 卷
* [`iscsi`](/zh-cn/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) 存储
* [`local`](/zh-cn/docs/concepts/storage/volumes/#local) - 节点上挂载的本地存储设备
* [`nfs`](/zh-cn/docs/concepts/storage/volumes/#nfs) - 网络文件系统 (NFS) 存储
* [`portworxVolume`](/zh-cn/docs/concepts/storage/volumes/#portworxvolume) - Portworx 卷
* [`rbd`](/zh-cn/docs/concepts/storage/volumes/#rbd) - Rados 块设备 (RBD) 卷
* [`vsphereVolume`](/zh-cn/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 卷
<!--
The following types of PersistentVolume are deprecated. This means that support is still available but will be removed in a future Kubernetes release.
@ -823,7 +823,7 @@ The following types of PersistentVolume are deprecated. This means that support
以下的持久卷已被弃用。这意味着当前仍是支持的，但是 Kubernetes 将来的发行版会将其移除。
* [`cinder`](/docs/concepts/storage/volumes/#cinder) - Cinder（OpenStack 块存储）（于 v1.18 **弃用**）
* [`flexVolume`](/zh/docs/concepts/storage/volumes/#flexVolume) - FlexVolume （于 v1.23 **弃用**）
* [`flexVolume`](/zh-cn/docs/concepts/storage/volumes/#flexVolume) - FlexVolume （于 v1.23 **弃用**）
* [`flocker`](/docs/concepts/storage/volumes/#flocker) - Flocker 存储（于 v1.22 **弃用**）
* [`quobyte`](/docs/concepts/storage/volumes/#quobyte) - Quobyte 卷
（于 v1.22 **弃用**）
@ -854,7 +854,7 @@ The name of a PersistentVolume object must be a valid
每个 PV 对象都包含 `spec` 部分和 `status` 部分，分别对应卷的规约和状态。
PersistentVolume 对象的名称必须是合法的
[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).
```yaml
apiVersion: v1
@ -898,7 +898,7 @@ Currently, storage size is the only resource that can be set or requested. Futu
一般而言，每个 PV 卷都有确定的存储容量。
容量属性是使用 PV 对象的 `capacity` 属性来设置的。
参考词汇表中的
[量纲（Quantity）](/zh/docs/reference/glossary/?all=true#term-quantity)
[量纲（Quantity）](/zh-cn/docs/reference/glossary/?all=true#term-quantity)
词条，了解 `capacity` 字段可以接受的单位。
目前，存储大小是可以设置和请求的唯一资源。
@ -1076,7 +1076,7 @@ to PVCs that request no particular class.
### 类 {#class}
每个 PV 可以属于某个类（Class），通过将其 `storageClassName` 属性设置为某个
[StorageClass](/zh/docs/concepts/storage/storage-classes/) 的名称来指定。
[StorageClass](/zh-cn/docs/concepts/storage/storage-classes/) 的名称来指定。
特定类的 PV 卷只能绑定到请求该类存储卷的 PVC 申领。
未设置 `storageClassName` 的 PV 卷没有类设定，只能绑定到那些没有指定特定
存储类的 PVC 申领。
@ -1181,11 +1181,11 @@ For most volume types, you do not need to set this field. It is automatically po
-->
{{< note >}}
对大多数类型的卷而言，你不需要设置节点亲和性字段。
[AWS EBS](/zh/docs/concepts/storage/volumes/#awselasticblockstore)、
[GCE PD](/zh/docs/concepts/storage/volumes/#gcepersistentdisk) 和
[Azure Disk](/zh/docs/concepts/storage/volumes/#azuredisk) 卷类型都能
[AWS EBS](/zh-cn/docs/concepts/storage/volumes/#awselasticblockstore)、
[GCE PD](/zh-cn/docs/concepts/storage/volumes/#gcepersistentdisk) 和
[Azure Disk](/zh-cn/docs/concepts/storage/volumes/#azuredisk) 卷类型都能
自动设置相关字段。
你需要为 [local](/zh/docs/concepts/storage/volumes/#local) 卷显式地设置
你需要为 [local](/zh-cn/docs/concepts/storage/volumes/#local) 卷显式地设置
此属性。
{{< /note >}}
@ -1221,7 +1221,7 @@ The name of a PersistentVolumeClaim object must be a valid
-->
每个 PVC 对象都有 `spec` 和 `status` 部分，分别对应申领的规约和状态。
PersistentVolumeClaim 对象的名称必须是合法的
[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).
```yaml
@ -1280,7 +1280,7 @@ Claims can specify a [label selector](/docs/concepts/overview/working-with-objec
-->
### 选择算符 {#selector}
申领可以设置[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)
申领可以设置[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)
来进一步过滤卷集合。只有标签与选择算符相匹配的卷能够绑定到申领上。
选择算符包含两个字段：
@ -1309,7 +1309,7 @@ be bound to the PVC.
### 类 {#class}
申领可以通过为 `storageClassName` 属性设置
[StorageClass](/zh/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。
[StorageClass](/zh-cn/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。
只有所请求的类的 PV 卷，即 `storageClassName` 值与 PVC 设置相同的 PV 卷，
才能绑定到 PVC 申领。
@ -1327,7 +1327,7 @@ PVC 申领不必一定要请求某个类。如果 PVC 的 `storageClassName` 属
存储类的 PV 卷（未设置注解或者注解值为 `""` 的 PersistentVolume（PV）对象在系统中不会被删除，因为这样做可能会引起数据丢失。
未设置 `storageClassName` 的 PVC 与此大不相同，也会被集群作不同处理。
具体筛查方式取决于
[`DefaultStorageClass` 准入控制器插件](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
[`DefaultStorageClass` 准入控制器插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)
是否被启用。
<!--
@ -1435,7 +1435,7 @@ See [an example of `hostPath` typed volume](/docs/tasks/configure-pod-container/
### 类型为 `hostpath` 的 PersistentVolume {#persistentvolumes-typed-hostpath}
`hostPath` PersistentVolume 使用节点上的文件或目录来模拟网络附加（network-attached）存储。
相关细节可参阅[`hostPath` 卷示例](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)。
相关细节可参阅[`hostPath` 卷示例](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume)。
<!--
## Raw Block Volume Support
@ -1526,7 +1526,7 @@ gate enabled, use of the `dataSourceRef` is preferred over `dataSource`.
{{< note >}}
Kubernetes 支持自定义的卷填充器；要使用自定义的卷填充器，你必须为
kube-apiserver 和 kube-controller-manager 启用 `AnyVolumeDataSource`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
{{< /note >}}
卷填充器利用了 PVC 规约字段 `dataSourceRef`。
@ -1722,7 +1722,7 @@ To enable support for restoring a volume from a volume snapshot data source, ena
`VolumeSnapshotDataSource` feature gate on the apiserver and controller-manager.
-->
卷快照（Volume Snapshot）特性的添加仅是为了支持 CSI 卷插件。
有关细节可参阅[卷快照](/zh/docs/concepts/storage/volume-snapshots/)文档。
有关细节可参阅[卷快照](/zh-cn/docs/concepts/storage/volume-snapshots/)文档。
要启用从卷快照数据源恢复数据卷的支持，可在 API 服务器和控制器管理器上启用
`VolumeSnapshotDataSource` 特性门控。
@ -1757,7 +1757,7 @@ spec:
-->
## 卷克隆 {#volume-cloning}
[卷克隆](/zh/docs/concepts/storage/volume-pvc-datasource/)功能特性仅适用于
[卷克隆](/zh-cn/docs/concepts/storage/volume-pvc-datasource/)功能特性仅适用于
CSI 卷插件。
<!--
@ -1840,8 +1840,8 @@ and need persistent storage, it is recommended that you use the following patter
* Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
* Read the [Persistent Storage design document](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/persistent-storage.md).
-->
* 进一步了解[创建持久卷](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
* 进一步学习[创建 PVC 申领](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
* 进一步了解[创建持久卷](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume).
* 进一步学习[创建 PVC 申领](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim).
* 阅读[持久存储的设计文档](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/persistent-storage.md).
<!--

14
content/zh-cn/docs/concepts/storage/projected-volumes.md
View File

@ -20,7 +20,7 @@ weight: 21 # just after persistent volumes
This document describes _projected volumes_ in Kubernetes. Familiarity with [volumes](/docs/concepts/storage/volumes/) is suggested.
-->
本文档描述 Kubernetes 中的*投射卷（Projected Volumes）*。
建议先熟悉[卷](/zh/docs/concepts/storage/volumes/)概念。
建议先熟悉[卷](/zh-cn/docs/concepts/storage/volumes/)概念。
<!-- body -->
@ -42,9 +42,9 @@ Currently, the following types of volume sources can be projected:
目前，以下类型的卷源可以被投射：
* [`secret`](/zh/docs/concepts/storage/volumes/#secret)
* [`downwardAPI`](/zh/docs/concepts/storage/volumes/#downwardapi)
* [`configMap`](/zh/docs/concepts/storage/volumes/#configmap)
* [`secret`](/zh-cn/docs/concepts/storage/volumes/#secret)
* [`downwardAPI`](/zh-cn/docs/concepts/storage/volumes/#downwardapi)
* [`configMap`](/zh-cn/docs/concepts/storage/volumes/#configmap)
* [`serviceAccountToken`](#serviceaccounttoken)
<!--
@ -92,7 +92,7 @@ into a Pod at a specified path. For example:
-->
## serviceAccountToken 投射卷 {#serviceaccounttoken}
当 `TokenRequestProjection` 特性被启用时，你可以将当前
[服务账号](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)
[服务账号](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens)
的令牌注入到 Pod 中特定路径下。例如：
{{< codenew file="pods/storage/projected-service-account-token.yaml" >}}
@ -108,7 +108,7 @@ is optional and it defaults to the identifier of the API server.
-->
示例 Pod 中包含一个投射卷，其中包含注入的服务账号令牌。
此 Pod 中的容器可以使用该令牌访问 Kubernetes API 服务器， 使用
[pod 的 ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/)
[pod 的 ServiceAccount](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)
进行身份验证。`audience` 字段包含令牌所针对的受众。
收到令牌的主体必须使用令牌受众中所指定的某个标识符来标识自身，否则应该拒绝该令牌。
此字段是可选的，默认值为 API 服务器的标识。
@ -130,7 +130,7 @@ of the projected volume.
A container using a projected volume source as a [`subPath`](/docs/concepts/storage/volumes/#using-subpath)
volume mount will not receive updates for those volume sources.
-->
以 [`subPath`](/zh/docs/concepts/storage/volumes/#using-subpath)
以 [`subPath`](/zh-cn/docs/concepts/storage/volumes/#using-subpath)
形式使用投射卷源的容器无法收到对应卷源的更新。
{{< /note >}}

6
content/zh-cn/docs/concepts/storage/storage-capacity.md
View File

@ -25,7 +25,7 @@ multiple scheduling retries will be needed.
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将
[Pod 调度](/zh/docs/concepts/scheduling-eviction/)到能够访问到足够存储容量的节点上。
[Pod 调度](/zh-cn/docs/concepts/scheduling-eviction/)到能够访问到足够存储容量的节点上。
如果没有跟踪存储容量，调度程序可能会选择一个没有足够容量来提供卷的节点，并且需要多次调度重试。
## {{% heading "prerequisites" %}}
@ -100,7 +100,7 @@ significant resources there.
如果有以下情况，存储容量信息将会被 Kubernetes 调度程序使用：
- Pod 使用的卷还没有被创建，
- 卷使用引用了 CSI 驱动的 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}，
并且使用了 `WaitForFirstConsumer` [卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)，
并且使用了 `WaitForFirstConsumer` [卷绑定模式](/zh-cn/docs/concepts/storage/storage-classes/#volume-binding-mode)，
- 驱动程序的 `CSIDriver` 对象的 `StorageCapacity` 被设置为 true。
在这种情况下，调度程序仅考虑将 Pod 调度到有足够存储容量的节点上。这个检测非常简单，
@ -109,7 +109,7 @@ significant resources there.
对于具有 `Immediate` 卷绑定模式的卷，存储驱动程序将决定在何处创建该卷，而不取决于将使用该卷的 Pod。
然后，调度程序将 Pod 调度到创建卷后可使用该卷的节点上。
对于 [CSI 临时卷](/zh/docs/concepts/storage/volumes/#csi)，调度总是在不考虑存储容量的情况下进行。
对于 [CSI 临时卷](/zh-cn/docs/concepts/storage/volumes/#csi)，调度总是在不考虑存储容量的情况下进行。
这是基于这样的假设：该卷类型仅由节点本地的特殊 CSI 驱动程序使用，并且不需要大量资源。
<!--

24
content/zh-cn/docs/concepts/storage/storage-classes.md
View File

@ -23,8 +23,8 @@ with [volumes](/docs/concepts/storage/volumes/) and
[persistent volumes](/docs/concepts/storage/persistent-volumes) is suggested.
-->
本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉
[卷](/zh/docs/concepts/storage/volumes/)和
[持久卷](/zh/docs/concepts/storage/persistent-volumes)的概念。
[卷](/zh-cn/docs/concepts/storage/volumes/)和
[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes)的概念。
<!-- body -->
@ -74,7 +74,7 @@ for details.
-->
管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类：
更多详情请参阅
[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
[PersistentVolumeClaim 章节](/zh-cn/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。
```yaml
apiVersion: storage.k8s.io/v1
@ -249,7 +249,7 @@ the class or PV, If a mount option is invalid, the PV mount fails.
The `volumeBindingMode` field controls when [volume binding and dynamic
provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
-->
`volumeBindingMode` 字段控制了[卷绑定和动态制备](/zh/docs/concepts/storage/persistent-volumes/#provisioning)
`volumeBindingMode` 字段控制了[卷绑定和动态制备](/zh-cn/docs/concepts/storage/persistent-volumes/#provisioning)
应该发生在什么时候。
<!--
@ -277,10 +277,10 @@ and [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-tolera
集群管理员可以通过指定 `WaitForFirstConsumer` 模式来解决此问题。
该模式将延迟 PersistentVolume 的绑定和制备，直到使用该 PersistentVolumeClaim 的 Pod 被创建。
PersistentVolume 会根据 Pod 调度约束指定的拓扑来选择或制备。这些包括但不限于
[资源需求](/zh/docs/concepts/configuration/manage-resources-containers/)、
[节点筛选器](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)、
[pod 亲和性和互斥性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity/)、
以及[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration)。
[资源需求](/zh-cn/docs/concepts/configuration/manage-resources-containers/)、
[节点筛选器](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector)、
[pod 亲和性和互斥性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity/)、
以及[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration)。
<!--
The following plugins support `WaitForFirstConsumer` with dynamic provisioning:
@ -313,7 +313,7 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver
to see its supported topology keys and examples.
-->
动态配置和预先创建的 PV 也支持 [CSI卷](/zh/docs/concepts/storage/volumes/#csi)，
动态配置和预先创建的 PV 也支持 [CSI卷](/zh-cn/docs/concepts/storage/volumes/#csi)，
但是你需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。
{{< note >}}
@ -770,7 +770,7 @@ vSphere 存储类有两种制备器
[弃用](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)。
更多关于 CSI 制备器的详情，请参阅
[Kubernetes vSphere CSI 驱动](https://vsphere-csi-driver.sigs.k8s.io/)
和 [vSphereVolume CSI 迁移](/zh/docs/concepts/storage/volumes/#csi-migration-5)。
和 [vSphereVolume CSI 迁移](/zh-cn/docs/concepts/storage/volumes/#csi-migration-5)。
<!--
#### CSI Provisioner {#vsphere-provisioner-csi}
@ -1209,8 +1209,8 @@ add the `create` permission of resource `secret` for clusterrole
`system:controller:persistent-volume-binder`.
-->
在存储制备期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了
[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和
[控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)，
[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 和
[控制器角色](/zh-cn/docs/reference/access-authn-authz/rbac/#controller-roles)，
为 `system:controller:persistent-volume-binder` 的 clusterrole 添加
`Secret` 资源的 `create` 权限。

2
content/zh-cn/docs/concepts/storage/volume-health-monitoring.md
View File

@ -64,7 +64,7 @@ You need to enable the `CSIVolumeHealth` [feature gate](/docs/reference/command-
-->
{{< note >}}
你需要启用 `CSIVolumeHealth`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
才能在节点上使用此特性。
{{< /note >}}

2
content/zh-cn/docs/concepts/storage/volume-pvc-datasource.md
View File

@ -21,7 +21,7 @@ weight: 60
This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested.
-->
本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉
[卷](/zh/docs/concepts/storage/volumes)。
[卷](/zh-cn/docs/concepts/storage/volumes)。
<!-- body -->

4
content/zh-cn/docs/concepts/storage/volume-snapshot-classes.md
View File

@ -12,8 +12,8 @@ with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and
[storage classes](/docs/concepts/storage/storage-classes) is suggested.
-->
本文档描述了 Kubernetes 中 VolumeSnapshotClass 的概念。建议熟悉
[卷快照（Volume Snapshots）](/zh/docs/concepts/storage/volume-snapshots/)和
[存储类（Storage Class）](/zh/docs/concepts/storage/storage-classes)。
[卷快照（Volume Snapshots）](/zh-cn/docs/concepts/storage/volume-snapshots/)和
[存储类（Storage Class）](/zh-cn/docs/concepts/storage/storage-classes)。
<!-- body -->

8
content/zh-cn/docs/concepts/storage/volume-snapshots.md
View File

@ -18,7 +18,7 @@ weight: 40
In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/).
-->
在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes
的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。
的 [持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)。
<!-- body -->
@ -118,7 +118,7 @@ Instead of using a pre-existing snapshot, you can request that a snapshot to be
#### 动态的 {#dynamic}
可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。
在获取快照时，[卷快照类](/zh/docs/concepts/storage/volume-snapshot-classes/)
在获取快照时，[卷快照类](/zh-cn/docs/concepts/storage/volume-snapshot-classes/)
指定要用的特定于存储提供程序的参数。
<!--
@ -196,7 +196,7 @@ using the attribute `volumeSnapshotClassName`. If nothing is set, then the defau
`persistentVolumeClaimName` 是 `PersistentVolumeClaim` 数据源对快照的名称。
这个字段是动态配置快照中的必填字段。
卷快照可以通过指定 [VolumeSnapshotClass](/zh/docs/concepts/storage/volume-snapshot-classes/)
卷快照可以通过指定 [VolumeSnapshotClass](/zh-cn/docs/concepts/storage/volume-snapshot-classes/)
使用 `volumeSnapshotClassName` 属性来请求特定类。如果没有设置，那么使用默认类（如果有）。
<!--
@ -353,4 +353,4 @@ For more details, see
[Volume Snapshot and Restore Volume from Snapshot](/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support).
-->
更多详细信息，请参阅
[卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。
[卷快照和从快照还原卷](/zh-cn/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。

44
content/zh-cn/docs/concepts/storage/volumes.md
View File

@ -332,7 +332,7 @@ must be installed on the cluster and the `CSIMigration` and `CSIMigrationAzureFi
`file.csi.azure.com` 容器存储接口（CSI）驱动程序。要使用此特性，必须在集群中安装
[Azure 文件 CSI 驱动程序](https://github.com/kubernetes-sigs/azurefile-csi-driver)，
并且 `CSIMigration` 和 `CSIMigrationAzureFile`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
必须被启用。
<!--
@ -449,7 +449,7 @@ must be installed on the cluster.
为了使用此特性，必须在集群中安装
[OpenStack Cinder CSI 驱动程序](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)，
你可以通过设置 `CSIMigrationOpenStack`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
为 `false` 来禁止 Cinder CSI 迁移。
<!--
@ -458,7 +458,7 @@ and the kubelet, you can enable the `InTreePluginOpenStackUnregister`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
-->
要禁止控制器管理器和 kubelet 加载树内 Cinder 插件，你可以启用
`InTreePluginOpenStackUnregister` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
`InTreePluginOpenStackUnregister` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
### configMap
@ -468,7 +468,7 @@ provides a way to inject configuration data into Pods.
The data stored in a ConfigMap object can be referenced in a volume of type
`configMap` and then consumed by containerized applications running in a Pod.
-->
[`configMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)
[`configMap`](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)
卷提供了向 Pod 注入配置数据的方法。
ConfigMap 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被 Pod 中运行的容器化应用使用。
@ -524,7 +524,7 @@ keyed with `log_level`.
* Text data is exposed as files using the UTF-8 character encoding. For other character encodings, use `binaryData`.
-->
{{< note >}}
* 在使用 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前你首先要创建它。
* 在使用 [ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前你首先要创建它。
* 容器以 [subPath](#using-subpath) 卷挂载方式使用 ConfigMap 时，将无法接收 ConfigMap 的更新。
* 文本数据挂载成文件时采用 UTF-8 字符编码。如果使用其他字符编码形式，可使用
`binaryData` 字段。
@ -550,7 +550,7 @@ receive Downward API updates.
<!--
See the [`downwardAPI` volume example](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) for more details.
-->
更多详细信息请参考 [`downwardAPI` 卷示例](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。
更多详细信息请参考 [`downwardAPI` 卷示例](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。
### emptyDir
@ -612,7 +612,7 @@ backed volumes are sized to 50% of the memory on a Linux host.
-->
{{< note >}}
当启用 `SizeMemoryBackedVolumes` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
当启用 `SizeMemoryBackedVolumes` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)
时，你可以为基于内存提供的卷指定大小。
如果未指定大小，则基于内存的卷的大小为 Linux 主机上内存的 50％。
{{< /note>}}
@ -818,7 +818,7 @@ Before creating a PersistentVolume, you must create the PD:
-->
#### 手动供应基于区域 PD 的 PersistentVolume {#manually-provisioning-regional-pd-pv}
使用[为 GCE PD 定义的存储类](/zh/docs/concepts/storage/storage-classes/#gce)
使用[为 GCE PD 定义的存储类](/zh-cn/docs/concepts/storage/storage-classes/#gce)
可以实现动态供应。在创建 PersistentVolume 之前，你首先要创建 PD。
```shell
@ -1063,7 +1063,7 @@ Watch out when using this type of volume, because:
* 具有相同配置（例如基于同一 PodTemplate 创建）的多个 Pod
会由于节点上文件的不同而在不同节点上有不同的行为。
* 下层主机上创建的文件或目录只能由 root 用户写入。你需要在
[特权容器](/zh/docs/tasks/configure-pod-container/security-context/)
[特权容器](/zh-cn/docs/tasks/configure-pod-container/security-context/)
中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。
<!--
@ -1264,7 +1264,7 @@ such as node resource requirements, node selectors, Pod affinity, and Pod anti-a
-->
使用 `local` 卷时，建议创建一个 StorageClass 并将其 `volumeBindingMode` 设置为
`WaitForFirstConsumer`。要了解更多详细信息，请参考
[local StorageClass 示例](/zh/docs/concepts/storage/storage-classes/#local)。
[local StorageClass 示例](/zh-cn/docs/concepts/storage/storage-classes/#local)。
延迟卷绑定的操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时，会评估
Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod亲和性和 Pod 反亲和性。
@ -1324,7 +1324,7 @@ A `persistentVolumeClaim` volume is used to mount a
are a way for users to "claim" durable storage (such as a GCE PersistentDisk or an
iSCSI volume) without knowing the details of the particular cloud environment.
-->
`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。
`persistentVolumeClaim` 卷用来将[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。
持久卷申领（PersistentVolumeClaim）是用户在不知道特定云环境细节的情况下“申领”持久存储（例如
GCE PersistentDisk 或者 iSCSI 卷）的一种方法。
@ -1332,7 +1332,7 @@ GCE PersistentDisk 或者 iSCSI 卷）的一种方法。
See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/) for more
details.
-->
更多详情请参考[持久卷示例](/zh/docs/concepts/storage/persistent-volumes/)。
更多详情请参考[持久卷示例](/zh-cn/docs/concepts/storage/persistent-volumes/)。
### portworxVolume {#portworxvolume}
@ -1395,7 +1395,7 @@ For more details, see the [Portworx volume](https://github.com/kubernetes/exampl
A projected volume maps several existing volume sources into the same
directory. For more details, see [projected volumes](/docs/concepts/storage/projected-volumes/).
-->
投射卷能将若干现有的卷来源映射到同一目录上。更多详情请参考[投射卷](/zh/docs/concepts/storage/projected-volumes/)。
投射卷能将若干现有的卷来源映射到同一目录上。更多详情请参考[投射卷](/zh-cn/docs/concepts/storage/projected-volumes/)。
### quobyte (已弃用) {#quobyte}
@ -1483,7 +1483,7 @@ must be enabled.
`rbd.csi.ceph.com` {{<glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序。
要使用该特性，必须在集群内安装
[Ceph CSI 驱动](https://github.com/ceph/ceph-csi)，并启用 `CSIMigration` 和 `csiMigrationRBD`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
<!--
As a Kubernetes cluster operator that administers storage, here are the
@ -1546,7 +1546,7 @@ receive Secret updates.
<!--
For more details, see [Configuring Secrets](/docs/concepts/configuration/secret/).
-->
更多详情请参考[配置 Secrets](/zh/docs/concepts/configuration/secret/)。
更多详情请参考[配置 Secrets](/zh-cn/docs/concepts/configuration/secret/)。
### storageOS (已弃用) {#storageos}
@ -1666,7 +1666,7 @@ must be installed on the cluster and the `CSIMigration` and `CSIMigrationvSphere
为了使用此功能特性，必须在集群中安装
[vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)，并启用
`CSIMigration` 和 `CSIMigrationvSphere`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
<!--
You can find additional advice on how to migrate in VMware's
@ -1875,7 +1875,7 @@ To learn about requesting space using a resource specification, see
[how to manage resources](/docs/concepts/configuration/manage-resources-containers/).
-->
要了解如何使用资源规约来请求空间，可参考
[如何管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。
[如何管理资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。
<!--
@ -1969,9 +1969,9 @@ if the driver supports that (beta feature)
`csi` 卷可以在 Pod 中以三种方式使用：
* 通过 PersistentVolumeClaim(#persistentvolumeclaim) 对象引用
* 使用[一般性的临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)
* 使用[一般性的临时卷](/zh-cn/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume)
（Alpha 特性）
* 使用 [CSI 临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)，
* 使用 [CSI 临时卷](/zh-cn/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)，
前提是驱动支持这种用法（Beta 特性）
<!--
@ -2101,7 +2101,7 @@ You can set up your
[PersistentVolume/PersistentVolumeClaim with raw block volume support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support) as usual, without any CSI specific changes.
-->
你可以和以前一样，安装自己的
[带有原始块卷支持的 PV/PVC](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)，
[带有原始块卷支持的 PV/PVC](/zh-cn/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)，
采用 CSI 对此过程没有影响。
<!--
@ -2120,7 +2120,7 @@ for more information.
-->
你可以直接在 Pod 规约中配置 CSI 卷。采用这种方式配置的卷都是临时卷，
无法在 Pod 重新启动后继续存在。
进一步的信息可参阅[临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)。
进一步的信息可参阅[临时卷](/zh-cn/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)。
<!--
For more information on how to develop a CSI driver, refer to the
@ -2359,5 +2359,5 @@ sudo systemctl restart docker
<!--
Follow an example of [deploying WordPress and MySQL with Persistent Volumes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/).
-->
参考[使用持久卷部署 WordPress 和 MySQL](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。
参考[使用持久卷部署 WordPress 和 MySQL](/zh-cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。

18
content/zh-cn/docs/concepts/storage/windows-storage.md
View File

@ -72,7 +72,7 @@ As a result, the following storage functionality is not supported on Windows nod
* 块设备映射
* 内存作为存储介质（例如 `emptyDir.medium` 设置为 `Memory`）
* 类似 UID/GID、各用户不同的 Linux 文件系统访问许可等文件系统特性
* 使用 [DefaultMode 设置 Secret 权限](/zh/docs/concepts/configuration/secret/#secret-files-permissions)
* 使用 [DefaultMode 设置 Secret 权限](/zh-cn/docs/concepts/configuration/secret/#secret-files-permissions)
（因为该特性依赖 UID/GID）
* 基于 NFS 的存储和卷支持
* 扩展已挂载卷（resizefs）
@ -97,7 +97,7 @@ Volume management components are shipped as Kubernetes volume
[plugin](/docs/concepts/storage/volumes/#types-of-volumes).
The following broad classes of Kubernetes volume plugins are supported on Windows:
-->
卷管理组件作为 Kubernetes 卷[插件](/zh/docs/concepts/storage/volumes/#types-of-volumes)发布。
卷管理组件作为 Kubernetes 卷[插件](/zh-cn/docs/concepts/storage/volumes/#types-of-volumes)发布。
Windows 支持以下类型的 Kubernetes 卷插件：
<!--
@ -105,9 +105,9 @@ Windows 支持以下类型的 Kubernetes 卷插件：
* Please note that FlexVolumes have been deprecated as of 1.23
* [`CSI Plugins`](/docs/concepts/storage/volumes/#csi)
-->
* [`FlexVolume plugins`](/zh/docs/concepts/storage/volumes/#flexVolume)
* [`FlexVolume plugins`](/zh-cn/docs/concepts/storage/volumes/#flexVolume)
* 请注意自 1.23 版本起，FlexVolume 已被弃用
* [`CSI Plugins`](/zh/docs/concepts/storage/volumes/#csi)
* [`CSI Plugins`](/zh-cn/docs/concepts/storage/volumes/#csi)
<!--
##### In-tree volume plugins
@ -125,8 +125,8 @@ The following in-tree plugins support persistent storage on Windows nodes:
* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk)
* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume)
-->
* [`awsElasticBlockStore`](/zh/docs/concepts/storage/volumes/#awselasticblockstore)
* [`azureDisk`](/zh/docs/concepts/storage/volumes/#azuredisk)
* [`azureFile`](/zh/docs/concepts/storage/volumes/#azurefile)
* [`gcePersistentDisk`](/zh/docs/concepts/storage/volumes/#gcepersistentdisk)
* [`vsphereVolume`](/zh/docs/concepts/storage/volumes/#vspherevolume)
* [`awsElasticBlockStore`](/zh-cn/docs/concepts/storage/volumes/#awselasticblockstore)
* [`azureDisk`](/zh-cn/docs/concepts/storage/volumes/#azuredisk)
* [`azureFile`](/zh-cn/docs/concepts/storage/volumes/#azurefile)
* [`gcePersistentDisk`](/zh-cn/docs/concepts/storage/volumes/#gcepersistentdisk)
* [`vsphereVolume`](/zh-cn/docs/concepts/storage/volumes/#vspherevolume)

26
content/zh-cn/docs/concepts/windows/intro.md
View File

@ -92,7 +92,7 @@ including:
* 巨页（HugePages）：Windows 容器当前不支持。
* 特权容器：Windows 容器当前不支持。
[HostProcess 容器](/zh/docs/tasks/configure-pod-container/create-hostprocess-pod/)提供类似功能。
[HostProcess 容器](/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod/)提供类似功能。
* TerminationGracePeriod：需要 containerD。
<!--
@ -156,7 +156,7 @@ Kubernetes 关键组件在 Windows 上的工作方式与在 Linux 上相同。
for all containers. If any of these fields is specified, the Pod will
not be admited by the API server.
-->
* [Pod](/zh/docs/concepts/workloads/pods/)
* [Pod](/zh-cn/docs/concepts/workloads/pods/)
Pod 是 Kubernetes 的基本构建块，是可以创建或部署的最小和最简单的单元。
你不可以在同一个 Pod 中部署 Windows 和 Linux 容器。
@ -220,7 +220,7 @@ Kubernetes 关键组件在 Windows 上的工作方式与在 Linux 上相同。
* {{< glossary_tooltip text="Services" term_id="service" >}}
See [Load balancing and Services](#load-balancing-and-services) for more details.
-->
* [工作负载资源](/zh/docs/concepts/workloads/controllers/)包括：
* [工作负载资源](/zh-cn/docs/concepts/workloads/controllers/)包括：
* ReplicaSet
* Deployment
@ -281,14 +281,14 @@ Some kubelet command line options behave differently on Windows, as described be
* The kubelet does not take OOM eviction actions
-->
* `--windows-priorityclass` 允许你设置 kubelet 进程的调度优先级
（参考 [CPU 资源管理](/zh/docs/concepts/configuration/windows-resource-management/#resource-management-cpu)）。
（参考 [CPU 资源管理](/zh-cn/docs/concepts/configuration/windows-resource-management/#resource-management-cpu)）。
* `--kubelet-reserve`、`--system-reserve` 和 `--eviction-hard` 标志更新
[NodeAllocatable](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)。
[NodeAllocatable](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)。
* 未实现使用 `--enforce-node-allocable` 驱逐。
* 未实现使用 `--eviction-hard` 和 `--eviction-soft` 驱逐。
* 在 Windows 节点上运行时，kubelet 没有内存或 CPU 限制。
`--kube-reserved` 和 `--system-reserved` 仅从 `NodeAllocatable` 中减去，并且不保证为工作负载提供的资源。
有关更多信息，请参考 [Windows 节点的资源管理](/zh/docs/concepts/configuration/windows-resource-management/#resource-reservation)。
有关更多信息，请参考 [Windows 节点的资源管理](/zh-cn/docs/concepts/configuration/windows-resource-management/#resource-reservation)。
* 未实现 `MemoryPressure` 条件。
* kubelet 不会执行 OOM 驱逐操作。
@ -419,7 +419,7 @@ work between Windows and Linux:
-->
* `securityContext.runAsNonRoot` -
此设置将阻止以 `ContainerAdministrator` 身份运行容器，这是 Windows 上与 root 用户最接近的身份。
* `securityContext.runAsUser` - 改用 [`runAsUserName`](/zh/docs/tasks/configure-pod-container/configure-runasusername)。
* `securityContext.runAsUser` - 改用 [`runAsUserName`](/zh-cn/docs/tasks/configure-pod-container/configure-runasusername)。
* `securityContext.seLinuxOptions` - 不能在 Windows 上使用，因为 SELinux 特定于 Linux。
* `terminationMessagePath` - 这个字段有一些限制，因为 Windows 不支持映射单个文件。
默认值为 `/dev/termination-log`，因为默认情况下它在 Windows 上不存在，所以能生效。
@ -499,7 +499,7 @@ For more information, visit the project's [GitHub page](https://github.com/kuber
-->
## 节点问题检测器 {#node-problem-detector}
节点问题检测器（参考[节点健康监测](/zh/docs/tasks/debug/debug-cluster/monitor-node-health/)）初步支持 Windows。
节点问题检测器（参考[节点健康监测](/zh-cn/docs/tasks/debug/debug-cluster/monitor-node-health/)）初步支持 Windows。
有关更多信息，请访问该项目的 [GitHub 页面](https://github.com/kubernetes/node-problem-detector#windows)。
<!--
@ -582,7 +582,7 @@ Learn how to [install ContainerD on a Windows node](/docs/setup/production-envir
对于运行 Windows 的 Kubernetes 节点，你可以使用
{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+ 作为容器运行时。
学习如何[在 Windows 上安装 ContainerD](/zh/docs/setup/production-environment/container-runtimes/#install-containerd)。
学习如何[在 Windows 上安装 ContainerD](/zh-cn/docs/setup/production-environment/container-runtimes/#install-containerd)。
<!--
There is a [known limitation](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)
@ -591,7 +591,7 @@ kernel patch.
-->
{{< note >}}
将 GMSA 和 containerd 一起用于访问 Windows
网络共享时存在[已知限制](/zh/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)，
网络共享时存在[已知限制](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)，
这需要一个内核补丁。
{{< /note >}}
@ -637,7 +637,7 @@ Windows Server SAC release
<!--
The Kubernetes [version-skew policy](/docs/setup/release/version-skew-policy/) also applies.
-->
也适用 Kubernetes [版本偏差策略](/zh/docs/setup/release/version-skew-policy/)。
也适用 Kubernetes [版本偏差策略](/zh-cn/docs/setup/release/version-skew-policy/)。
<!--
## Getting help and troubleshooting {#troubleshooting}
@ -655,7 +655,7 @@ SIG Windows [contributing guide on gathering logs](https://github.com/kubernetes
-->
## 获取帮助和故障排查 {#troubleshooting}
对 Kubernetes 集群进行故障排查的主要帮助来源应始于[故障排查](/zh/docs/tasks/debug/)页面。
对 Kubernetes 集群进行故障排查的主要帮助来源应始于[故障排查](/zh-cn/docs/tasks/debug/)页面。
本节包括了一些其他特定于 Windows 的故障排查帮助。
日志是解决 Kubernetes 中问题的重要元素。
@ -698,7 +698,7 @@ The Kubernetes [cluster API](https://cluster-api.sigs.k8s.io/) project also prov
### 部署工具 {#deployment-tools}
kubeadm 工具帮助你部署 Kubernetes 集群，提供管理集群的控制平面以及运行工作负载的节点。
[添加 Windows 节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)阐述了如何使用
[添加 Windows 节点](/zh-cn/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)阐述了如何使用
kubeadm 将 Windows 节点部署到你的集群。
Kubernetes [集群 API](https://cluster-api.sigs.k8s.io/) 项目也提供了自动部署 Windows 节点的方式。

14
content/zh-cn/docs/concepts/windows/user-guide.md
View File

@ -47,9 +47,9 @@ The example in the section below is provided to jumpstart your experience with W
-->
## 在你开始之前 {#before-you-begin}
* 创建一个 Kubernetes 集群，其中包含一个控制平面和一个[运行 Windows Server 的工作节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
* 创建一个 Kubernetes 集群，其中包含一个控制平面和一个[运行 Windows Server 的工作节点](/zh-cn/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
* 务必请注意，在 Kubernetes 上创建和部署服务和工作负载的行为方式与 Linux 和 Windows 容器的行为方式大致相同。
与集群交互的 [kubectl 命令](/zh/docs/reference/kubectl/)是一致的。
与集群交互的 [kubectl 命令](/zh-cn/docs/reference/kubectl/)是一致的。
下一小节的示例旨在帮助你快速开始使用 Windows 容器。
<!--
@ -164,7 +164,7 @@ port 80 of the container directly to the Service.
在 Pod 之间（以及跨主机，如果你有多个 Windows 节点）互 ping
* Service 到 Pod 的通信，在 Linux 控制平面节点以及独立的 Pod 中执行 `curl`
访问虚拟的服务 IP（在 `kubectl get services` 下查看）
* 服务发现，使用 Kubernetes [默认 DNS 后缀](/zh/docs/concepts/services-networking/dns-pod-service/#services)的服务名称，
* 服务发现，使用 Kubernetes [默认 DNS 后缀](/zh-cn/docs/concepts/services-networking/dns-pod-service/#services)的服务名称，
用 `curl` 访问服务名称
* 入站连接，在 Linux 控制平面节点或集群外的机器上执行 `curl` 来访问 NodePort 服务
* 出站连接，使用 kubectl exec，从 Pod 内部执行 `curl` 访问外部 IP
@ -225,7 +225,7 @@ Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasus
### 使用可配置的容器用户名 {#using-configurable-container-usernames}
Windows 容器可以配置为使用不同于镜像默认值的用户名来运行其入口点和进程。
[在这里](/zh/docs/tasks/configure-pod-container/configure-runasusername/)了解更多信息。
[在这里](/zh-cn/docs/tasks/configure-pod-container/configure-runasusername/)了解更多信息。
<!--
### Managing Workload Identity with Group Managed Service Accounts
@ -242,7 +242,7 @@ Windows 容器工作负载可以配置为使用组托管服务帐户（Group Man
组托管服务帐户是一种特定类型的活动目录（Active Directory）帐户，可提供自动密码管理、
简化的服务主体名称（Service Principal Name，SPN）管理，以及将管理委派给多个服务器上的其他管理员的能力。
配置了 GMSA 的容器可以携带使用 GMSA 配置的身份访问外部活动目录域资源。
在[此处](/zh/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 Windows 容器配置和使用 GMSA 的更多信息。
在[此处](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 Windows 容器配置和使用 GMSA 的更多信息。
<!--
## Taints and Tolerations
@ -263,7 +263,7 @@ to Windows.
用户需要使用某种污点（Taint）和节点选择器的组合，以便将 Linux 和 Windows 工作负载各自调度到特定操作系统的节点。
下面概述了推荐的方法，其主要目标之一是该方法不应破坏现有 Linux 工作负载的兼容性。
如果启用了 `IdentifyPodOS` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)，
如果启用了 `IdentifyPodOS` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)，
你可以（并且应该）将 Pod 的 `.spec.os.name` 设置为该 Pod 中的容器设计所用于的操作系统。
对于运行 Linux 容器的 Pod，将 `.spec.os.name` 设置为 `linux`。
对于运行 Windows 容器的 Pod，将 `.spec.os.name` 设置为 `Windows`。
@ -287,7 +287,7 @@ so taints and tolerations and node selectors are still required
to ensure that the Windows pods land onto appropriate Windows nodes.
-->
调度器在将 Pod 分配到节点时并不使用 `.spec.os.name` 的值。
你应该使用正常的 Kubernetes 机制[将 Pod 分配给节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)，
你应该使用正常的 Kubernetes 机制[将 Pod 分配给节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)，
以确保集群的控制平面将 Pod 放置到运行适当操作系统的节点上。
`.spec.os.name` 值对 Windows Pod 的调度没有影响，

38
content/zh-cn/docs/concepts/workloads/_index.md
View File

@ -26,7 +26,7 @@ Pod is running means that all the Pods on that node fail. Kubernetes treats that
of failure as final: you would need to create a new Pod even if the node later recovers.
-->
无论你的负载是单一组件还是由多个一同工作的组件构成，在 Kubernetes 中你
可以在一组 [Pods](/zh/docs/concepts/workloads/pods) 中运行它。
可以在一组 [Pods](/zh-cn/docs/concepts/workloads/pods) 中运行它。
在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组
{{< glossary_tooltip text="容器" term_id="container" >}}。
@ -37,7 +37,7 @@ For example, once a pod is running in your cluster then a critical fault on the
all the pods on that node fail. Kubernetes treats that level of failure as final: you
would need to create a new `Pod` to recover, even if the node later becomes healthy.
-->
Kubernetes Pods 有[确定的生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)。
Kubernetes Pods 有[确定的生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)。
例如，当某 Pod 在你的集群中运行时，Pod 运行所在的
{{< glossary_tooltip text="节点" term_id="node" >}} 出现致命错误时，
所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态：
@ -72,15 +72,15 @@ Kubernetes 提供若干种内置的工作负载资源：
`Pods` for that `StatefulSet`, can replicate data to other `Pods` in the same `StatefulSet`
to improve overall resilience.
-->
* [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 和
[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)
* [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 和
[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/)
（替换原来的资源 {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}）。
`Deployment` 很适合用来管理你的集群上的无状态应用，`Deployment` 中的所有
`Pod` 都是相互等价的，并且在需要的时候被换掉。
* [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)
* [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)
让你能够运行一个或者多个以某种方式跟踪应用状态的 Pods。
例如，如果你的负载会将数据作持久存储，你可以运行一个 `StatefulSet`，将每个
`Pod` 与某个 [`PersistentVolume`](/zh/docs/concepts/storage/persistent-volumes/)
`Pod` 与某个 [`PersistentVolume`](/zh-cn/docs/concepts/storage/persistent-volumes/)
对应起来。你在 `StatefulSet` 中各个 `Pod` 内运行的代码可以将数据复制到同一
`StatefulSet` 中的其它 `Pod` 中以提高整体的服务可靠性。
<!--
@ -95,14 +95,14 @@ Kubernetes 提供若干种内置的工作负载资源：
define tasks that run to completion and then stop. Jobs represent one-off tasks, whereas
`CronJobs` recur according to a schedule.
-->
* [DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/)
* [DaemonSet](/zh-cn/docs/concepts/workloads/controllers/daemonset/)
定义提供节点本地支撑设施的 `Pods`。这些 Pods 可能对于你的集群的运维是
非常重要的，例如作为网络链接的辅助工具或者作为网络
{{< glossary_tooltip text="插件" term_id="addons" >}}
的一部分等等。每次你向集群中添加一个新节点时，如果该节点与某 `DaemonSet`
的规约匹配，则控制面会为该 `DaemonSet` 调度一个 `Pod` 到该新节点上运行。
* [Job](/zh/docs/concepts/workloads/controllers/job/) 和
[CronJob](/zh/docs/concepts/workloads/controllers/cron-jobs/)。
* [Job](/zh-cn/docs/concepts/workloads/controllers/job/) 和
[CronJob](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)。
定义一些一直运行到结束并停止的任务。`Job` 用来表达的是一次性的任务，而
`CronJob` 会根据其时间规划反复运行。
@ -117,7 +117,7 @@ then you can implement or install an extension that does provide that feature.
-->
在庞大的 Kubernetes 生态系统中，你还可以找到一些提供额外操作的第三方
工作负载资源。通过使用
[定制资源定义（CRD）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)，
[定制资源定义（CRD）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)，
你可以添加第三方工作负载资源，以完成原本不是 Kubernetes 核心功能的工作。
例如，如果你希望运行一组 `Pods`，但要求所有 Pods 都可用时才执行操作
（比如针对某种高吞吐量的分布式任务），你可以实现一个能够满足这一需求
@ -135,18 +135,18 @@ As well as reading about each resource, you can learn about specific tasks that
-->
除了阅读了解每类资源外，你还可以了解与这些资源相关的任务：
* [使用 Deployment 运行一个无状态的应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
* 以[单实例](/zh/docs/tasks/run-application/run-single-instance-stateful-application/)
或者[多副本集合](/zh/docs/tasks/run-application/run-replicated-stateful-application/)
* [使用 Deployment 运行一个无状态的应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)
* 以[单实例](/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application/)
或者[多副本集合](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)
的形式运行有状态的应用；
* [使用 `CronJob` 运行自动化的任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/)
* [使用 `CronJob` 运行自动化的任务](/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs/)
<!--
To learn about Kubernetes' mechanisms for separating code from configuration,
visit [Configuration](/docs/concepts/configuration/).
-->
要了解 Kubernetes 将代码与配置分离的实现机制，可参阅
[配置部分](/zh/docs/concepts/configuration/)。
[配置部分](/zh-cn/docs/concepts/configuration/)。
<!--
There are two supporting concepts that provide backgrounds about how Kubernetes manages pods
@ -158,9 +158,9 @@ for applications:
-->
关于 Kubernetes 如何为应用管理 Pods，还有两个支撑概念能够提供相关背景信息：
* [垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)机制负责在
* [垃圾收集](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/)机制负责在
对象的 _属主资源_ 被删除时在集群中清理这些对象。
* [_Time-to-Live_ 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)
* [_Time-to-Live_ 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)
会在 Job 结束之后的指定时间间隔之后删除它们。
<!--
@ -169,6 +169,6 @@ a [`Service`](/docs/concepts/services-networking/service/) or, for web applicati
using an [`Ingress`](/docs/concepts/services-networking/ingress).
-->
一旦你的应用处于运行状态，你就可能想要以
[`Service`](/zh/docs/concepts/services-networking/service/)
[`Service`](/zh-cn/docs/concepts/services-networking/service/)
的形式使之可在互联网上访问；或者对于 Web 应用而言，使用
[`Ingress`](/zh/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。
[`Ingress`](/zh-cn/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。

28
content/zh-cn/docs/concepts/workloads/controllers/deployment.md
View File

@ -1063,7 +1063,7 @@ Assuming [horizontal Pod autoscaling](/docs/tasks/run-application/horizontal-pod
in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of
Pods you want to run based on the CPU utilization of your existing Pods.
-->
假设集群启用了[Pod 的水平自动缩放](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)，
假设集群启用了[Pod 的水平自动缩放](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)，
你可以为 Deployment 设置自动缩放器，并基于现有 Pod 的 CPU 利用率选择要运行的
Pod 个数下限和上限。
@ -1854,7 +1854,7 @@ can create multiple Deployments, one for each release, following the canary patt
## 金丝雀部署 {#canary-deployment}
如果要使用 Deployment 向用户子集或服务器子集上线版本，
则可以遵循[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
则可以遵循[资源管理](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)
所描述的金丝雀模式，创建多个 Deployment，每个版本一个。
<!--
@ -1868,8 +1868,8 @@ configuring containers, and [using kubectl to manage resources](/docs/concepts/o
## 编写 Deployment 规约 {#writing-a-deployment-spec}
同其他 Kubernetes 配置一样， Deployment 需要 `apiVersion`，`kind` 和 `metadata` 字段。
有关配置文件的其他信息，请参考[部署 Deployment](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、
配置容器和[使用 kubectl 管理资源](/zh/docs/concepts/overview/working-with-objects/object-management/)等相关文档。
有关配置文件的其他信息，请参考[部署 Deployment](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)、
配置容器和[使用 kubectl 管理资源](/zh-cn/docs/concepts/overview/working-with-objects/object-management/)等相关文档。
<!--
The name of a Deployment object must be a valid
@ -1878,7 +1878,7 @@ The name of a Deployment object must be a valid
A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
-->
Deployment 对象的名称必须是合法的
[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)。
Deployment 还需要 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
<!--
@ -1894,7 +1894,7 @@ The `.spec.template` and `.spec.selector` are the only required field of the `.s
The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
-->
`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。
`.spec.template` 是一个 [Pod 模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。
它和 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的语法规则完全相同。
只是这里它是嵌套的，因此不需要 `apiVersion` 或 `kind`。
@ -1909,7 +1909,7 @@ labels and an appropriate restart policy. For labels, make sure not to overlap w
Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is
allowed, which is the default if not specified.
-->
只有 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
只有 [`.spec.template.spec.restartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
等于 `Always` 才是被允许的，这也是在没有指定时的默认设置。
<!--
@ -1936,7 +1936,7 @@ then applying that manifest overwrites the manual scaling that you previously di
If a [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (or any
similar API for horizontal scaling) is managing scaling for a Deployment, don't set `.spec.replicas`.
-->
如果一个 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
如果一个 [HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
（或者其他执行水平扩缩操作的类似 API）在管理 Deployment 的扩缩，
则不要设置 `.spec.replicas`。
@ -1960,7 +1960,7 @@ for the Pods targeted by this Deployment.
### 选择算符 {#selector}
`.spec.selector` 是指定本 Deployment 的 Pod
[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)的必需字段。
[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)的必需字段。
`.spec.selector` 必须匹配 `.spec.template.metadata.labels`，否则请求会被 API 拒绝。
@ -2033,7 +2033,7 @@ replacement will be created immediately (even if the old Pod is still in a Termi
才会创建新版本的 Pod。如果你手动删除一个 Pod，其生命周期是由 ReplicaSet 来控制的，
后者会立即创建一个替换 Pod（即使旧的 Pod 仍然处于 Terminating 状态）。
如果你需要一种“最多 n 个”的 Pod 个数保证，你需要考虑使用
[StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。
[StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)。
{{< /note >}}
<!--
@ -2138,7 +2138,7 @@ a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/
在没有任意容器崩溃情况下的最小就绪时间，
只有超出这个时间 Pod 才被视为可用。默认值为 0（Pod 在准备就绪后立即将被视为可用）。
要了解何时 Pod 被视为就绪，
可参考[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
可参考[容器探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
<!--
### Revision History Limit
@ -2192,11 +2192,11 @@ Deployment 在创建时是默认不会处于暂停状态。
* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
you can use it to manage application availability during disruptions.
-->
* 了解 [Pod](/zh/docs/concepts/workloads/pods)。
* [使用 Deployment 运行一个无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。
* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。
* [使用 Deployment 运行一个无状态应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)。
* `Deployment` 是 Kubernetes REST API 中的一个顶层资源。
阅读 {{< api-reference page="workload-resources/deployment-v1" >}}
对象定义，以了解 Deployment 的 API 细节。
* 阅读 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)
* 阅读 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)
了解如何使用它来在可能出现干扰的情况下管理应用的可用性。

58
content/zh-cn/docs/concepts/workloads/controllers/job.md
View File

@ -193,7 +193,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d
## 编写 Job 规约 {#writing-a-job-spec}
与 Kubernetes 中其他资源的配置类似，Job 也需要 `apiVersion`、`kind` 和 `metadata` 字段。
Job 的名字必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
Job 的名字必须是合法的 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。
Job 配置还需要一个 [`.spec` 节](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
@ -213,14 +213,14 @@ Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-po
Job 的 `.spec` 中只有 `.spec.template` 是必需的字段。
字段 `.spec.template` 的值是一个 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。
字段 `.spec.template` 的值是一个 [Pod 模版](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。
其定义规范与 {{< glossary_tooltip text="Pod" term_id="pod" >}}
完全相同，只是其中不再需要 `apiVersion` 或 `kind` 字段。
除了作为 Pod 所必需的字段之外，Job 中的 Pod 模版必需设置合适的标签
（参见 [Pod 选择算符](#pod-selector)）和合适的重启策略。
Job 中 Pod 的 [`RestartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
Job 中 Pod 的 [`RestartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy)
只能设置为 `Never` 或 `OnFailure` 之一。
<!--
@ -386,7 +386,7 @@ Jobs with _fixed completion count_ - that is, jobs that have non null
当每个索引都对应一个完成完成的 Pod 时，Job 被认为是已完成的。
关于如何使用这种模式的更多信息，可参阅
[用带索引的 Job 执行基于静态任务分配的并行处理](/zh/docs/tasks/job/indexed-parallel-processing-static/)。
[用带索引的 Job 执行基于静态任务分配的并行处理](/zh-cn/docs/tasks/job/indexed-parallel-processing-static/)。
需要注意的是，对同一索引值可能被启动的 Pod 不止一个，尽管这种情况很少发生。
这时，只有一个会被记入完成计数中。
@ -410,7 +410,7 @@ Pod 则继续留在当前节点，但容器会被重新运行。
因此，你的程序需要能够处理在本地被重启的情况，或者要设置
`.spec.template.spec.restartPolicy = "Never"`。
关于 `restartPolicy` 的更多信息，可参阅
[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/#example-states)。
[Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#example-states)。
<!--
An entire Pod can also fail, for a number of reasons, such as when the pod is kicked off the node
@ -574,7 +574,7 @@ Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job its
That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve.
-->
注意 Job 规约和 Job 中的
[Pod 模版规约](/zh/docs/concepts/workloads/pods/init-containers/#detailed-behavior)
[Pod 模版规约](/zh-cn/docs/concepts/workloads/pods/init-containers/#detailed-behavior)
都有 `activeDeadlineSeconds` 字段。
请确保你在合适的层次设置正确的字段。
@ -599,7 +599,7 @@ cleaned up by CronJobs based on the specified capacity-based cleanup policy.
完成的 Job 通常不需要留存在系统中。在系统中一直保留它们会给 API
服务器带来额外的压力。
如果 Job 由某种更高级别的控制器来管理，例如
[CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs/)，
[CronJobs](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)，
则 Job 可以被 CronJob 基于特定的根据容量裁定的清理策略清理掉。
### 已完成 Job 的 TTL 机制 {#ttl-mechanisms-for-finished-jobs}
@ -621,7 +621,7 @@ be honored.
For example:
-->
自动清理已完成 Job （状态为 `Complete` 或 `Failed`）的另一种方式是使用由
[TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)所提供
[TTL 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)所提供
的 TTL 机制。
通过设置 Job 的 `.spec.ttlSecondsAfterFinished` 字段，可以让该控制器清理掉
已结束的资源。
@ -720,10 +720,10 @@ The pattern names are also links to examples and more detailed description.
| 模式 | 单个 Job 对象 | Pods 数少于工作条目数？ | 直接使用应用无需修改? |
| ----- |:-------------:|:-----------------------:|:---------------------:|
| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 有时 |
| [Pod 数量可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | |
| [静态任务分派的带索引的 Job](/zh/docs/tasks/job/indexed-parallel-processing-static) | ✓ | | ✓ |
| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/) | | | ✓ |
| [每工作条目一 Pod 的队列](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/) | ✓ | | 有时 |
| [Pod 数量可变的队列](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/) | ✓ | ✓ | |
| [静态任务分派的带索引的 Job](/zh-cn/docs/tasks/job/indexed-parallel-processing-static) | ✓ | | ✓ |
| [Job 模版扩展](/zh-cn/docs/tasks/job/parallel-processing-expansion/) | | | ✓ |
<!--
When you specify completions with `.spec.completions`, each Pod created by the Job controller
@ -746,10 +746,10 @@ Here, `W` is the number of work items.
| 模式 | `.spec.completions` | `.spec.parallelism` |
| ----- |:-------------------:|:--------------------:|
| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意值 |
| [Pod 个数可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 |
| [静态任务分派的带索引的 Job](/zh/docs/tasks/job/indexed-parallel-processing-static) | W | | 任意值 |
| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 |
| [每工作条目一 Pod 的队列](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意值 |
| [Pod 个数可变的队列](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 |
| [静态任务分派的带索引的 Job](/zh-cn/docs/tasks/job/indexed-parallel-processing-static) | W | | 任意值 |
| [Job 模版扩展](/zh-cn/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 |
<!--
## Advanced usage
@ -912,8 +912,8 @@ on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/
It is enabled by default.
-->
{{< note >}}
为了使用此功能，你必须在 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)上启用
`JobMutableNodeSchedulingDirectives` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
为了使用此功能，你必须在 [API 服务器](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)上启用
`JobMutableNodeSchedulingDirectives` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
默认情况下启用。
{{< /note >}}
@ -1084,10 +1084,10 @@ on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/
and the [controller manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
It is enabled by default.
-->
要使用该行为，你必须为 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
和[控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/)
要使用该行为，你必须为 [API 服务器](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)
和[控制器管理器](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/)
启用 `JobTrackingWithFinalizers`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
默认是启用的。
<!--
@ -1175,11 +1175,11 @@ for pods with `RestartPolicy` equal to `OnFailure` or `Never`.
-->
### 副本控制器 {#replication-controller}
Job 与[副本控制器](/zh/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。
Job 与[副本控制器](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。
副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器），
Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。
正如在 [Pod 生命期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 中讨论的，
正如在 [Pod 生命期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 中讨论的，
`Job` 仅适合于 `restartPolicy` 设置为 `OnFailure` 或 `Never` 的 Pod。
注意：如果 `restartPolicy` 未设置，其默认值是 `Always`。
@ -1230,13 +1230,13 @@ object, but maintains complete control over what Pods are created and how work i
can use to define a series of Jobs that will run based on a schedule, similar to
the UNIX tool `cron`.
-->
* 了解 [Pods](/zh/docs/concepts/workloads/pods)。
* 了解 [Pods](/zh-cn/docs/concepts/workloads/pods)。
* 了解运行 Job 的不同的方式：
* [使用工作队列进行粗粒度并行处理](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/)
* [使用工作队列进行精细的并行处理](/zh/docs/tasks/job/fine-parallel-processing-work-queue/)
* [使用索引作业完成静态工作分配下的并行处理](/zh/docs/tasks/job/indexed-parallel-processing-static/)（Beta 阶段）
* 基于一个模板运行多个 Job：[使用展开的方式进行并行处理](/zh/docs/tasks/job/parallel-processing-expansion/)
* [使用工作队列进行粗粒度并行处理](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/)
* [使用工作队列进行精细的并行处理](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/)
* [使用索引作业完成静态工作分配下的并行处理](/zh-cn/docs/tasks/job/indexed-parallel-processing-static/)（Beta 阶段）
* 基于一个模板运行多个 Job：[使用展开的方式进行并行处理](/zh-cn/docs/tasks/job/parallel-processing-expansion/)
* 跟随[自动清理完成的 Job](#clean-up-finished-jobs-automatically) 文中的链接，了解你的集群如何清理完成和失败的任务。
* `Job` 是 Kubernetes REST API 的一部分。阅读 {{< api-reference page="workload-resources/job-v1" >}}
对象定义理解关于该资源的 API。
* 阅读 [`CronJob`](/zh/docs/concepts/workloads/controllers/cron-jobs/)，它允许你定义一系列定期运行的 Job，类似于 UNIX 工具 `cron`。
* 阅读 [`CronJob`](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)，它允许你定义一系列定期运行的 Job，类似于 UNIX 工具 `cron`。

38
content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md
View File

@ -30,8 +30,8 @@ weight: 90
A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
-->
{{< note >}}
现在推荐使用配置 [`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 的
[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。
现在推荐使用配置 [`ReplicaSet`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 的
[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。
{{< /note >}}
<!--
@ -196,7 +196,7 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun
与所有其它 Kubernetes 配置一样，ReplicationController 需要 `apiVersion`、
`kind` 和 `metadata` 字段。
有关使用配置文件的常规信息，参考
[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。
[对象管理](/zh-cn/docs/concepts/overview/working-with-objects/object-management/)。
ReplicationController 也需要一个 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
@ -211,8 +211,8 @@ The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overv
`.spec.template` 是 `.spec` 的唯一必需字段。
`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。
它的模式与 [Pod](/zh/docs/concepts/workloads/pods/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。
`.spec.template` 是一个 [Pod 模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。
它的模式与 [Pod](/zh-cn/docs/concepts/workloads/pods/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。
<!--
In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
@ -226,10 +226,10 @@ for example the [Kubelet](/docs/admin/kubelet/) or Docker.
除了 Pod 所需的字段外，ReplicationController 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。
对于标签，请确保不与其他控制器重叠。参考 [Pod 选择算符](#pod-selector)。
只允许 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。
只允许 [`.spec.template.spec.restartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。
对于本地容器重启，ReplicationController 委托给节点上的代理，
例如 [Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 或 Docker。
例如 [Kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 或 Docker。
<!--
### Labels on the ReplicationController
@ -256,7 +256,7 @@ deleted. This allows the ReplicationController to be replaced without affecting
-->
### Pod 选择算符 {#pod-selector}
`.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
`.spec.selector` 字段是一个[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
ReplicationController 管理标签与选择算符匹配的所有 Pod。
它不区分它创建或删除的 Pod 和其他人或进程创建或删除的 Pod。
这允许在不影响正在运行的 Pod 的情况下替换 ReplicationController。
@ -323,7 +323,7 @@ When using the REST API or [client library](/docs/reference/using-api/client-lib
kubectl 将 ReplicationController 缩放为 0 并等待以便在删除 ReplicationController 本身之前删除每个 Pod。
如果这个 kubectl 命令被中断，可以重新启动它。
当使用 REST API 或[客户端库](/zh/docs/reference/using-api/client-libraries)时，你需要明确地执行这些步骤（缩放副本为 0、
当使用 REST API 或[客户端库](/zh-cn/docs/reference/using-api/client-libraries)时，你需要明确地执行这些步骤（缩放副本为 0、
等待 Pod 删除，之后删除 ReplicationController 资源）。
<!--
@ -341,7 +341,7 @@ When using the REST API or [client library](/docs/reference/using-api/client-lib
使用 kubectl，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=orphan` 选项。
当使用 REST API 或客户端库(/zh/docs/reference/using-api/client-libraries)时，只需删除 ReplicationController 对象。
当使用 REST API 或客户端库(/zh-cn/docs/reference/using-api/client-libraries)时，只需删除 ReplicationController 对象。
<!--
Once the original is deleted, you can create a new ReplicationController to replace it. As long
@ -416,7 +416,7 @@ Rolling update is implemented in the client tool
这两个 ReplicationController 将需要创建至少具有一个不同标签的 Pod，比如 Pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。
滚动更新是在客户端工具 [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update)
中实现的。访问 [`kubectl rolling-update` 任务](/zh/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。
中实现的。访问 [`kubectl rolling-update` 任务](/zh-cn/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。
<!--
### Multiple release tracks
@ -534,9 +534,9 @@ Note that we recommend using Deployments instead of directly using Replica Sets,
### ReplicaSet
[`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController，
支持新的[基于集合的标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。
它主要被 [`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)
[`ReplicaSet`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController，
支持新的[基于集合的标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。
它主要被 [`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/)
用来作为一种编排 Pod 创建、删除及更新的机制。
请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非
你需要自定义更新编排或根本不需要更新。
@ -550,7 +550,7 @@ because they are declarative, server-side, and have additional features.
-->
### Deployment （推荐）
[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。
[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。
如果你想要这种滚动更新功能，那么推荐使用 Deployment，因为它们是声明式的、服务端的，并且具有其它特性。
<!--
@ -575,7 +575,7 @@ Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead o
### Job
对于预期会自行终止的 Pod (即批处理任务)，使用
[`Job`](/zh/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
[`Job`](/zh-cn/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
<!--
### DaemonSet
@ -588,7 +588,7 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
### DaemonSet
对于提供机器级功能（例如机器监控或机器日志记录）的 Pod，
使用 [`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不是
使用 [`DaemonSet`](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 而不是
ReplicationController。
这些 Pod 的生命期与机器的生命期绑定：它们需要在其他 Pod 启动之前在机器上运行，
并且在机器准备重新启动或者关闭时安全地终止。
@ -605,8 +605,8 @@ ReplicationController。
-->
## {{% heading "whatsnext" %}}
- 了解 [Pods](/zh/docs/concepts/workloads/pods)。
- 了解 [Depolyment](/zh/docs/concepts/workloads/controllers/deployment/)，ReplicationController 的替代品。
- 了解 [Pods](/zh-cn/docs/concepts/workloads/pods)。
- 了解 [Depolyment](/zh-cn/docs/concepts/workloads/controllers/deployment/)，ReplicationController 的替代品。
- `ReplicationController` 是 Kubernetes REST API 的一部分，阅读 {{< api-reference page="workload-resources/replication-controller-v1" >}}
对象定义以了解 replication controllers 的 API。

50
content/zh-cn/docs/concepts/workloads/controllers/statefulset.md
View File

@ -53,8 +53,8 @@ that provides a set of stateless replicas.
在上面描述中，“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的。
如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用
由一组无状态的副本控制器提供的工作负载来部署应用程序，比如
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者
[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/)
[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 或者
[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/)
可能更适用于你的无状态应用部署需要。
<!--
@ -77,7 +77,7 @@ that provides a set of stateless replicas.
基于所请求的 `storage class` 来提供，或者由管理员预先提供。
* 删除或者收缩 StatefulSet 并*不会*删除它关联的存储卷。
这样做是为了保证数据安全，它通常比自动清除 StatefulSet 所有相关的资源更有价值。
* StatefulSet 当前需要[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
* StatefulSet 当前需要[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
来负责 Pod 的网络标识。你需要负责创建此服务。
* 当删除 StatefulSets 时，StatefulSet 不提供任何终止 Pod 的保证。
为了实现 StatefulSet 中的 Pod 可以有序地且体面地终止，可以在删除之前将 StatefulSet
@ -162,9 +162,9 @@ The name of a StatefulSet object must be a valid
* 名为 `nginx` 的 Headless Service 用来控制网络域名。
* 名为 `web` 的 StatefulSet 有一个 Spec，它表明将在独立的 3 个 Pod 副本中启动 nginx 容器。
* `volumeClaimTemplates` 将通过 PersistentVolumes 驱动提供的
[PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
[PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
StatefulSet 的命名需要遵循[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。
StatefulSet 的命名需要遵循[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)规范。
<!--
### Pod Selector
@ -187,7 +187,7 @@ You can set the `.spec.volumeClaimTemplates` which can provide stable storage u
你可以设置 `.spec.volumeClaimTemplates`，
它可以使用 PersistentVolume 制备程序所准备的
[PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
[PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) 来提供稳定的存储。
<!-- ### Minimum ready seconds -->
### 最短就绪秒数 {#minimum-ready-seconds}
@ -207,7 +207,7 @@ available as soon as it is ready). To learn more about when a Pod is considered
请通过取消设置 StatefulSetMinReadySeconds 标志来选择退出。
该字段默认为 0（Pod 准备就绪后将被视为可用）。
要了解有关何时认为 Pod 准备就绪的更多信息，
请参阅[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
请参阅[容器探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。
<!--
## Pod Identity
@ -252,7 +252,7 @@ by the `serviceName` field on the StatefulSet.
StatefulSet 中的每个 Pod 根据 StatefulSet 的名称和 Pod 的序号派生出它的主机名。
组合主机名的格式为`$(StatefulSet 名称)-$(序号)`。
上例将会创建三个名称分别为 `web-0、web-1、web-2` 的 Pod。
StatefulSet 可以使用 [无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
StatefulSet 可以使用 [无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
控制它的 Pod 的网络域。管理域的这个服务的格式为：
`$(服务名称).$(命名空间).svc.cluster.local`，其中 `cluster.local` 是集群域。
一旦每个 Pod 创建成功，就会得到一个匹配的 DNS 子域，格式为：
@ -286,7 +286,7 @@ responsible for the network identity of the pods.
- 直接查询 Kubernetes API（比如，利用 watch 机制）而不是依赖于 DNS 查询
- 缩短 Kubernetes DNS 驱动的缓存时长（通常这意味着修改 CoreDNS 的 ConfigMap，目前缓存时长为 30 秒）
正如[限制](#limitations)中所述，你需要负责创建[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)
正如[限制](#limitations)中所述，你需要负责创建[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)
以便为 Pod 提供网络标识。
<!--
@ -314,7 +314,7 @@ Cluster Domain will be set to `cluster.local` unless
[otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
-->
{{< note >}}
集群域会被设置为 `cluster.local`，除非有[其他配置](/zh/docs/concepts/services-networking/dns-pod-service/)。
集群域会被设置为 `cluster.local`，除非有[其他配置](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。
{{< /note >}}
<!--
@ -371,7 +371,7 @@ The StatefulSet should not specify a `pod.Spec.TerminationGracePeriodSeconds` of
-->
StatefulSet 不应将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0。
这种做法是不安全的，要强烈阻止。更多的解释请参考
[强制删除 StatefulSet Pod](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)。
[强制删除 StatefulSet Pod](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/)。
<!--
When the nginx example above is created, three Pods will be deployed in the order
@ -382,7 +382,7 @@ web-2 is launched, web-2 will not be launched until web-0 is successfully relaun
becomes Running and Ready.
-->
在上面的 nginx 示例被创建后，会按照 web-0、web-1、web-2 的顺序部署三个 Pod。
在 web-0 进入 [Running 和 Ready](/zh/docs/concepts/workloads/pods/pod-lifecycle/)
在 web-0 进入 [Running 和 Ready](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)
状态前不会部署 web-1。在 web-1 进入 Running 和 Ready 状态前不会部署 web-2。
如果 web-1 已经处于 Running 和 Ready 状态，而 web-2 尚未部署，在此期间发生了
web-0 运行失败，那么 web-2 将不会被部署，要等到 web-0 部署完成并进入 Running 和
@ -553,7 +553,7 @@ enabled.
-->
{{< note >}}
`maxUnavailable` 字段处于 Alpha 阶段，仅当 API 服务器启用了 `MaxUnavailableStatefulSet`
[特性门控](/zh/docs/reference/commmand-line-tools-reference/feature-gates/)时才起作用。
[特性门控](/zh-cn/docs/reference/commmand-line-tools-reference/feature-gates/)时才起作用。
{{< /note >}}
<!--
@ -608,7 +608,7 @@ StatefulSet:
在 StatefulSet 的生命周期中，可选字段
`.spec.persistentVolumeClaimRetentionPolicy` 控制是否删除以及如何删除 PVC。
使用该字段，你必须启用 `StatefulSetAutoDeletePVC`
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
启用后，你可以为每个 StatefulSet 配置两个策略：
<!--
@ -692,7 +692,7 @@ policy to `Delete`, an owner reference to the StatefulSet instance is placed on
associated with that StatefulSet.
-->
StatefulSet {{<glossary_tooltip text="控制器" term_id="controller">}}为其 PVC 添加了
[属主引用](/zh/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)，
[属主引用](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)，
这些 PVC 在 Pod 终止后被{{<glossary_tooltip text="垃圾回收器" term_id="garbage-collection">}}删除。
这使 Pod 能够在删除 PVC 之前（以及在删除后备 PV 和卷之前，取决于保留策略）干净地卸载所有卷。
当你设置 `whenDeleted` 删除策略，对 StatefulSet 实例的属主引用放置在与该 StatefulSet 关联的所有 PVC 上。
@ -756,7 +756,7 @@ Statefulset, don't set `.spec.replicas`. Instead, allow the Kubernetes
{{<glossary_tooltip text="control plane" term_id="control-plane" >}} to manage
the `.spec.replicas` field automatically.
-->
如果 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
如果 [HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/)
（或任何类似的水平缩放 API）正在管理 Statefulset 的缩放，
请不要设置 `.spec.replicas`。
相反，允许 Kubernetes 控制平面自动管理 `.spec.replicas` 字段。
@ -779,15 +779,15 @@ the `.spec.replicas` field automatically.
* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
you can use it to manage application availability during disruptions.
-->
* 了解 [Pod](/zh/docs/concepts/workloads/pods)。
* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。
* 了解如何使用 StatefulSet
* 跟随示例[部署有状态应用](/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/)。
* 了解如何[扩缩 StatefulSet](/zh/docs/tasks/run-application/scale-stateful-set/)。
* 了解[删除 StatefulSet](/zh/docs/tasks/run-application/delete-stateful-set/)涉及到的操作。
* 了解如何[配置 Pod 以使用卷进行存储](/zh/docs/tasks/configure-pod-container/configure-volume-storage/)。
* 了解如何[配置 Pod 以使用 PersistentVolume 作为存储](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。
* 跟随示例[部署有状态应用](/zh-cn/docs/tutorials/stateful-application/basic-stateful-set/)。
* 跟随示例[使用 StatefulSet 部署 Cassandra](/zh-cn/docs/tutorials/stateful-application/cassandra/)。
* 跟随示例[运行多副本的有状态应用程序](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)。
* 了解如何[扩缩 StatefulSet](/zh-cn/docs/tasks/run-application/scale-stateful-set/)。
* 了解[删除 StatefulSet](/zh-cn/docs/tasks/run-application/delete-stateful-set/)涉及到的操作。
* 了解如何[配置 Pod 以使用卷进行存储](/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage/)。
* 了解如何[配置 Pod 以使用 PersistentVolume 作为存储](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。
* `StatefulSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/stateful-set-v1" >}}
对象定义理解关于该资源的 API。
* 阅读 [Pod 干扰预算（Disruption Budget）](/zh/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。
* 阅读 [Pod 干扰预算（Disruption Budget）](/zh-cn/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。

8
content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md
View File

@ -37,7 +37,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the
TTL-after-finished 控制器只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished`
字段来自动清理已结束的作业（`Complete` 或 `Failed`），如
[示例](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
[示例](/zh-cn/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
所示。
<!--
@ -72,9 +72,9 @@ The TTL seconds can be set at any time. Here are some examples for setting the
-->
* 在作业清单（manifest）中指定此字段，以便 Job 在完成后的某个时间被自动清除。
* 将此字段设置为现有的、已完成的作业，以采用此新功能。
* 在创建作业时使用 [mutating admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
* 在创建作业时使用 [mutating admission webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
动态设置该字段。集群管理员可以使用它对完成的作业强制执行 TTL 策略。
* 使用 [mutating admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
* 使用 [mutating admission webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
在作业完成后动态设置该字段，并根据作业状态、标签等选择不同的 TTL 值。
<!--
@ -123,6 +123,6 @@ very small. Please be aware of this risk when setting a non-zero TTL.
* [Clean up Jobs automatically](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
* [Design doc](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)
-->
* [自动清理 Job](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
* [自动清理 Job](/zh-cn/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
* [设计文档](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md)

32
content/zh-cn/docs/concepts/workloads/pods/_index.md
View File

@ -52,8 +52,8 @@ during Pod startup. You can also inject
for debugging if your cluster offers this.
-->
除了应用容器，Pod 还可以包含在 Pod 启动期间运行的
[Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。
你也可以在集群中支持[临时性容器](/zh/docs/concepts/workloads/pods/ephemeral-containers/)
[Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)。
你也可以在集群中支持[临时性容器](/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/)
的情况下，为调试的目的注入临时性容器。
<!-- body -->
@ -271,7 +271,7 @@ When you create the manifest for a Pod object, make sure the name specified is a
[DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
-->
当你为 Pod 对象创建清单时，要确保所指定的 Pod 名称是合法的
[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)。
<!--
### Pods and controllers
@ -314,9 +314,9 @@ PodTemplates are specifications for creating Pods, and are included in workload
_Pod 模板（Pod Template）_ 来替你创建 Pod 并管理它们。
Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
[Job](/zh/docs/concepts/workloads/controllers/job/) 和
[DaemonSets](/zh/docs/concepts/workloads/controllers/daemonset/) 等。
[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)、
[Job](/zh-cn/docs/concepts/workloads/controllers/job/) 和
[DaemonSets](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 等。
<!--
Each controller for a workload resource uses the `PodTemplate` inside the workload
@ -462,7 +462,7 @@ Kubernetes implements shared storage and makes it available to Pods.
Pod 中的所有容器都可以访问该共享卷，从而允许这些容器共享数据。
卷还允许 Pod 中的持久数据保留下来，即使其中的容器需要重新启动。
有关 Kubernetes 如何在 Pod 中实现共享存储并将其提供给 Pod 的更多信息，
请参考[卷](/zh/docs/concepts/storage/)。
请参考[卷](/zh-cn/docs/concepts/storage/)。
<!--
### Pod networking
@ -503,7 +503,7 @@ Containers within the Pod see the system hostname as being the same as the confi
section.
-->
Pod 中的容器所看到的系统主机名与为 Pod 配置的 `name` 属性值相同。
[网络](/zh/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。
[网络](/zh-cn/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。
<!--
## Privileged mode for containers
@ -515,14 +515,14 @@ If your cluster has the `WindowsHostProcessContainers` feature enabled, you can
## 容器的特权模式 {#privileged-mode-for-containers}
在 Linux 中，Pod 中的任何容器都可以使用容器规约中的
[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/)中的
[安全性上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)中的
`privileged`（Linux）参数启用特权模式。
这对于想要使用操作系统管理权能（Capabilities，如操纵网络堆栈和访问设备）
的容器很有用。
如果你的集群启用了 `WindowsHostProcessContainers` 特性，你可以使用 Pod 规约中安全上下文的
`windowsOptions.hostProcess` 参数来创建
[Windows HostProcess Pod](/zh/docs/tasks/configure-pod-container/create-hostprocess-pod/)。
[Windows HostProcess Pod](/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod/)。
这些 Pod 中的所有容器都必须以 Windows HostProcess 容器方式运行。
HostProcess Pod 可以直接运行在主机上，它也能像 Linux 特权容器一样，用于执行管理任务。
@ -564,7 +564,7 @@ but cannot be controlled from there.
静态 Pod 通常绑定到某个节点上的 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}。
其主要用途是运行自托管的控制面。
在自托管场景中，使用 `kubelet` 来管理各个独立的
[控制面组件](/zh/docs/concepts/overview/components/#control-plane-components)。
[控制面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components)。
`kubelet` 自动尝试为每个静态 Pod 在 Kubernetes API 服务器上创建一个
{{< glossary_tooltip text="镜像 Pod" term_id="mirror-pod" >}}。
@ -601,7 +601,7 @@ _Probe_ 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubele
- `TCPSocketAction`（由 kubelet 直接检测）
- `HTTPGetAction`（由 kubelet 直接检测）
你可以参阅 Pod 的生命周期文档中的[探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)部分。
你可以参阅 Pod 的生命周期文档中的[探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)部分。
## {{% heading "whatsnext" %}}
@ -616,11 +616,11 @@ _Probe_ 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubele
object definition describes the object in detail.
* [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) explains common layouts for Pods with more than one container.
-->
* 了解 [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)
* 了解 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)，以及如何使用它
* 了解 [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)
* 了解 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)，以及如何使用它
来配置不同的 Pod 使用不同的容器运行时配置
* 了解 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* 了解 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)，以及你
* 了解 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/)
* 了解 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)，以及你
如何可以利用它在出现干扰因素时管理应用的可用性。
* Pod 在 Kubernetes REST API 中是一个顶层资源。
{{< api-reference page="workload-resources/pod-v1" >}}

26
content/zh-cn/docs/concepts/workloads/pods/disruptions.md
View File

@ -60,7 +60,7 @@ an application. Examples are:
- 云提供商或虚拟机管理程序中的故障导致的虚拟机消失
- 内核错误
- 节点由于集群网络隔离从集群中消失
- 由于节点[资源不足](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)导致 pod 被驱逐。
- 由于节点[资源不足](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)导致 pod 被驱逐。
<!--
Except for the out-of-resources condition, all these conditions
@ -98,7 +98,7 @@ Cluster Administrator actions include:
-->
集群管理员操作包括：
- [排空（drain）节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)进行修复或升级。
- [排空（drain）节点](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)进行修复或升级。
- 从集群中排空节点以缩小集群（了解[集群自动扩缩](https://github.com/kubernetes/autoscaler/#readme)）。
- 从节点中移除一个 Pod，以允许其他 Pod 使用该节点。
@ -145,13 +145,13 @@ and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/)
or across zones (if using a
[multi-zone cluster](/docs/setup/multiple-zones).)
-->
- 确保 Pod 在请求中给出[所需资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)。
- 确保 Pod 在请求中给出[所需资源](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/)。
- 如果需要更高的可用性，请复制应用程序。
（了解有关运行多副本的[无状态](/zh/docs/tasks/run-application/run-stateless-application-deployment/)
和[有状态](/zh/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
（了解有关运行多副本的[无状态](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)
和[有状态](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。）
- 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用
[反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
或跨区域（如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
[反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
或跨区域（如果使用[多区域集群](/zh-cn/docs/setup/best-practices/multiple-zones/)）扩展应用程序。
<!--
The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are
@ -170,7 +170,7 @@ in your pod spec can also cause voluntary (and involuntary) disruptions.
实现可能导致碎片整理和紧缩节点的自愿干扰。集群
管理员或托管提供商应该已经记录了各级别的自愿干扰（如果有的话）。
有些配置选项，例如在 pod spec 中
[使用 PriorityClasses](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)
[使用 PriorityClasses](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)
也会产生自愿（和非自愿）的干扰。
<!--
@ -213,7 +213,7 @@ instead of directly deleting pods or deployments. Examples are the `kubectl dra
and the Kubernetes-on-GCE cluster upgrade script (`cluster/gce/upgrade.sh`).
-->
集群管理员和托管提供商应该使用遵循 PodDisruptionBudgets 的接口
（通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
（通过调用[Eviction API](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)），
而不是直接删除 Pod 或 Deployment。
<!--
@ -277,7 +277,7 @@ hornoring the
`terminationGracePeriodSeconds` setting in its [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
-->
当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地
[终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
[终止](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会
参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
中的 `terminationGracePeriodSeconds` 配置值。
@ -506,7 +506,7 @@ the nodes in your cluster, such as a node or system software upgrade, here are s
* Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
including steps to maintain its availability during the rollout.
-->
* 参考[配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。
* 进一步了解[排空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)的信息。
* 了解[更新 Deployment](/zh/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
* 参考[配置 Pod 干扰预算](/zh-cn/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。
* 进一步了解[排空节点](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)的信息。
* 了解[更新 Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
的过程，包括如何在其进程中维持应用的可用性

4
content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md
View File

@ -124,11 +124,11 @@ sharing](/docs/tasks/configure-pod-container/share-process-namespace/) so
you can view processes in other containers.
-->
使用临时容器时，启用
[进程名字空间共享](/zh/docs/tasks/configure-pod-container/share-process-namespace/)
[进程名字空间共享](/zh-cn/docs/tasks/configure-pod-container/share-process-namespace/)
很有帮助，可以查看其他容器中的进程。
{{% heading "whatsnext" %}}
<!--
* Learn how to [debug pods using ephemeral containers](/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container).
-->
* 了解如何[使用临时调试容器来进行调试](/zh/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container)
* 了解如何[使用临时调试容器来进行调试](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container)

28
content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md
View File

@ -45,7 +45,7 @@ or is [terminated](#pod-termination).
Pod 对象的状态包含了一组 [Pod 状况（Conditions）](#pod-conditions)。
如果应用需要的话，你也可以向其中注入[自定义的就绪性信息](#pod-readiness-gate)。
Pod 在其生命周期中只会被[调度](/zh/docs/concepts/scheduling-eviction/)一次。
Pod 在其生命周期中只会被[调度](/zh-cn/docs/concepts/scheduling-eviction/)一次。
一旦 Pod 被调度（分派）到某个节点，Pod 会一直在该节点运行，直到 Pod 停止或者
被[终止](#pod-termination)。
@ -66,7 +66,7 @@ are [scheduled for deletion](#pod-garbage-collection) after a timeout period.
和一个个独立的应用容器一样，Pod 也被认为是相对临时性（而不是长期存在）的实体。
Pod 会被创建、赋予一个唯一的
ID（[UID](/zh/docs/concepts/overview/working-with-objects/names/#uids)），
ID（[UID](/zh-cn/docs/concepts/overview/working-with-objects/names/#uids)），
并被调度到节点，并在终止（根据重启策略）或删除之前一直运行在该节点。
如果一个{{< glossary_tooltip text="节点" term_id="node" >}}死掉了，调度到该节点
@ -182,7 +182,7 @@ There are three possible container states: `Waiting`, `Running`, and `Terminated
## 容器状态 {#container-states}
Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的[阶段](#pod-phase)一样。
你可以使用[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)
你可以使用[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)
来在容器生命周期中的特定时间点触发事件。
一旦{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}将 Pod
@ -306,7 +306,7 @@ Pod 有一个 PodStatus 对象，其中包含一个
-->
* `PodScheduled`：Pod 已经被调度到某节点；
* `ContainersReady`：Pod 中所有容器都已就绪；
* `Initialized`：所有的 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)
* `Initialized`：所有的 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)
都已成功完成；
* `Ready`：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。
@ -383,7 +383,7 @@ status:
The Pod conditions you add must have names that meet the Kubernetes [label key format](/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set).
-->
你所添加的 Pod 状况名称必须满足 Kubernetes
[标签键名格式](/zh/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
[标签键名格式](/zh-cn/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。
<!--
### Status for Pod readiness {#pod-readiness-status}
@ -401,7 +401,7 @@ write code that sets custom Pod conditions for Pod readiness.
如果需要设置 Pod 的 `status.conditions`，应用或者
{{< glossary_tooltip term_id="operator-pattern" text="Operators">}}
需要使用 `PATCH` 操作。
你可以使用 [Kubernetes 客户端库](/zh/docs/reference/using-api/client-libraries/)
你可以使用 [Kubernetes 客户端库](/zh-cn/docs/reference/using-api/client-libraries/)
之一来编写代码，针对 Pod 就绪态设置定制的 Pod 状况。
<!--
@ -434,7 +434,7 @@ a network request.
-->
## 容器探针 {#container-probes}
probe 是由 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
probe 是由 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。
要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。
<!--
@ -484,7 +484,7 @@ Each probe must define exactly one of these four mechanisms:
[gRPC健康检查](https://grpc.io/grpc/core/md_doc_health-checking.html)。
如果响应的状态是 "SERVING"，则认为诊断成功。
gRPC 探针是一个 alpha 特性，只有在你启用了
"GRPCContainerProbe" [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gate/)时才能使用。
"GRPCContainerProbe" [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gate/)时才能使用。
`httpGet`
: 对容器的 IP 地址上指定端口和路径执行 HTTP `GET` 请求。如果响应的状态码大于等于 200
@ -573,7 +573,7 @@ For more information about how to set up a liveness, readiness, or startup probe
see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).
-->
如欲了解如何设置存活态、就绪态和启动探针的进一步细节，可以参阅
[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
[配置存活态、就绪态和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
<!--
#### When should you use a liveness probe?
@ -770,7 +770,7 @@ An example flow:
order. If the order of shutdowns matters, consider using a `preStop` hook to synchronize.
-->
1. 如果 Pod 中的容器之一定义了 `preStop`
[回调](/zh/docs/concepts/containers/container-lifecycle-hooks)，
[回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks)，
`kubelet` 开始在容器内运行该回调逻辑。如果超出体面终止限期时，`preStop` 回调逻辑
仍在运行，`kubelet` 会请求给予该 Pod 的宽限期一次性增加 2 秒钟。
@ -874,7 +874,7 @@ API 服务器直接删除 Pod 对象，这样新的与之同名的 Pod 即可以
在节点侧，被设置为立即终止的 Pod 仍然会在被强行杀死之前获得一点点的宽限时间。
如果你需要强制删除 StatefulSet 的 Pod，请参阅
[从 StatefulSet 中删除 Pod](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)
[从 StatefulSet 中删除 Pod](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/)
的任务文档。
<!--
@ -915,9 +915,9 @@ This avoids a resource leak as Pods are created and terminated over time.
the API reference documentation covering
[`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) for Pod.
-->
* 动手实践[为容器生命周期时间关联处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
* 动手实践[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。
* 动手实践[为容器生命周期时间关联处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。
* 动手实践[配置存活态、就绪态和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。
* 进一步了解[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)。
* 关于 API 中定义的有关 Pod 和容器状态的详细规范信息，
可参阅 API 参考文档中 Pod 的 [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) 字段。

10
content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
View File

@ -76,7 +76,7 @@ graph TB
<!--
Instead of manually applying labels, you can also reuse the [well-known labels](/docs/reference/labels-annotations-taints/) that are created and populated automatically on most clusters.
-->
你可以复用在大多数集群上自动创建和填充的[常用标签](/zh/docs/reference/labels-annotations-taints/)，
你可以复用在大多数集群上自动创建和填充的[常用标签](/zh-cn/docs/reference/labels-annotations-taints/)，
而不是手动添加标签。
<!--
@ -166,7 +166,7 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
in order to use it.
-->
`minDomains` 字段是在 1.24 版本中新增的 alpha 字段。你必须启用
`MinDomainsInPodToplogySpread` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)才能使用它。
`MinDomainsInPodToplogySpread` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)才能使用它。
{{< /note >}}
<!--
@ -187,7 +187,7 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s
- **labelSelector** 用于查找匹配的 Pod。匹配此标签的 Pod 将被统计，
以确定相应拓扑域中 Pod 的数量。
有关详细信息，请参考[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
有关详细信息，请参考[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。
<!--
When a Pod defines more than one `topologySpreadConstraint`, those constraints are ANDed: The kube-scheduler looks for a node for the incoming Pod that satisfies all the constraints.
@ -524,7 +524,7 @@ replication controllers, replica sets or stateful sets that the Pod belongs to.
An example configuration might look like follows:
-->
你可以在 [调度方案（Scheduling Profile）](/zh/docs/reference/scheduling/config/#profiles)
你可以在 [调度方案（Scheduling Profile）](/zh-cn/docs/reference/scheduling/config/#profiles)
中将默认约束作为 `PodTopologySpread` 插件参数的一部分来设置。
约束的设置采用[如前所述的 API](#api)，只是 `labelSelector` 必须为空。
选择算符是根据 Pod 所属的服务、副本控制器、ReplicaSet 或 StatefulSet 来设置的。
@ -553,7 +553,7 @@ profiles:
is disabled by default. It's recommended to use `PodTopologySpread` to achieve similar
behavior.
-->
[`SelectorSpread` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)默认是被禁用的。
[`SelectorSpread` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)默认是被禁用的。
建议使用 `PodTopologySpread` 来实现类似的行为。
{{< /note >}}