From 5e58c40edfcc1bd3c9a960cbdfc77167eb9bb853 Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 20:15:59 +0800 Subject: [PATCH] [zh]Update concepts pages(part-1) for links with '/zh/' prefix, using new prefix '/zh-cn/' --- .../concepts/architecture/cloud-controller.md | 6 +- .../control-plane-node-communication.md | 14 ++--- .../docs/concepts/architecture/controller.md | 14 ++--- .../zh-cn/docs/concepts/architecture/cri.md | 2 +- .../architecture/garbage-collection.md | 36 ++++++------ .../zh-cn/docs/concepts/architecture/nodes.md | 58 +++++++++---------- .../concepts/cluster-administration/_index.md | 38 ++++++------ .../cluster-administration/certificates.md | 2 +- .../cluster-administration/flow-control.md | 2 +- .../cluster-administration/logging.md | 2 +- .../manage-deployment.md | 22 +++---- .../cluster-administration/networking.md | 6 +- .../cluster-administration/proxies.md | 6 +- .../cluster-administration/system-logs.md | 6 +- .../cluster-administration/system-metrics.md | 6 +- .../cluster-administration/system-traces.md | 4 +- .../docs/concepts/configuration/configmap.md | 16 ++--- .../manage-resources-containers.md | 42 +++++++------- .../organize-cluster-access-kubeconfig.md | 6 +- .../docs/concepts/configuration/overview.md | 36 ++++++------ .../docs/concepts/configuration/secret.md | 54 ++++++++--------- .../windows-resource-management.md | 2 +- .../zh-cn/docs/concepts/containers/_index.md | 6 +- .../containers/container-environment.md | 10 ++-- .../containers/container-lifecycle-hooks.md | 6 +- .../zh-cn/docs/concepts/containers/images.md | 22 +++---- .../docs/concepts/containers/runtime-class.md | 14 ++--- 27 files changed, 219 insertions(+), 219 deletions(-) diff --git a/content/zh-cn/docs/concepts/architecture/cloud-controller.md b/content/zh-cn/docs/concepts/architecture/cloud-controller.md index 05caa7690f..d46b7967ad 100644 --- a/content/zh-cn/docs/concepts/architecture/cloud-controller.md +++ b/content/zh-cn/docs/concepts/architecture/cloud-controller.md @@ -318,10 +318,10 @@ To upgrade a HA control plane to use the cloud controller manager, see [Migrate Want to know how to implement your own cloud controller manager, or extend an existing project? --> -[云控制器管理器的管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) +[云控制器管理器的管理](/zh-cn/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) 给出了运行和管理云控制器管理器的指南。 -要升级 HA 控制平面以使用云控制器管理器，请参见 [将复制的控制平面迁移以使用云控制器管理器](/zh/docs/tasks/administer-cluster/controller-manager-leader-migration/) +要升级 HA 控制平面以使用云控制器管理器，请参见 [将复制的控制平面迁移以使用云控制器管理器](/zh-cn/docs/tasks/administer-cluster/controller-manager-leader-migration/) 想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？ @@ -343,6 +343,6 @@ For more information about developing plugins, see [Developing Cloud Controller 特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。 关于如何开发插件的详细信息，可参考 -[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/) +[开发云控制器管理器](/zh-cn/docs/tasks/administer-cluster/developing-cloud-controller-manager/) 文档。 diff --git a/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md b/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md index 8a92d69f2e..57f05179ed 100644 --- a/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md @@ -33,17 +33,17 @@ Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。 所有从集群（或所运行的 Pods）发出的 API 调用都终止于 API 服务器。 其它控制面组件都没有被设计为可暴露远程服务。 API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求， -并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。 -一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用， -特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-authz/authentication/#anonymous-requests) -或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 +并启用一种或多种形式的客户端[身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/)机制。 +一种或多种客户端[鉴权机制](/zh-cn/docs/reference/access-authn-authz/authorization/)应该被启用， +特别是在允许使用[匿名请求](/zh-cn/docs/reference/access-authn-authz/authentication/#anonymous-requests) +或[服务账号令牌](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。 一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。 -请查看 [kubelet TLS 启动引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) +请查看 [kubelet TLS 启动引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 以了解如何自动提供 kubelet 客户端证书。 在温度计的例子中，如果房间很冷，那么某个控制器可能还会启动一个防冻加热器。 就 Kubernetes 集群而言，控制面间接地与 IP 地址管理工具、存储服务、云驱动 -APIs 以及其他服务协作，通过[扩展 Kubernetes](/zh/docs/concepts/extend-kubernetes/) +APIs 以及其他服务协作，通过[扩展 Kubernetes](/zh-cn/docs/concepts/extend-kubernetes/) 来实现这点。 -* 阅读 [Kubernetes 控制平面组件](/zh/docs/concepts/overview/components/#control-plane-components) -* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) +* 阅读 [Kubernetes 控制平面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components) +* 了解 [Kubernetes 对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/) 的一些基本知识 -* 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) +* 进一步学习 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/) * 如果你想编写自己的控制器，请看 Kubernetes 的 - [扩展模式](/zh/docs/concepts/extend-kubernetes/#extension-patterns)。 + [扩展模式](/zh-cn/docs/concepts/extend-kubernetes/#extension-patterns)。 diff --git a/content/zh-cn/docs/concepts/architecture/cri.md b/content/zh-cn/docs/concepts/architecture/cri.md index 68cd082fc0..c0b3579578 100644 --- a/content/zh-cn/docs/concepts/architecture/cri.md +++ b/content/zh-cn/docs/concepts/architecture/cri.md @@ -46,7 +46,7 @@ flags](/docs/reference/command-line-tools-reference/kubelet) --> 当通过 gRPC 连接到容器运行时时，kubelet 充当客户端。 运行时和镜像服务端点必须在容器运行时中可用，可以使用 -[命令行标志](/zh/docs/reference/command-line-tools-reference/kubelet)的 +[命令行标志](/zh-cn/docs/reference/command-line-tools-reference/kubelet)的 `--image-service-endpoint` 和 `--container-runtime-endpoint` 在 kubelet 中单独配置。 diff --git a/content/zh-cn/docs/concepts/architecture/garbage-collection.md b/content/zh-cn/docs/concepts/architecture/garbage-collection.md index c095601354..d45b98fa8f 100644 --- a/content/zh-cn/docs/concepts/architecture/garbage-collection.md +++ b/content/zh-cn/docs/concepts/architecture/garbage-collection.md @@ -32,16 +32,16 @@ allows the clean up of resources like the following: manager * [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats) --> -* [失败的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) -* [已完成的 Job](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) +* [失败的 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) +* [已完成的 Job](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) * [不再存在属主引用的对象](#owners-dependents) * [未使用的容器和容器镜像](#containers-images) -* [动态制备的、StorageClass 回收策略为 Delete 的 PV 卷](/zh/docs/concepts/storage/persistent-volumes/#delete) -* [阻滞或者过期的 CertificateSigningRequest (CSRs)](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) +* [动态制备的、StorageClass 回收策略为 Delete 的 PV 卷](/zh-cn/docs/concepts/storage/persistent-volumes/#delete) +* [阻滞或者过期的 CertificateSigningRequest (CSRs)](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) * 在以下情形中删除了的{{}}对象： - * 当集群使用[云控制器管理器](/zh/docs/concepts/architecture/cloud-controller/)运行于云端时； + * 当集群使用[云控制器管理器](/zh-cn/docs/concepts/architecture/cloud-controller/)运行于云端时； * 当集群使用类似于云控制器管理器的插件运行在本地环境中时。 -* [节点租约对象](/zh/docs/concepts/architecture/nodes/#heartbeats) +* [节点租约对象](/zh-cn/docs/concepts/architecture/nodes/#heartbeats) ## 属主与依赖 {#owners-dependents} -Kubernetes 中很多对象通过[*属主引用*](/zh/docs/concepts/overview/working-with-objects/owners-dependents/) +Kubernetes 中很多对象通过[*属主引用*](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/) 链接到彼此。属主引用（Owner Reference）可以告诉控制面哪些对象依赖于其他对象。 Kubernetes 使用属主引用来为控制面以及其他 API 客户端在删除某对象时提供一个清理关联资源的机会。 在大多数场合，Kubernetes 都是自动管理属主引用的。 @@ -69,7 +69,7 @@ to the labels, each `EndpointSlice` that is managed on behalf of a Service has an owner reference. Owner references help different parts of Kubernetes avoid interfering with objects they don’t control. --> -属主关系与某些资源所使用的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)不同。 +属主关系与某些资源所使用的[标签和选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)不同。 例如，考虑一个创建 `EndpointSlice` 对象的 {{}} 对象。Service 对象使用*标签*来允许控制面确定哪些 `EndpointSlice` 对象被该 Service 使用。除了标签，每个被 Service 托管的 `EndpointSlice` 对象还有一个属主引用属性。 @@ -181,7 +181,7 @@ to learn more. 在前台级联删除过程中，唯一可能阻止属主对象被删除的是那些带有 `ownerReference.blockOwnerDeletion=true` 字段的依赖对象。 -参阅[使用前台级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) +参阅[使用前台级联删除](/zh-cn/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) 以了解进一步的细节。 要配置对未使用容器和镜像的垃圾收集选项，可以使用一个 -[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)，基于 -[`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) +[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)，基于 +[`KubeletConfiguration`](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 资源类型来调整与垃圾搜集相关的 kubelet 行为。 @@ -353,8 +353,8 @@ configure garbage collection: * Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/). * Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs. --> -* 进一步了解 [Kubernetes 对象的属主关系](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)。 -* 进一步了解 Kubernetes [finalizers](/zh/docs/concepts/overview/working-with-objects/finalizers/)。 -* 进一步了解 [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) (beta)， +* 进一步了解 [Kubernetes 对象的属主关系](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/)。 +* 进一步了解 Kubernetes [finalizers](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。 +* 进一步了解 [TTL 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) (beta)， 该控制器负责清理已完成的 Job。 diff --git a/content/zh-cn/docs/concepts/architecture/nodes.md b/content/zh-cn/docs/concepts/architecture/nodes.md index 0ab1e695ca..a57f98dc14 100644 --- a/content/zh-cn/docs/concepts/architecture/nodes.md +++ b/content/zh-cn/docs/concepts/architecture/nodes.md @@ -38,7 +38,7 @@ Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行 通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可能 只有一个节点。 -节点上的[组件](/zh/docs/concepts/overview/components/#node-components)包括 +节点上的[组件](/zh-cn/docs/concepts/overview/components/#node-components)包括 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、 {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}以及 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}。 @@ -110,7 +110,7 @@ The name of a Node object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> Node 对象的名称必须是合法的 -[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)。 ### 节点名称唯一性 {#node-name-uniqueness} -节点的[名称](/zh/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。 +节点的[名称](/zh-cn/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。 没有两个 Node 可以同时使用相同的名称。 Kubernetes 还假定名字相同的资源是同一个对象。 就 Node 而言，隐式假定使用相同名称的实例会具有相同的状态（例如网络配置、根磁盘内容） 和类似节点标签这类属性。这可能在节点被更改但其名称未变时导致系统状态不一致。 @@ -167,7 +167,7 @@ For self-registration, the kubelet is started with the following options: （逗号分隔的 `=:`）注册节点。当 `register-node` 为 false 时无效。 - `--node-ip` - 节点 IP 地址。 - `--node-labels` - 在集群中注册节点时要添加的{{< glossary_tooltip text="标签" term_id="label" >}}。 - （参见 [NodeRestriction 准入控制插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。 + （参见 [NodeRestriction 准入控制插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。 - `--node-status-update-frequency` - 指定 kubelet 向控制面发送状态的频率。 -启用[Node 鉴权模式](/zh/docs/reference/access-authn-authz/node/)和 -[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时， +启用[Node 鉴权模式](/zh-cn/docs/reference/access-authn-authz/node/)和 +[NodeRestriction 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时， 仅授权 `kubelet` 创建或修改其自己的节点资源。 {{< note >}} @@ -256,7 +256,7 @@ kubectl cordon $NODENAME See [Safely Drain a Node](/docs/tasks/administer-cluster/safely-drain-node/) for more details. --> -更多细节参考[安全地腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。 +更多细节参考[安全地腾空节点](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)。 {{< note >}} 当节点上出现问题时，Kubernetes 控制面会自动创建与影响节点的状况对应的 -[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +[污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。 调度器在将 Pod 指派到某 Node 时会考虑 Node 上的污点设置。 Pod 也可以设置{{< glossary_tooltip text="容忍度" term_id="toleration" >}}， 以便能够在设置了特定污点的 Node 上运行。 @@ -439,7 +439,7 @@ Pod 也可以设置{{< glossary_tooltip text="容忍度" term_id="toleration" >} See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) for more details. --> -进一步的细节可参阅[根据状况为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)。 +进一步的细节可参阅[根据状况为节点设置污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)。 -可以在学习如何在节点上[预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +可以在学习如何在节点上[预留计算资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 的时候了解有关容量和可分配资源的更多信息。 如果要为非 Pod 进程显式保留资源。 -请参考[为系统守护进程预留资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。 +请参考[为系统守护进程预留资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。 {{< /note >}} -如果启用了 `TopologyManager` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +如果启用了 `TopologyManager` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， `kubelet` 可以在作出资源分配决策时使用拓扑提示。 -参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)了解详细信息。 +参考[控制节点上拓扑管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)了解详细信息。 节点体面关闭的特性对应两个 -[`KubeletConfiguration`](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 选项： +[`KubeletConfiguration`](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 选项： * `shutdownGracePeriod`： * 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod - 还是[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 + 还是[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 * `shutdownGracePeriodCriticalPods`： - * 在节点关闭期间指定用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) + * 在节点关闭期间指定用于终止[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) 的持续时间。该值应小于 `shutdownGracePeriod`。 假设集群中存在以下自定义的 Pod -[优先级类](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。 +[优先级类](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。 | Pod 优先级类名称 | Pod 优先级类数值 | |-------------------------|------------------------| @@ -982,7 +982,7 @@ in a cluster, Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) the settings for `shutdownGracePeriodByPodPriority` could look like: --> -在 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)中， +在 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)中， `shutdownGracePeriodByPodPriority` 可能看起来是这样： | Pod 优先级类数值 | 关闭期限 | @@ -1059,8 +1059,8 @@ their respective shutdown periods. 如果此功能特性被启用，但没有提供配置数据，则不会出现排序操作。 使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， -并将 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， +并将 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/) 中的 `shutdownGracePeriodByPodPriority` 设置为期望的配置， 其中包含 Pod 的优先级类数值以及对应的关闭期限。 @@ -1107,7 +1107,7 @@ must be set to false. --> 要在节点上启用交换内存，必须启用kubelet 的 `NodeSwap` 特性门控， 同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn` -[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。 +[配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。 -* 进一步了解节点[组件](/zh/docs/concepts/overview/components/#node-components)。 +* 进一步了解节点[组件](/zh-cn/docs/concepts/overview/components/#node-components)。 * 阅读 [Node 的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。 * 阅读架构设计文档中有关 [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 的章节。 -* 了解[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +* 了解[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。 diff --git a/content/zh-cn/docs/concepts/cluster-administration/_index.md b/content/zh-cn/docs/concepts/cluster-administration/_index.md index d37c50dcad..c340a741c7 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/_index.md +++ b/content/zh-cn/docs/concepts/cluster-administration/_index.md @@ -25,7 +25,7 @@ The cluster administration overview is for anyone creating or administering a Ku It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). --> 集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 -我们假设你大概了解一些核心的 Kubernetes [概念](/zh/docs/concepts/)。 +我们假设你大概了解一些核心的 Kubernetes [概念](/zh-cn/docs/concepts/)。 @@ -40,7 +40,7 @@ Before choosing a guide, here are some considerations: --> ## 规划集群 {#planning-a-cluster} -查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes +查阅[安装](/zh-cn/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 {{< note >}} @@ -68,12 +68,12 @@ Before choosing a guide, here are some considerations: - 你的集群是在**本地**还是**云（IaaS）** 上？Kubernetes 不能直接支持混合集群。 作为代替，你可以建立多个集群。 - **如果你在本地配置 Kubernetes**，需要考虑哪种 - [网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。 + [网络模型](/zh-cn/docs/concepts/cluster-administration/networking/)最适合。 - 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）** 上运行？ - 你是想**运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？ 如果是后者，请选择一个处于开发状态的发行版。 某些发行版只提供二进制发布版，但提供更多的选择。 -- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。 +- 让你自己熟悉运行一个集群所需的[组件](/zh-cn/docs/concepts/overview/components/)。 ## 管理集群 {#managing-a-cluster} -* 学习如何[管理节点](/zh/docs/concepts/architecture/nodes/)。 +* 学习如何[管理节点](/zh-cn/docs/concepts/architecture/nodes/)。 -* 学习如何设定和管理集群共享的[资源配额](/zh/docs/concepts/policy/resource-quotas/) 。 +* 学习如何设定和管理集群共享的[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/) 。 ## 保护集群 {#securing-a-cluster} -* [生成证书](/zh/docs/tasks/administer-cluster/certificates/) +* [生成证书](/zh-cn/docs/tasks/administer-cluster/certificates/) 节描述了使用不同的工具链生成证书的步骤。 -* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/) +* [Kubernetes 容器环境](/zh-cn/docs/concepts/containers/container-environment/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 -* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/) +* [控制到 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/) 描述了如何为用户和 service accounts 建立权限许可。 -* [身份认证](/zh/docs/reference/access-authn-authz/authentication/) +* [身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/) 节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。 -* [鉴权](/zh/docs/reference/access-authn-authz/authorization/) +* [鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/) 与身份认证不同，用于控制如何处理 HTTP 请求。 -* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) +* [使用准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 -* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) +* [在 Kubernetes 集群中使用 Sysctls](/zh-cn/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 -* [审计](/zh/docs/tasks/debug/debug-cluster/audit/) +* [审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/) 描述了如何与 Kubernetes 的审计日志交互。 ### 保护 kubelet {#securing-the-kubelet} -* [主控节点通信](/zh/docs/concepts/architecture/control-plane-node-communication/) -* [TLS 引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) -* [Kubelet 认证/授权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/) +* [主控节点通信](/zh-cn/docs/concepts/architecture/control-plane-node-communication/) +* [TLS 引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) +* [Kubelet 认证/授权](/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz/) ## 可选集群服务 {#optional-cluster-services} -* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/) +* [DNS 集成](/zh-cn/docs/concepts/services-networking/dns-pod-service/) 描述了如何将一个 DNS 名解析到一个 Kubernetes service。 -* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/) +* [记录和监控集群活动](/zh-cn/docs/concepts/cluster-administration/logging/) 阐述了 Kubernetes 的日志如何工作以及怎样实现。 diff --git a/content/zh-cn/docs/concepts/cluster-administration/certificates.md b/content/zh-cn/docs/concepts/cluster-administration/certificates.md index b900e77ec9..2297ffac05 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/certificates.md +++ b/content/zh-cn/docs/concepts/cluster-administration/certificates.md @@ -14,5 +14,5 @@ weight: 20 -要了解如何为集群生成证书，参阅[证书](/zh/docs/tasks/administer-cluster/certificates/)。 +要了解如何为集群生成证书，参阅[证书](/zh-cn/docs/tasks/administer-cluster/certificates/)。 diff --git a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md index a28154dfe6..746a7b4e3b 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md +++ b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md @@ -86,7 +86,7 @@ command-line flags to your `kube-apiserver` invocation: --> API 优先级与公平性（APF）特性由特性门控控制，默认情况下启用。 有关特性门控的一般性描述以及如何启用和禁用特性门控， -请参见[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +请参见[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 APF 的特性门控称为 `APIPriorityAndFairness`。 此特性也与某个 {{< glossary_tooltip term_id="api-group" text="API 组" >}} 相关： diff --git a/content/zh-cn/docs/concepts/cluster-administration/logging.md b/content/zh-cn/docs/concepts/cluster-administration/logging.md index ff6e2612ed..8b53c28ae3 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/logging.md +++ b/content/zh-cn/docs/concepts/cluster-administration/logging.md @@ -478,7 +478,7 @@ a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to c --> 下面是两个配置文件，可以用来实现一个带日志代理的边车容器。 第一个文件包含用来配置 fluentd 的 -[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。 +[ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)。 {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} diff --git a/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md b/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md index 7d77f529e2..38bda5a21f 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md @@ -12,8 +12,8 @@ You've deployed your application and exposed it via a service. Now what? Kuberne 你已经部署了应用并通过服务暴露它。然后呢？ Kubernetes 提供了一些工具来帮助管理你的应用部署，包括扩缩容和更新。 我们将更深入讨论的特性包括 -[配置文件](/zh/docs/concepts/configuration/overview/)和 -[标签](/zh/docs/concepts/overview/working-with-objects/labels/)。 +[配置文件](/zh-cn/docs/concepts/configuration/overview/)和 +[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 @@ -85,7 +85,7 @@ A URL can also be specified as a configuration source, which is handy for deploy 还可以使用 URL 作为配置源，便于直接使用已经提交到 Github 上的配置文件进行部署： ```shell -kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/zh/examples/application/nginx/nginx-deployment.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/application/nginx/nginx-deployment.yaml ``` ``` @@ -239,7 +239,7 @@ persistentvolumeclaim/my-pvc created If you're interested in learning more about `kubectl`, go ahead and read [Command line tool (kubectl)](/docs/reference/kubectl/). --> 如果你有兴趣进一步学习关于 `kubectl` 的内容，请阅读 -[命令行工具（kubectl）](/zh/docs/reference/kubectl/)。 +[命令行工具（kubectl）](/zh-cn/docs/reference/kubectl/)。 想要了解更多信息，请参考 -[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)和 +[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)和 [`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate) 命令文档。 @@ -535,7 +535,7 @@ For more information, please see [kubectl scale](/docs/reference/generated/kubec 想要了解更多信息，请参考 [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)命令文档、 [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 命令文档和 -[水平 Pod 自动伸缩](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。 +[水平 Pod 自动伸缩](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。 你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch、 JSON merge patch、以及 strategic merge patch。 请参考 -[使用 kubectl patch 更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) +[使用 kubectl patch 更新 API 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) 和 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch). @@ -716,7 +716,7 @@ That's it! The Deployment will declaratively update the deployed nginx applicati --> 没错，就是这样！Deployment 将在后台逐步更新已经部署的 nginx 应用。 它确保在更新过程中，只有一定数量的旧副本被开闭，并且只有一定基于所需 Pod 数量的新副本被创建。 -想要了解更多细节，请参考 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。 +想要了解更多细节，请参考 [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。 ## {{% heading "whatsnext" %}} @@ -724,5 +724,5 @@ That's it! The Deployment will declaratively update the deployed nginx applicati - [Learn about how to use `kubectl` for application introspection and debugging.](/docs/tasks/debug/debug-application/debug-running-pod/) - [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/) --> -- 学习[如何使用 `kubectl` 观察和调试应用](/zh/docs/tasks/debug/debug-application/debug-running-pod/) -- 阅读[配置最佳实践和技巧](/zh/docs/concepts/configuration/overview/) +- 学习[如何使用 `kubectl` 观察和调试应用](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/) +- 阅读[配置最佳实践和技巧](/zh-cn/docs/concepts/configuration/overview/) diff --git a/content/zh-cn/docs/concepts/cluster-administration/networking.md b/content/zh-cn/docs/concepts/cluster-administration/networking.md index 4bfae1a551..edc6866ec8 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/networking.md +++ b/content/zh-cn/docs/concepts/cluster-administration/networking.md @@ -29,8 +29,8 @@ problems to address: 1. 高度耦合的容器间通信：这个已经被 {{< glossary_tooltip text="Pods" term_id="pod" >}} 和 `localhost` 通信解决了。 2. Pod 间通信：本文档讲述重点。 -3. Pod 和服务间通信：由[服务](/zh/docs/concepts/services-networking/service/)负责。 -4. 外部和服务间通信：也由[服务](/zh/docs/concepts/services-networking/service/)负责。 +3. Pod 和服务间通信：由[服务](/zh-cn/docs/concepts/services-networking/service/)负责。 +4. 外部和服务间通信：也由[服务](/zh-cn/docs/concepts/services-networking/service/)负责。 @@ -56,7 +56,7 @@ Kubernetes 的宗旨就是在应用之间共享机器。 而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。 与其去解决这些问题，Kubernetes 选择了其他不同的方法。 -要了解 Kubernetes 网络模型，请参阅[此处](/zh/docs/concepts/services-networking/)。 +要了解 Kubernetes 网络模型，请参阅[此处](/zh-cn/docs/concepts/services-networking/)。 -1. [kubectl proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)： +1. [kubectl proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)： - 运行在用户的桌面或 pod 中 - 从本机地址到 Kubernetes apiserver 的代理 @@ -56,7 +56,7 @@ There are several different proxies you may encounter when using Kubernetes: - can be used to reach a Node, Pod, or Service - does load balancing when used to reach a Service --> -2. [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)： +2. [apiserver proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)： - 是一个建立在 apiserver 内部的“堡垒” - 将集群外部的用户与集群 IP 相连接，这些IP是无法通过其他方式访问的 @@ -75,7 +75,7 @@ There are several different proxies you may encounter when using Kubernetes: - provides load balancing - is only used to reach services --> -3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)： +3. [kube proxy](/zh-cn/docs/concepts/services-networking/service/#ips-and-vips)： - 在每个节点上运行 - 代理 UDP、TCP 和 SCTP diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-logs.md b/content/zh-cn/docs/concepts/cluster-administration/system-logs.md index 164d416b9f..2365e3bd23 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/system-logs.md +++ b/content/zh-cn/docs/concepts/cluster-administration/system-logs.md @@ -38,7 +38,7 @@ klog 是 Kubernetes 的日志库。 [klog](https://github.com/kubernetes/klog) 为 Kubernetes 系统组件生成日志消息。 -有关 klog 配置的更多信息，请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。 +有关 klog 配置的更多信息，请参见[命令行工具参考](/zh-cn/docs/reference/command-line-tools-reference/)。 JSON 输出并不支持太多标准 klog 参数。对于不受支持的 klog 参数的列表， -请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。 +请参见[命令行工具参考](/zh-cn/docs/reference/command-line-tools-reference/)。 并不是所有日志都保证写成 JSON 格式（例如，在进程启动期间）。 如果你打算解析日志，请确保可以处理非 JSON 格式的日志行。 @@ -388,7 +388,7 @@ The `logrotate` tool rotates logs daily, or once the log size is greater than 10 * Read about [deprecation of klog flags](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) * Read about the [Conventions for logging severity](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) --> -* 阅读 [Kubernetes 日志架构](/zh/docs/concepts/cluster-administration/logging/) +* 阅读 [Kubernetes 日志架构](/zh-cn/docs/concepts/cluster-administration/logging/) * 阅读[结构化日志提案（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) * 阅读[上下文日志提案（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging) * 阅读 [klog 参数的废弃（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md b/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md index f054161998..2f971177fe 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md +++ b/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md @@ -204,7 +204,7 @@ kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结 现在，收集加速器指标的责任属于供应商，而不是 kubelet。供应商必须提供一个收集指标的容器， 并将其公开给指标服务（例如 Prometheus）。 -[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +[`DisableAcceleratorUsageMetrics` 特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 禁止由 kubelet 收集的指标。 关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。 @@ -271,7 +271,7 @@ The kube-scheduler identifies the resource [requests and limits](/docs/concepts/ - the unit of the resource if known (for example, `cores`) --> kube-scheduler 组件能够辩识各个 Pod 所配置的资源 -[请求和约束](/zh/docs/concepts/configuration/manage-resources-containers/)。 +[请求和约束](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。 在 Pod 的资源请求值或者约束值非零时，kube-scheduler 会以度量值时间序列的形式 生成报告。该时间序列值包含以下标签： - 名字空间 @@ -341,4 +341,4 @@ Here is an example: * Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) --> * 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) -* 阅读有关 [Kubernetes 弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) +* 阅读有关 [Kubernetes 弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-traces.md b/content/zh-cn/docs/concepts/cluster-administration/system-traces.md index 71ede2f3e7..2a3860a361 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/system-traces.md +++ b/content/zh-cn/docs/concepts/cluster-administration/system-traces.md @@ -114,7 +114,7 @@ with `--tracing-config-file=`. This is an example config that re spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint: --> 要启用追踪特性，需要启用 kube-apiserver 上的 `APIServerTracing` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 然后，使用 `--tracing-config-file=<<配置文件路径>` 为 kube-apiserver 提供追踪配置文件。 下面是一个示例配置，它为万分之一的请求记录 spans，并使用了默认的 OpenTelemetry 端口。 @@ -132,7 +132,7 @@ For more information about the `TracingConfiguration` struct, see --> 有关 TracingConfiguration 结构体的更多信息，请参阅 -[API 服务器配置 API (v1alpha1)](/zh/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。 +[API 服务器配置 API (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。 ## ConfigMap 对象 -ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)， +ConfigMap 是一个 API [对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/)， 让你可以存储其他对象所需要使用的配置。 和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 和 `binaryData` 字段。这些字段能够接收键-值对作为其取值。`data` 和 `binaryData` @@ -81,7 +81,7 @@ ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects 则被设计用来保存二进制数据作为 base64 编码的字串。 ConfigMap 的名字必须是一个合法的 -[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)。 {{< note >}} -使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。 +使用 ConfigMap 作为 [subPath](/zh-cn/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。 {{< /note >}} 此功能特性由 `ImmutableEphemeralVolumes` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来控制。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来控制。 你可以通过将 `immutable` 字段设置为 `true` 创建不可变更的 ConfigMap。 例如： @@ -465,7 +465,7 @@ to the deleted ConfigMap, it is recommended to recreate these pods. * Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for separating code from configuration. --> -* 阅读 [Secret](/zh/docs/concepts/configuration/secret/)。 -* 阅读[配置 Pod 使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。 -* 阅读[修改 ConfigMap（或任何其他 Kubernetes 对象）](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 +* 阅读 [Secret](/zh-cn/docs/concepts/configuration/secret/)。 +* 阅读[配置 Pod 使用 ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)。 +* 阅读[修改 ConfigMap（或任何其他 Kubernetes 对象）](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 * 阅读 [Twelve-Factor 应用](https://12factor.net/zh_cn/)来了解将代码和配置分开的动机。 diff --git a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md index 001ab761ef..7c1d37f9fa 100644 --- a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md +++ b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md @@ -145,8 +145,8 @@ through the Kubernetes API server. --> CPU 和内存统称为“计算资源”，或简称为“资源”。 计算资源的数量是可测量的，可以被请求、被分配、被消耗。 -它们与 [API 资源](/zh/docs/concepts/overview/kubernetes-api/) 不同。 -API 资源（如 Pod 和 [Service](/zh/docs/concepts/services-networking/service/)）是可通过 +它们与 [API 资源](/zh-cn/docs/concepts/overview/kubernetes-api/) 不同。 +API 资源（如 Pod 和 [Service](/zh-cn/docs/concepts/services-networking/service/)）是可通过 Kubernetes API 服务器读取和修改的对象。 kubelet 也使用此类存储来保存 -[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， 容器镜像文件、以及运行中容器的可写入层。 {{< caution >}} @@ -502,7 +502,7 @@ Kubernetes 有两种方式支持节点上配置本地临时性存储： （kubelet）来保存数据的。 kubelet 也会生成 -[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， 并按临时性本地存储的方式对待之。 字段 `.status.allocatable` 描述节点上可以用于 Pod 的资源总量（例如：15 个虚拟 CPU、7538 MiB 内存）。关于 Kubernetes 中节点可分配资源的信息，可参阅 -[为系统守护进程预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/)。 +[为系统守护进程预留计算资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/)。 -你可以配置[资源配额](/zh/docs/concepts/policy/resource-quotas/)功能特性以限制每个名字空间可以使用的资源总量。 +你可以配置[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)功能特性以限制每个名字空间可以使用的资源总量。 当某名字空间中存在 ResourceQuota 时，Kubernetes 会在该名字空间中的对象强制实施配额。 例如，如果你为不同的团队分配名字空间，你可以为这些名字空间添加 ResourceQuota。 设置资源配额有助于防止一个团队占用太多资源，以至于这种占用会影响其他团队。 @@ -1375,10 +1375,10 @@ memory limit (and possibly request) for that container. * Read about [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS * Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) --> -* 获取[分配内存资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 -* 获取[分配 CPU 资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 +* 获取[分配内存资源给容器和 Pod ](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 +* 获取[分配 CPU 资源给容器和 Pod ](/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 * 阅读 API 参考中 [Container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) 和其[资源请求](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)定义。 * 阅读 XFS 中[配额](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)的文档 -* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) +* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) diff --git a/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index fa77d3c2de..c46b91d3c7 100644 --- a/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -58,7 +58,7 @@ For step-by-step instructions on creating and specifying kubeconfig files, see [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). --> 有关创建和指定 kubeconfig 文件的分步说明，请参阅 -[配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 +[配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 @@ -193,7 +193,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: [Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). --> 有关设置 `KUBECONFIG` 环境变量的示例，请参阅 - [设置 KUBECONFIG 环境变量](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 + [设置 KUBECONFIG 环境变量](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 -* [配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/zh-cn/docs/concepts/configuration/overview.md b/content/zh-cn/docs/concepts/configuration/overview.md index 01314daf34..b0d9c2a033 100644 --- a/content/zh-cn/docs/concepts/configuration/overview.md +++ b/content/zh-cn/docs/concepts/configuration/overview.md @@ -77,8 +77,8 @@ This is a living document. If you think of something that is not on this list bu - Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure. --> - 如果可能，不要使用独立的 Pods（即，未绑定到 -[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 或 -[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 的 Pod）。 +[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 或 +[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 的 Pod）。 如果节点发生故障，将不会重新调度独立的 Pods。 Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终可用，也可以指定替换 Pod 的策略（例如 -[RollingUpdate](/zh/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)）。 -除了一些显式的 [`restartPolicy: Never`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) -场景外，Deployment 通常比直接创建 Pod 要好得多。[Job](/zh/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。 +[RollingUpdate](/zh-cn/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)）。 +除了一些显式的 [`restartPolicy: Never`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +场景外，Deployment 通常比直接创建 Pod 要好得多。[Job](/zh-cn/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。 - 在创建相应的后端工作负载（Deployment 或 ReplicaSet），以及在需要访问它的任何工作负载之前创建 - [服务](/zh/docs/concepts/services-networking/service/)。 + [服务](/zh-cn/docs/concepts/services-networking/service/)。 当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。 例如，如果存在名为 `foo` 的服务，则所有容器将在其初始环境中获得以下变量。 @@ -118,7 +118,7 @@ Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终 - An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically. --> -- 一个可选（尽管强烈推荐）的[集群插件](/zh/docs/concepts/cluster-administration/addons/) +- 一个可选（尽管强烈推荐）的[集群插件](/zh-cn/docs/concepts/cluster-administration/addons/) 是 DNS 服务器。DNS 服务器为新的 `Services` 监视 Kubernetes API，并为每个创建一组 DNS 记录。 如果在整个集群中启用了 DNS，则所有 `Pods` 应该能够自动对 `Services` 进行名称解析。 @@ -135,14 +135,14 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). --> 如果你只需要访问端口以进行调试，则可以使用 - [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或 - [`kubectl port-forward`](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 + [apiserver proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或 + [`kubectl port-forward`](/zh-cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 如果你明确需要在节点上公开 Pod 的端口，请在使用 `hostPort` 之前考虑使用 - [NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) 服务。 + [NodePort](/zh-cn/docs/concepts/services-networking/service/#type-nodeport) 服务。 - 当你不需要 `kube-proxy` 负载均衡时，使用 - [无头服务](/zh/docs/concepts/services-networking/service/#headless-services) + [无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services) (`ClusterIP` 被设置为 `None`)以便于服务发现。 -- 定义并使用[标签](/zh/docs/concepts/overview/working-with-objects/labels/)来识别应用程序 +- 定义并使用[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)来识别应用程序 或 Deployment 的 __语义属性__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。 你可以使用这些标签为其他资源选择合适的 Pod； 例如，一个选择所有 `tier: frontend` Pod 的服务，或者 `app: myapp` 的所有 `phase: test` 组件。 @@ -175,7 +175,7 @@ services) (which have a `ClusterIP` of `None`) for service discovery when you do A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime. --> 通过从选择器中省略特定发行版的标签，可以使服务跨越多个 Deployment。 -当你需要不停机的情况下更新正在运行的服务，可以使用[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。 +当你需要不停机的情况下更新正在运行的服务，可以使用[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。 -- 对于常见场景，应使用 [Kubernetes 通用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)。 +- 对于常见场景，应使用 [Kubernetes 通用标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/)。 这些标准化的标签丰富了对象的元数据，使得包括 `kubectl` 和 - [仪表板（Dashboard）](/zh/docs/tasks/access-application-cluster/web-ui-dashboard) + [仪表板（Dashboard）](/zh-cn/docs/tasks/access-application-cluster/web-ui-dashboard) 这些工具能够以可互操作的方式工作。 - 使用标签选择器进行 `get` 和 `delete` 操作，而不是特定的对象名称。 -- 请参阅[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)和 - [有效使用标签](/zh/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。 +- 请参阅[标签选择器](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)和 + [有效使用标签](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。 - 使用`kubectl run`和`kubectl expose`来快速创建单容器部署和服务。 - 有关示例，请参阅[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)。 + 有关示例，请参阅[使用服务访问集群中的应用程序](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/)。 diff --git a/content/zh-cn/docs/concepts/configuration/secret.md b/content/zh-cn/docs/concepts/configuration/secret.md index 961b149257..b67534c238 100644 --- a/content/zh-cn/docs/concepts/configuration/secret.md +++ b/content/zh-cn/docs/concepts/configuration/secret.md @@ -74,8 +74,8 @@ In order to safely use Secrets, take at least the following steps: 为了安全地使用 Secret，请至少执行以下步骤： -1. 为 Secret [启用静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)； -1. [启用或配置 RBAC 规则](/zh/docs/reference/access-authn-authz/authorization/)来限制读取和写入 +1. 为 Secret [启用静态加密](/zh-cn/docs/tasks/administer-cluster/encrypt-data/)； +1. [启用或配置 RBAC 规则](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制读取和写入 Secret 的数据（包括通过间接方式）。需要注意的是，被准许创建 Pod 的人也隐式地被授权获取 Secret 内容。 1. 在适当的情况下，还可以使用 RBAC 等机制来限制允许哪些主体创建新 Secret 或替换现有 Secret。 @@ -139,7 +139,7 @@ Here are some of your options: token). --> - 如果你的云原生组件需要执行身份认证来访问你所知道的、在同一 Kubernetes 集群中运行的另一个应用， - 你可以使用 [ServiceAccount](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens) + 你可以使用 [ServiceAccount](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens) 及其令牌来标识你的客户端身份。 - 你可以运行的第三方工具也有很多，这些工具可以运行在集群内或集群外，提供机密数据管理。 例如，这一工具可能是 Pod 通过 HTTPS 访问的一个服务，该服务在客户端能够正确地通过身份认证 @@ -153,9 +153,9 @@ Here are some of your options: trusted Pods onto nodes that provide a Trusted Platform Module, configured out-of-band. --> - 就身份认证而言，你可以为 X.509 证书实现一个定制的签名者，并使用 - [CertificateSigningRequest](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) + [CertificateSigningRequest](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/) 来让该签名者为需要证书的 Pod 发放证书。 -- 你可以使用一个[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +- 你可以使用一个[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 来将节点本地的加密硬件暴露给特定的 Pod。例如，你可以将可信任的 Pod 调度到提供可信平台模块（Trusted Platform Module，TPM）的节点上。 这类节点是另行配置的。 @@ -191,9 +191,9 @@ There are several options to create a Secret: ### 创建 Secret {#creating-a-secret} -- [使用 `kubectl` 命令来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/) -- [基于配置文件来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/) -- [使用 kustomize 来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- [使用 `kubectl` 命令来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [基于配置文件来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [使用 kustomize 来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/) -你仍然可以[手动创建](/zh/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token) +你仍然可以[手动创建](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token) 服务账号令牌。例如，当你需要一个永远都不过期的令牌时。 不过，仍然建议使用 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) 子资源来获得访问 API 服务器的令牌。 @@ -648,7 +648,7 @@ A container using a Secret as a [subPath](/docs/concepts/storage/volumes#using-subpath) volume mount does not receive automated Secret updates. --> -对于以 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言， +对于以 [subPath](/zh-cn/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言， 它们无法收到自动的 Secret 更新。 {{< /note >}} @@ -660,7 +660,7 @@ the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) --> Kubelet 组件会维护一个缓存，在其中保存节点上 Pod 卷中使用的 Secret 的当前主键和取值。 你可以配置 kubelet 如何检测所缓存数值的变化。 -[kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/)中的 +[kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)中的 `configMapAndSecretChangeDetectionStrategy` 字段控制 kubelet 所采用的策略。 默认的策略是 `Watch`。 @@ -886,7 +886,7 @@ documentation. --> ##### 手动设定 imagePullSecret {#manually-specifying-an-imagepullsecret} -你可以通过阅读[容器镜像](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +你可以通过阅读[容器镜像](/zh-cn/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 文档了解如何设置 `imagePullSecrets`。 -参考 [ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) +参考 [ServiceAccount](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) 文档了解服务账号的工作原理。你也可以查看 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) 资源中的 `automountServiceAccountToken` 和 `serviceAccountName` 字段文档， @@ -1814,7 +1814,7 @@ The following YAML contains an example config for a TLS Secret: Kubernetes 提供一种内置的 `kubernetes.io/tls` Secret 类型，用来存放 TLS 场合通常要使用的证书及其相关密钥。 -TLS Secret 的一种典型用法是为 [Ingress](/zh/docs/concepts/services-networking/ingress/) +TLS Secret 的一种典型用法是为 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 资源配置传输过程中的数据加密，不过也可以用于其他资源或者直接在负载中使用。 当使用此类型的 Secret 时，Secret 配置中的 `data` （或 `stringData`）字段必须包含 `tls.key` 和 `tls.crt` 主键，尽管 API 服务器实际上并不会对每个键的取值作进一步的合法性检查。 @@ -2164,8 +2164,8 @@ on that node. [authorization policies](/docs/reference/access-authn-authz/authorization/) such as [RBAC](/docs/reference/access-authn-authz/rbac/). --> -- 部署与 Secret API 交互的应用时，你应该使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) - 这类[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)来限制访问。 +- 部署与 Secret API 交互的应用时，你应该使用 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) + 这类[鉴权策略](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制访问。 -- 学习如何[使用 `kubectl` 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/) -- 学习如何[使用配置文件管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/) -- 学习如何[使用 kustomize 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/) -- 阅读 [API 参考](/zh/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret` +- 学习如何[使用 `kubectl` 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- 学习如何[使用配置文件管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- 学习如何[使用 kustomize 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- 阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret` diff --git a/content/zh-cn/docs/concepts/configuration/windows-resource-management.md b/content/zh-cn/docs/concepts/configuration/windows-resource-management.md index a34682f5ae..4a4cefb483 100644 --- a/content/zh-cn/docs/concepts/configuration/windows-resource-management.md +++ b/content/zh-cn/docs/concepts/configuration/windows-resource-management.md @@ -104,7 +104,7 @@ On Windows these values are only used to calculate the node's 为了满足操作系统、容器运行时和 kubelet 等 Kubernetes 主机进程使用的内存和 CPU， 你可以（且应该）用 `--kube-reserved` 和/或 `--system-reserved` kubelet 标志来预留内存和 CPU 资源。 -在 Windows 上，这些值仅用于计算节点的[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。 +在 Windows 上，这些值仅用于计算节点的[可分配](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。 ## 容器镜像 {#container-images} -[容器镜像](/zh/docs/concepts/containers/images/)是一个随时可以运行的软件包， +[容器镜像](/zh-cn/docs/concepts/containers/images/)是一个随时可以运行的软件包， 包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。 根据设计，容器是不可变的：你不能更改已经运行的容器的代码。 @@ -53,7 +53,7 @@ the change, then recreate the container to start from the updated image. * Read about [Pods](/docs/concepts/workloads/pods/) --> -* 进一步阅读[容器镜像](/zh/docs/concepts/containers/images/) -* 进一步阅读 [Pods](/zh/docs/concepts/workloads/pods/) +* 进一步阅读[容器镜像](/zh-cn/docs/concepts/containers/images/) +* 进一步阅读 [Pods](/zh-cn/docs/concepts/workloads/pods/) diff --git a/content/zh-cn/docs/concepts/containers/container-environment.md b/content/zh-cn/docs/concepts/containers/container-environment.md index 362e9d4c1b..32ed23ba50 100644 --- a/content/zh-cn/docs/concepts/containers/container-environment.md +++ b/content/zh-cn/docs/concepts/containers/container-environment.md @@ -34,8 +34,8 @@ The Kubernetes Container environment provides several important resources to Con Kubernetes 的容器环境给容器提供了几个重要的资源： -* 文件系统，其中包含一个[镜像](/zh/docs/concepts/containers/images/) - 和一个或多个的[卷](/zh/docs/concepts/storage/volumes/) +* 文件系统，其中包含一个[镜像](/zh-cn/docs/concepts/containers/images/) + 和一个或多个的[卷](/zh-cn/docs/concepts/storage/volumes/) * 容器自身的信息 * 集群中其他对象的信息 @@ -59,7 +59,7 @@ as are any environment variables specified statically in the container image. [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) 函数来获取。 Pod 名称和命名空间可以通过 -[下行 API](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) +[下行 API](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 转换为环境变量。 Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 container 镜像中静态指定的任何环境变量一样。 @@ -100,7 +100,7 @@ if [DNS addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addon * Get hands-on experience [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). --> -* 学习更多有关[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)的知识 -* 动手[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) +* 学习更多有关[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)的知识 +* 动手[为容器生命周期事件添加处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) diff --git a/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md b/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md index 32d86af26a..9791183f47 100644 --- a/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md @@ -80,7 +80,7 @@ A more detailed description of the termination behavior can be found in [Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). --> 有关终止行为的更详细描述，请参见 -[终止 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)。 +[终止 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)。 -* 进一步了解[容器环境](/zh/docs/concepts/containers/container-environment/) -* 动手实践，[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) +* 进一步了解[容器环境](/zh-cn/docs/concepts/containers/container-environment/) +* 动手实践，[为容器生命周期事件添加处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) diff --git a/content/zh-cn/docs/concepts/containers/images.md b/content/zh-cn/docs/concepts/containers/images.md index 12c48ef463..f3783775cc 100644 --- a/content/zh-cn/docs/concepts/containers/images.md +++ b/content/zh-cn/docs/concepts/containers/images.md @@ -101,7 +101,7 @@ these values have: --> ### 镜像拉取策略 {#image-pull-policy} -容器的 `imagePullPolicy` 和镜像的标签会影响 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 尝试拉取（下载）指定的镜像。 +容器的 `imagePullPolicy` 和镜像的标签会影响 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 尝试拉取（下载）指定的镜像。 以下列表包含了 `imagePullPolicy` 可以设置的值，以及这些值的效果： @@ -179,7 +179,7 @@ running the same code no matter what tag changes happen at the registry. 镜像摘要唯一标识了镜像的特定版本，因此 Kubernetes 每次启动具有指定镜像名称和摘要的容器时，都会运行相同的代码。 通过摘要指定镜像可固定你运行的代码，这样镜像仓库的变化就不会导致版本的混杂。 -有一些第三方的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) +有一些第三方的[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) 在创建 Pod（和 Pod 模板）时产生变更，这样运行的工作负载就是根据镜像摘要，而不是标签来定义的。 无论镜像仓库上的标签发生什么变化，你都想确保你所有的工作负载都运行相同的代码，那么指定镜像摘要会很有用。 @@ -247,7 +247,7 @@ If you would like to always force a pull, you can do one of the following: 当你提交 Pod 时，Kubernetes 会将策略设置为 `Always`。 - 省略 `imagePullPolicy` 和镜像的标签； 当你提交 Pod 时，Kubernetes 会将策略设置为 `Always`。 -- 启用准入控制器 [AlwaysPullImages](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。 +- 启用准入控制器 [AlwaysPullImages](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。 有关配置私有容器镜像仓库的示例，请参阅任务 -[从私有镜像库中提取图像](/zh/docs/tasks/configure-pod-container/pull-image-private-registry)。 +[从私有镜像库中提取图像](/zh-cn/docs/tasks/configure-pod-container/pull-image-private-registry)。 该示例使用 Docker Hub 中的私有注册表。 你需要对使用私有仓库的每个 Pod 执行以上操作。 不过，设置该字段的过程也可以通过为 -[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) +[服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) 资源设置 `imagePullSecrets` 来自动完成。 有关详细指令可参见 -[将 ImagePullSecrets 添加到服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)。 +[将 ImagePullSecrets 添加到服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)。 你也可以将此方法与节点级别的 `.docker/config.json` 配置结合使用。 来自不同来源的凭据会被合并。 @@ -685,7 +685,7 @@ common use cases and suggested solutions. - Move sensitive data into a "Secret" resource, instead of packaging it in an image. --> 3. 集群使用专有镜像，且有些镜像需要更严格的访问控制 - - 确保 [AlwaysPullImages 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)被启用。否则，所有 Pod 都可以使用所有镜像。 + - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)被启用。否则，所有 Pod 都可以使用所有镜像。 - 确保将敏感数据存储在 Secret 资源中，而不是将其打包在镜像里 4. 集群是多租户的并且每个租户需要自己的私有仓库 - - 确保 [AlwaysPullImages 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。否则，所有租户的所有的 Pod 都可以使用所有镜像。 + - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。否则，所有租户的所有的 Pod 都可以使用所有镜像。 - 为私有仓库启用鉴权 - 为每个租户生成访问仓库的凭据，放置在 Secret 中，并将 Secrert 发布到各租户的命名空间下。 - 租户将 Secret 添加到每个名字空间中的 imagePullSecrets @@ -716,4 +716,4 @@ Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config. * Learn about [container image garbage collection](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection). --> * 阅读 [OCI Image Manifest 规范](https://github.com/opencontainers/image-spec/blob/master/manifest.md)。 -* 了解[容器镜像垃圾收集](/zh/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)。 +* 了解[容器镜像垃圾收集](/zh-cn/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)。 diff --git a/content/zh-cn/docs/concepts/containers/runtime-class.md b/content/zh-cn/docs/concepts/containers/runtime-class.md index 99b9f8851d..5eb922eee5 100644 --- a/content/zh-cn/docs/concepts/containers/runtime-class.md +++ b/content/zh-cn/docs/concepts/containers/runtime-class.md @@ -92,7 +92,7 @@ The configurations have a corresponding `handler` name, referenced by the Runtim handler must be a valid [DNS label name](/docs/concepts/overview/working-with-objects/names/#dns-label-names). --> 所有这些配置都具有相应的 `handler` 名，并被 RuntimeClass 引用。 -handler 必须是有效的 [DNS 标签名](/zh/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 +handler 必须是有效的 [DNS 标签名](/zh-cn/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 {{< note >}} 建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。 -通常这是默认配置。参阅[授权概述](/zh/docs/reference/access-authn-authz/authorization/)了解更多信息。 +通常这是默认配置。参阅[授权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)了解更多信息。 {{< /note >}} 这一设置会告诉 kubelet 使用所指的 RuntimeClass 来运行该 pod。 如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler， -那么 pod 将会进入 `Failed` 终止[阶段](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 -你可以查看相应的[事件](/zh/docs/tasks/debug/debug-application/debug-running-pod/)， +那么 pod 将会进入 `Failed` 终止[阶段](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 +你可以查看相应的[事件](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/)， 获取执行过程中的错误信息。 更多有关 node selector 和 tolerations 的配置信息，请查阅 -[将 Pod 分派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)。 +[将 Pod 分派到节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)。 - [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) - [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) -- 阅读关于 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 的概念 +- 阅读关于 [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/) 的概念 - [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)