From 3ecfa2da5ae71ec8361e85935d5222f9077f1fe1 Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 20:20:11 +0800 Subject: [PATCH] [zh]Update concepts pages(part-4) for links with '/zh/' prefix, using new prefix '/zh-cn/' --- .../concepts/storage/dynamic-provisioning.md | 12 +-- .../concepts/storage/ephemeral-volumes.md | 38 ++++---- .../concepts/storage/persistent-volumes.md | 86 +++++++++---------- .../concepts/storage/projected-volumes.md | 14 +-- .../docs/concepts/storage/storage-capacity.md | 6 +- .../docs/concepts/storage/storage-classes.md | 24 +++--- .../storage/volume-health-monitoring.md | 2 +- .../concepts/storage/volume-pvc-datasource.md | 2 +- .../storage/volume-snapshot-classes.md | 4 +- .../docs/concepts/storage/volume-snapshots.md | 8 +- .../zh-cn/docs/concepts/storage/volumes.md | 44 +++++----- .../docs/concepts/storage/windows-storage.md | 18 ++-- content/zh-cn/docs/concepts/windows/intro.md | 26 +++--- .../zh-cn/docs/concepts/windows/user-guide.md | 14 +-- .../zh-cn/docs/concepts/workloads/_index.md | 38 ++++---- .../workloads/controllers/deployment.md | 28 +++--- .../concepts/workloads/controllers/job.md | 58 ++++++------- .../controllers/replicationcontroller.md | 38 ++++---- .../workloads/controllers/statefulset.md | 50 +++++------ .../workloads/controllers/ttlafterfinished.md | 8 +- .../docs/concepts/workloads/pods/_index.md | 32 +++---- .../concepts/workloads/pods/disruptions.md | 26 +++--- .../workloads/pods/ephemeral-containers.md | 4 +- .../concepts/workloads/pods/pod-lifecycle.md | 28 +++--- .../pods/pod-topology-spread-constraints.md | 10 +-- 25 files changed, 309 insertions(+), 309 deletions(-) diff --git a/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md b/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md index f673dfa5f5..f256992599 100644 --- a/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md +++ b/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md @@ -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/)来表示这些卷。 动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。 @@ -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/)查阅有关存储类的更多信息。 要启用动态供应功能，集群管理员需要为用户预先创建一个或多个 `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 服务端被启用。 -在[多区域](/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)来实现。 diff --git a/content/zh-cn/docs/concepts/storage/ephemeral-volumes.md b/content/zh-cn/docs/concepts/storage/ephemeral-volumes.md index f92c561bdb..2e7c7980df 100644 --- a/content/zh-cn/docs/concepts/storage/ephemeral-volumes.md +++ b/content/zh-cn/docs/concepts/storage/ephemeral-volumes.md @@ -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。 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/) 来限制如何使用此驱动程序。 -就[资源所有权](/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。 -[为 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)。 本文描述 Kubernetes 中的 _持久卷（Persistent Volume）_ 。 -建议先熟悉[卷（Volume）](/zh/docs/concepts/storage/volumes/)的概念。 +建议先熟悉[卷（Volume）](/zh-cn/docs/concepts/storage/volumes/)的概念。 @@ -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/)。 为了基于存储类完成动态的存储供应，集群管理员需要在 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/) 文档。 不过，管理员可以按 -[参考资料](/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 卷 {{< 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) 是否被启用。 卷快照（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 卷插件。 -* 进一步了解[创建持久卷](/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). 本文档描述 Kubernetes 中的*投射卷（Projected Volumes）*。 -建议先熟悉[卷](/zh/docs/concepts/storage/volumes/)概念。 +建议先熟悉[卷](/zh-cn/docs/concepts/storage/volumes/)概念。 @@ -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) ## 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 >}} diff --git a/content/zh-cn/docs/concepts/storage/storage-capacity.md b/content/zh-cn/docs/concepts/storage/storage-capacity.md index 7cf604cf56..c89d98e3bc 100644 --- a/content/zh-cn/docs/concepts/storage/storage-capacity.md +++ b/content/zh-cn/docs/concepts/storage/storage-capacity.md @@ -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 驱动程序使用，并且不需要大量资源。 本文描述了 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)的概念。 @@ -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) 应该发生在什么时候。 -动态配置和预先创建的 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)。 在存储制备期间，为挂载凭证创建一个名为 `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` 权限。 diff --git a/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md b/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md index 0b7f5924a4..bf1c732fd6 100644 --- a/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md +++ b/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md @@ -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 >}} diff --git a/content/zh-cn/docs/concepts/storage/volume-pvc-datasource.md b/content/zh-cn/docs/concepts/storage/volume-pvc-datasource.md index 06454b6234..d50dcdd99c 100644 --- a/content/zh-cn/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/zh-cn/docs/concepts/storage/volume-pvc-datasource.md @@ -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)。 diff --git a/content/zh-cn/docs/concepts/storage/volume-snapshot-classes.md b/content/zh-cn/docs/concepts/storage/volume-snapshot-classes.md index 8739de2d04..47f617fe11 100644 --- a/content/zh-cn/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/zh-cn/docs/concepts/storage/volume-snapshot-classes.md @@ -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)。 diff --git a/content/zh-cn/docs/concepts/storage/volume-snapshots.md b/content/zh-cn/docs/concepts/storage/volume-snapshots.md index d556faafea..719bcfa2a3 100644 --- a/content/zh-cn/docs/concepts/storage/volume-snapshots.md +++ b/content/zh-cn/docs/concepts/storage/volume-snapshots.md @@ -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/)。 @@ -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/) 指定要用的特定于存储提供程序的参数。 更多详细信息，请参阅 -[卷快照和从快照还原卷](/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)。 diff --git a/content/zh-cn/docs/concepts/storage/volumes.md b/content/zh-cn/docs/concepts/storage/volumes.md index b8d0eb94ff..ebe50dd897 100644 --- a/content/zh-cn/docs/concepts/storage/volumes.md +++ b/content/zh-cn/docs/concepts/storage/volumes.md @@ -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/) 必须被启用。 要禁止控制器管理器和 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. -更多详细信息请参考 [`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` 卷。 使用 `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` {{}} 驱动程序。 要使用该特性，必须在集群内安装 [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/)。 -更多详情请参考[配置 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/)。 要了解如何使用资源规约来请求空间，可参考 -[如何管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。 +[如何管理资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。 你可以和以前一样，安装自己的 -[带有原始块卷支持的 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 对此过程没有影响。 你可以直接在 Pod 规约中配置 CSI 卷。采用这种方式配置的卷都是临时卷， 无法在 Pod 重新启动后继续存在。 -进一步的信息可参阅[临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)。 +进一步的信息可参阅[临时卷](/zh-cn/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)。 -参考[使用持久卷部署 WordPress 和 MySQL](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。 +参考[使用持久卷部署 WordPress 和 MySQL](/zh-cn/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。 diff --git a/content/zh-cn/docs/concepts/storage/windows-storage.md b/content/zh-cn/docs/concepts/storage/windows-storage.md index 142fadae0c..697aa22477 100644 --- a/content/zh-cn/docs/concepts/storage/windows-storage.md +++ b/content/zh-cn/docs/concepts/storage/windows-storage.md @@ -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 卷插件： -* [`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) -* [`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) \ No newline at end of file +* [`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) \ No newline at end of file diff --git a/content/zh-cn/docs/concepts/windows/intro.md b/content/zh-cn/docs/concepts/windows/intro.md index fb44b155a3..ce447d4657 100644 --- a/content/zh-cn/docs/concepts/windows/intro.md +++ b/content/zh-cn/docs/concepts/windows/intro.md @@ -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。 -* [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)。 {{< 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 -也适用 Kubernetes [版本偏差策略](/zh/docs/setup/release/version-skew-policy/)。 +也适用 Kubernetes [版本偏差策略](/zh-cn/docs/setup/release/version-skew-policy/)。 ## 获取帮助和故障排查 {#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 节点的方式。 diff --git a/content/zh-cn/docs/concepts/windows/user-guide.md b/content/zh-cn/docs/concepts/windows/user-guide.md index 7b3ab57b62..49d89b9461 100644 --- a/content/zh-cn/docs/concepts/windows/user-guide.md +++ b/content/zh-cn/docs/concepts/windows/user-guide.md @@ -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 容器。 调度器在将 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 的调度没有影响， diff --git a/content/zh-cn/docs/concepts/workloads/_index.md b/content/zh-cn/docs/concepts/workloads/_index.md index a61176f660..5d895415d3 100644 --- a/content/zh-cn/docs/concepts/workloads/_index.md +++ b/content/zh-cn/docs/concepts/workloads/_index.md @@ -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` 中以提高整体的服务可靠性。 -* [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/) 要了解 Kubernetes 将代码与配置分离的实现机制，可参阅 -[配置部分](/zh/docs/concepts/configuration/)。 +[配置部分](/zh-cn/docs/concepts/configuration/)。 关于 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 结束之后的指定时间间隔之后删除它们。 一旦你的应用处于运行状态，你就可能想要以 -[`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) 资源将其暴露到互联网上。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md index 77914f837b..6518588433 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md @@ -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，每个版本一个。 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)。 -`.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` 才是被允许的，这也是在没有指定时的默认设置。 -如果一个 [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 >}} -* 了解 [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/) 了解如何使用它来在可能出现干扰的情况下管理应用的可用性。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/job.md b/content/zh-cn/docs/concepts/workloads/controllers/job.md index 30411c769e..fa647a7067 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/job.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/job.md @@ -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` 之一。 注意 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/) | | | ✓ | {{< 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/)。 默认是启用的。 ### 副本控制器 {#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`。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md b/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md index f83b5d4686..5229fa6d09 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md @@ -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 >}} ### 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 资源）。 ### Deployment （推荐） -[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。 +[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。 如果你想要这种滚动更新功能，那么推荐使用 Deployment，因为它们是声明式的、服务端的，并且具有其它特性。 ## {{% 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。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md b/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md index 22a3cdcca7..72e3d58818 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md @@ -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/) 可能更适用于你的无状态应用部署需要。 ### 最短就绪秒数 {#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)。 {{< note >}} -集群域会被设置为 `cluster.local`，除非有[其他配置](/zh/docs/concepts/services-networking/dns-pod-service/)。 +集群域会被设置为 `cluster.local`，除非有[其他配置](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。 {{< /note >}} 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/)。 在上面的 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 >}} StatefulSet {{}}为其 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 终止后被{{}}删除。 这使 Pod 能够在删除 PVC 之前（以及在删除后备 PV 和卷之前，取决于保留策略）干净地卸载所有卷。 当你设置 `whenDeleted` 删除策略，对 StatefulSet 实例的属主引用放置在与该 StatefulSet 关联的所有 PVC 上。 @@ -756,7 +756,7 @@ Statefulset, don't set `.spec.replicas`. Instead, allow the Kubernetes {{}} 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/)，了解如何在干扰下运行高度可用的应用。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md index 352ddaf83d..7887151b9a 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -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) 所示。 * 在作业清单（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 值。 -* [自动清理 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) diff --git a/content/zh-cn/docs/concepts/workloads/pods/_index.md b/content/zh-cn/docs/concepts/workloads/pods/_index.md index 5eec324a1a..12063e1e84 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/_index.md +++ b/content/zh-cn/docs/concepts/workloads/pods/_index.md @@ -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/) 的情况下，为调试的目的注入临时性容器。 @@ -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)。 Pod 中的容器所看到的系统主机名与为 Pod 配置的 `name` 属性值相同。 -[网络](/zh/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。 +[网络](/zh-cn/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。 -* 了解 [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" >}} diff --git a/content/zh-cn/docs/concepts/workloads/pods/disruptions.md b/content/zh-cn/docs/concepts/workloads/pods/disruptions.md index 8afcb0f696..24e7ac25dc 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh-cn/docs/concepts/workloads/pods/disruptions.md @@ -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 被驱逐。 集群管理员操作包括： -- [排空（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/)）扩展应用程序。 集群管理员和托管提供商应该使用遵循 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。 当使用驱逐 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) 的过程，包括如何在其进程中维持应用的可用性 diff --git a/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md b/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md index 0535b4afe3..a464991304 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md @@ -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" %}} -* 了解如何[使用临时调试容器来进行调试](/zh/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container) +* 了解如何[使用临时调试容器来进行调试](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container) diff --git a/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md b/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md index 3458799573..0841135197 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md @@ -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)。 ## 容器探针 {#container-probes} -probe 是由 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。 +probe 是由 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。 要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。 如欲了解如何设置存活态、就绪态和启动探针的进一步细节，可以参阅 -[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。 +[配置存活态、就绪态和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。 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/) 的任务文档。 -* 动手实践[为容器生命周期时间关联处理程序](/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) 字段。 diff --git a/content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 5c698ac514..40ef623ad6 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -76,7 +76,7 @@ graph TB -你可以复用在大多数集群上自动创建和填充的[常用标签](/zh/docs/reference/labels-annotations-taints/)， +你可以复用在大多数集群上自动创建和填充的[常用标签](/zh-cn/docs/reference/labels-annotations-taints/)， 而不是手动添加标签。 `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 >}} -你可以在 [调度方案（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 >}}