diff --git a/content/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes.md b/content/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes.md index 5ad4f62c28..a05e0a4dc2 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes.md @@ -134,5 +134,5 @@ a `disktype=ssd` label. Learn more about [labels and selectors](/docs/concepts/overview/working-with-objects/labels/). --> -进一步了解[标签和选择器](/zh/docs/concepts/overview/working-with-objects/labels/) +进一步了解[标签和选择器](/zh-cn/docs/concepts/overview/working-with-objects/labels/) diff --git a/content/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md b/content/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md index 41f3a64f3b..45e6082a2b 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event.md @@ -126,7 +126,7 @@ unless the Pod's grace period expires. For more details, see --> Kubernetes 在容器结束前立即发送 preStop 事件。除非 Pod 宽限期限超时，Kubernetes 的容器管理逻辑 会一直阻塞等待 preStop 处理函数执行完毕。更多的相关细节，可以参阅 -[Pods 的结束](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。 +[Pods 的结束](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。 -* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。 -* 进一步了解[Pod 的生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)。 +* 进一步了解[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)。 +* 进一步了解[Pod 的生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)。 这篇文章介绍如何给容器配置活跃（Liveness）、就绪（Readiness）和启动（Startup）探测器。 -[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) +[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 使用存活探测器来确定什么时候要重启容器。 例如，存活探测器可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。 重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。 @@ -354,7 +354,7 @@ Here is an example manifest: 如果你的应用实现了 [gRPC 健康检查协议](https://github.com/grpc/grpc/blob/master/doc/health-checking.md)， kubelet 可以配置为使用该协议来执行应用活跃性检查。 你必须启用 `GRPCContainerProbe` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 才能配置依赖于 gRPC 的检查机制。 下面是一个示例清单： @@ -638,7 +638,7 @@ eventual removal of that feature gate. 这一缺陷在 Kubernetes v1.20 版本中得到修复。你可能一直依赖于之前错误的探测行为， 甚至都没有觉察到这一问题的存在，因为默认的超时值是 1 秒钟。 作为集群管理员，你可以在所有的 kubelet 上禁用 `ExecProbeTimeout` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) （将其设置为 `false`），从而恢复之前版本中的运行行为。之后当集群中所有的 exec 探针都设置了 `timeoutSeconds` 参数后，移除此标志重载。 如果你有 Pod 受到此默认 1 秒钟超时值的影响，你应该更新这些 Pod 对应的探针的超时值， @@ -860,7 +860,7 @@ It will be rejected by the API server. * Learn more about [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes). --> -* 进一步了解[容器探针](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 +* 进一步了解[容器探针](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)。 @@ -464,7 +464,7 @@ PersistentVolume are not present on the Pod resource itself. * Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/). * Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). --> -* 进一步了解 [PersistentVolumes](/zh/docs/concepts/storage/persistent-volumes/) +* 进一步了解 [PersistentVolumes](/zh-cn/docs/concepts/storage/persistent-volumes/) * 阅读[持久存储设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md) {{< note >}} -使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes/#using-subpath) +使用 ConfigMap 作为 [subPath](/zh-cn/docs/concepts/storage/volumes/#using-subpath) 的数据卷将不会收到 ConfigMap 更新。 {{< /note >}} @@ -1113,7 +1113,7 @@ The ConfigMap API resource stores configuration data as key-value pairs. The dat ConfigMap API 资源将配置数据存储为键值对。 数据可以在 Pod 中使用，也可以用来提供系统组件（如控制器）的配置。 -ConfigMap 与 [Secret](/zh/docs/concepts/configuration/secret/) 类似， +ConfigMap 与 [Secret](/zh-cn/docs/concepts/configuration/secret/) 类似， 但是提供的是一种处理不含敏感信息的字符串的方法。 用户和系统组件都可以在 ConfigMap 中存储配置数据。 @@ -1123,7 +1123,7 @@ ConfigMaps should reference properties files, not replace them. Think of the Con {{< note >}} ConfigMap 应该引用属性文件，而不是替换它们。可以将 ConfigMap 理解为类似于 Linux `/etc` 目录及其内容的东西。例如，如果你基于 ConfigMap 创建 -[Kubernetes 卷](/zh/docs/concepts/storage/volumes/)，则 ConfigMap +[Kubernetes 卷](/zh-cn/docs/concepts/storage/volumes/)，则 ConfigMap 中的每个数据项都由该数据卷中的某个独立的文件表示。 {{< /note >}} @@ -1220,6 +1220,6 @@ data: -* 浏览[使用 ConfigMap 配置 Redis](/zh/docs/tutorials/configuration/configure-redis-using-configmap/) +* 浏览[使用 ConfigMap 配置 Redis](/zh-cn/docs/tutorials/configuration/configure-redis-using-configmap/) 真实示例。 diff --git a/content/zh-cn/docs/tasks/configure-pod-container/configure-pod-initialization.md b/content/zh-cn/docs/tasks/configure-pod-container/configure-pod-initialization.md index 25f37b8b9c..65166ce246 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/configure-pod-initialization.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/configure-pod-initialization.md @@ -138,8 +138,8 @@ The output shows that nginx is serving the web page that was written by the init * Learn more about [Debugging Init Containers](/docs/tasks/debug/debug-application/debug-init-containers/) --> -* 进一步了解[同一 Pod 中的容器间的通信](/zh/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。 -* 进一步了解 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。 -* 进一步了解[卷](/zh/docs/concepts/storage/volumes/)。 -* 进一步了解 [Init 容器排错](/zh/docs/tasks/debug/debug-application/debug-init-containers/)。 +* 进一步了解[同一 Pod 中的容器间的通信](/zh-cn/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume/)。 +* 进一步了解 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)。 +* 进一步了解[卷](/zh-cn/docs/concepts/storage/volumes/)。 +* 进一步了解 [Init 容器排错](/zh-cn/docs/tasks/debug/debug-application/debug-init-containers/)。 diff --git a/content/zh-cn/docs/tasks/configure-pod-container/configure-projected-volume-storage.md b/content/zh-cn/docs/tasks/configure-pod-container/configure-projected-volume-storage.md index 420d1ea960..e9f49a2127 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/configure-projected-volume-storage.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/configure-projected-volume-storage.md @@ -20,7 +20,7 @@ several existing volume sources into the same directory. Currently, `secret`, `c and `serviceAccountToken` volumes can be projected. --> -本文介绍怎样通过[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。 +本文介绍怎样通过[`projected`](/zh-cn/docs/concepts/storage/volumes/#projected) 卷将现有的多个卷资源挂载到相同的目录。 当前，`secret`、`configMap`、`downwardAPI` 和 `serviceAccountToken` 卷可以被投射。 -* 进一步了解[`projected`](/zh/docs/concepts/storage/volumes/#projected) 卷。 +* 进一步了解[`projected`](/zh-cn/docs/concepts/storage/volumes/#projected) 卷。 * 阅读[一体卷](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)设计文档。 diff --git a/content/zh-cn/docs/tasks/configure-pod-container/configure-runasusername.md b/content/zh-cn/docs/tasks/configure-pod-container/configure-runasusername.md index d6cb133369..65df06ff34 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/configure-runasusername.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/configure-runasusername.md @@ -222,6 +222,6 @@ For more information about these limtations, check [here](https://support.micros * [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts) * [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/) --> -* [Kubernetes 中调度 Windows 容器的指南](/zh/docs/concepts/windows/user-guide/) -* [使用组托管服务帐户（GMSA）管理工作负载身份](/zh/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts) -* [Windows 下 pod 和容器的 GMSA 配置](/zh/docs/tasks/configure-pod-container/configure-gmsa/) +* [Kubernetes 中调度 Windows 容器的指南](/zh-cn/docs/concepts/windows/user-guide/) +* [使用组托管服务帐户（GMSA）管理工作负载身份](/zh-cn/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts) +* [Windows 下 pod 和容器的 GMSA 配置](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/) diff --git a/content/zh-cn/docs/tasks/configure-pod-container/configure-service-account.md b/content/zh-cn/docs/tasks/configure-pod-container/configure-service-account.md index a27261c87f..badb1f5de2 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/configure-service-account.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/configure-service-account.md @@ -73,9 +73,9 @@ In version 1.6+, you can opt out of automounting API credentials for a service a `automountServiceAccountToken: false` on the service account: --> 你可以使用自动挂载给 Pod 的服务账户凭据访问 API， -[访问集群](/zh/docs/tasks/access-application-cluster/access-cluster/)页面中有相关描述。 +[访问集群](/zh-cn/docs/tasks/access-application-cluster/access-cluster/)页面中有相关描述。 服务账户的 API 许可取决于你所使用的 -[鉴权插件和策略](/zh/docs/reference/access-authn-authz/authorization/#authorization-modules)。 +[鉴权插件和策略](/zh-cn/docs/reference/access-authn-authz/authorization/#authorization-modules)。 在 1.6 以上版本中，你可以通过在服务账户上设置 `automountServiceAccountToken: false` 来实现不给服务账号自动挂载 API 凭据： @@ -155,7 +155,7 @@ The name of a ServiceAccount object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> ServiceAccount 对象的名字必须是一个有效的 -[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). -使用名为 [ServiceAccountToken](/zh/docs/concepts/storage/volumes/#projected) 的 +使用名为 [ServiceAccountToken](/zh-cn/docs/concepts/storage/volumes/#projected) 的 ProjectedVolume 类型在 PodSpec 上配置此功能。 要向 Pod 提供具有 "vault" 用户以及两个小时有效期的令牌，可以在 PodSpec 中配置以下内容： @@ -640,7 +640,7 @@ See also: --> 另请参见： -- [服务账号的集群管理员指南](/zh/docs/reference/access-authn-authz/service-accounts-admin/) +- [服务账号的集群管理员指南](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/) - [服务账号签署密钥检索 KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/1393-oidc-discovery) - [OIDC 发现规范](https://openid.net/specs/openid-connect-discovery-1_0.html) diff --git a/content/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage.md b/content/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage.md index 5e5a9907e9..b468a6943e 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage.md @@ -22,7 +22,7 @@ applications, such as key-value stores (such as Redis) and databases. 此页面展示了如何配置 Pod 以使用卷进行存储。 只要容器存在，容器的文件系统就会存在，因此当一个容器终止并重新启动，对该容器的文件系统改动将丢失。 -对于独立于容器的持久化存储，你可以使用[卷](/zh/docs/concepts/storage/volumes/)。 +对于独立于容器的持久化存储，你可以使用[卷](/zh-cn/docs/concepts/storage/volumes/)。 这对于有状态应用程序尤为重要，例如键值存储（如 Redis）和数据库。 ## {{% heading "prerequisites" %}} @@ -44,7 +44,7 @@ restarts. Here is the configuration file for the Pod: ## 为 Pod 配置卷 {#configure-a-volume-for-a-pod} 在本练习中，你将创建一个运行 Pod，该 Pod 仅运行一个容器并拥有一个类型为 -[emptyDir](/zh/docs/concepts/storage/volumes/#emptydir) 的卷， +[emptyDir](/zh-cn/docs/concepts/storage/volumes/#emptydir) 的卷， 在整个 Pod 生命周期中一直存在，即使 Pod 中的容器被终止和重启。以下是 Pod 的配置： {{< codenew file="pods/storage/redis.yaml" >}} @@ -193,5 +193,5 @@ details such as mounting and unmounting the devices on the nodes. See * 参阅 [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)。 * 除了 `emptyDir` 提供的本地磁盘存储外，Kubernetes 还支持许多不同的网络附加存储解决方案， 包括 GCE 上的 PD 和 EC2 上的 EBS，它们是关键数据的首选，并将处理节点上的一些细节， - 例如安装和卸载设备。了解更多详情请参阅[卷](/zh/docs/concepts/storage/volumes/)。 + 例如安装和卸载设备。了解更多详情请参阅[卷](/zh-cn/docs/concepts/storage/volumes/)。 diff --git a/content/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod.md b/content/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod.md index 97029bff8f..abc3896e70 100644 --- a/content/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod.md +++ b/content/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod.md @@ -100,7 +100,7 @@ latest version of containerd (v1.6+) to run HostProcess containers. 在 Kubernetes v{{< skew currentVersion >}} 中，HostProcess 容器功能特性默认是启用的。 kubelet 会直接与 containerd 通信，通过 CRI 将主机进程标志传递过去。 你可以使用 containerd 的最新版本（v1.6+）来运行 HostProcess 容器。 -参阅[如何安装 containerd](/zh/docs/setup/production-environment/container-runtimes/#containerd)。 +参阅[如何安装 containerd](/zh-cn/docs/setup/production-environment/container-runtimes/#containerd)。 -进一步的细节可参阅[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#overview)文档。 +进一步的细节可参阅[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#overview)文档。 启用 Windows HostProcess Pod 需要在 Pod 安全配置中设置合适的选项。 在 [Pod -安全标准](/zh/docs/concepts/security/pod-security-standards)中所定义的策略中， +安全标准](/zh-cn/docs/concepts/security/pod-security-standards)中所定义的策略中， HostProcess Pod 默认是不被 basline 和 restricted 策略支持的。因此建议 HostProcess 运行在与 privileged 模式相看齐的策略下。 @@ -193,11 +193,11 @@ HostProcess 运行在与 privileged 模式相看齐的策略下。 - securityContext.windowsOptions.hostProcess + securityContext.windowsOptions.hostProcess

- Windows Pods 提供运行 + Windows Pods 提供运行 HostProcess 容器的能力，这类容器能够具有对 Windows 节点的特权访问权限。

可选值