From f0ddd217db97a00e0ed36d55891f94a24c4fde30 Mon Sep 17 00:00:00 2001 From: howieyuen Date: Thu, 23 Jun 2022 20:17:26 +0800 Subject: [PATCH] [zh]Update concepts pages(part-2) for links with '/zh/' prefix, using new prefix '/zh-cn/' --- .../docs/concepts/extend-kubernetes/_index.md | 66 +++++++++---------- .../api-extension/apiserver-aggregation.md | 8 +-- .../api-extension/custom-resources.md | 46 ++++++------- .../compute-storage-net/device-plugins.md | 20 +++--- .../concepts/extend-kubernetes/operator.md | 10 +-- .../extend-kubernetes/service-catalog.md | 6 +- .../docs/concepts/overview/components.md | 18 ++--- .../docs/concepts/overview/kubernetes-api.md | 22 +++---- .../concepts/overview/what-is-kubernetes.md | 4 +- .../working-with-objects/annotations.md | 2 +- .../working-with-objects/field-selectors.md | 6 +- .../working-with-objects/finalizers.md | 2 +- .../kubernetes-objects.md | 10 +-- .../overview/working-with-objects/labels.md | 24 +++---- .../overview/working-with-objects/names.md | 8 +-- .../working-with-objects/namespaces.md | 22 +++---- .../working-with-objects/object-management.md | 8 +-- .../working-with-objects/owners-dependents.md | 10 +-- .../zh-cn/docs/concepts/policy/limit-range.md | 16 ++--- .../concepts/policy/node-resource-managers.md | 8 +-- .../docs/concepts/policy/pid-limiting.md | 14 ++-- 21 files changed, 165 insertions(+), 165 deletions(-) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/_index.md b/content/zh-cn/docs/concepts/extend-kubernetes/_index.md index e6f8d4bf86..95b0b1cf31 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/_index.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/_index.md @@ -79,11 +79,11 @@ Customization approaches can be broadly divided into *configuration*, which only 配置文件和参数标志的说明位于在线文档的参考章节，按可执行文件组织： -* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) -* [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) -* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) -* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) -* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/). +* [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) +* [kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) +* [kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/). -*内置的策略 API*，例如[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)、 -[PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/)、 -[NetworkPolicy](/zh/docs/concepts/services-networking/network-policies/) -和基于角色的访问控制（[RBAC](/zh/docs/reference/access-authn-authz/rbac/)） +*内置的策略 API*，例如[ResourceQuota](/zh-cn/docs/concepts/policy/resource-quotas/)、 +[PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/)、 +[NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies/) +和基于角色的访问控制（[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)） 等等都是内置的 Kubernetes API。 API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境中。 这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定， 所以新的集群配置是可复用的，并且可以当作应用程序来管理。 此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样， -采纳的是一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。 +采纳的是一种[预定义的支持策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于配置文件和参数标志。 1. 用户通常使用 `kubectl` 与 Kubernetes API 交互。 - [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)能够扩展 kubectl 程序的行为。 + [kubectl 插件](/zh-cn/docs/tasks/extend-kubectl/kubectl-plugins/)能够扩展 kubectl 程序的行为。 这些插件只会影响到每个用户的本地环境，因此无法用来强制实施整个站点范围的策略。 2. API 服务器处理所有请求。API 服务器中的几种扩展点能够使用户对请求执行身份认证、 @@ -273,7 +273,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/ 不要使用自定义资源来充当应用、用户或者监控数据的数据存储。 -关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 +关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 ### 身份认证 {#authentication} -[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中 +[身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/)负责将所有请求中 的头部或证书映射到发出该请求的客户端的用户名。 Kubernetes 提供若干种内置的认证方法，以及 -[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) +[认证 Webhook](/zh-cn/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法以备内置方法无法满足你的要求。 ### 鉴权 {#authorization} -[鉴权](/zh/docs/reference/access-authn-authz/authorization/) +[鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/) 操作负责确定特定的用户是否可以读、写 API 资源或对其执行其他操作。 此操作仅在整个资源集合的层面进行。 换言之，它不会基于对象的特定字段作出不同的判决。 如果内置的鉴权选项无法满足你的需要，你可以使用 -[鉴权 Webhook](/zh/docs/reference/access-authn-authz/webhook/)来调用用户提供 +[鉴权 Webhook](/zh-cn/docs/reference/access-authn-authz/webhook/)来调用用户提供 的代码，执行定制的鉴权操作。 ### 设备插件 {#device-plugins} -使用[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)， +使用[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)， 节点能够发现新的节点资源（除了内置的类似 CPU 和内存这类资源）。 ### 网络插件 {#network-plugins} -通过节点层面的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)， +通过节点层面的[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)， 可以支持不同的网络设施。 -* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) -* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +* 进一步了解[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 了解[动态准入控制](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) * 进一步了解基础设施扩展 - * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) - * [设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) -* 了解 [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/) -* 了解 [Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/) + * [网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +* 了解 [kubectl 插件](/zh-cn/docs/tasks/extend-kubectl/kubectl-plugins/) +* 了解 [Operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index d2a0c6c188..52a0c64e7e 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -32,7 +32,7 @@ The aggregation layer is different from [Custom Resources](/docs/concepts/extend 或者你自己开发的 API。 聚合层不同于 -[定制资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 +[定制资源（Custom Resources）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 后者的目的是让 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 能够认识新的对象类别（Kind）。 @@ -83,10 +83,10 @@ If your extension API server cannot achieve that latency requirement, consider m Alternatively: learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). --> -* 阅读[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档， +* 阅读[配置聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档， 了解如何在自己的环境中启用聚合器。 -* 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)， +* 接下来，了解[安装扩展 API 服务器](/zh-cn/docs/tasks/extend-kubernetes/setup-extension-api-server/)， 开始使用聚合层。 * 从 API 参考资料中研究关于 [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) 的内容。 -或者，学习如何[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 +或者，学习如何[使用自定义资源定义扩展 Kubernetes API](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index e2021c4043..f69c13963f 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -37,9 +37,9 @@ collection of Pod objects. ## 定制资源 *资源（Resource）* 是 -[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) 中的一个端点， +[Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/) 中的一个端点， 其中存储的是某个类别的 -[API 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) +[API 对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/) 的一个集合。 例如内置的 *pods* 资源包含一组 Pod 对象。 @@ -84,7 +84,7 @@ keep the current state of Kubernetes objects in sync with the desired state. The controller interprets the structured data as a record of the user's desired state, and continually maintains this state. --> -使用[声明式 API](/zh/docs/concepts/overview/kubernetes-api/)， +使用[声明式 API](/zh-cn/docs/concepts/overview/kubernetes-api/)， 你可以 _声明_ 或者设定你的资源的期望状态，并尝试让 Kubernetes 对象的当前状态 同步到其期望状态。控制器负责将结构化的数据解释为用户所期望状态的记录，并 持续地维护该状态。 @@ -99,7 +99,7 @@ for specific applications into an extension of the Kubernetes API. --> 你可以在一个运行中的集群上部署和更新定制控制器，这类操作与集群的生命周期无关。 定制控制器可以用于任何类别的资源，不过它们与定制资源结合起来时最为有效。 -[Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)就是将定制资源 +[Operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/)就是将定制资源 与定制控制器相结合的。你可以使用定制控制器来将特定于某应用的领域知识组织 起来，以编码的形式构造对 Kubernetes API 的扩展。 @@ -113,7 +113,7 @@ or let your API stand alone. ## 我是否应该向我的 Kubernetes 集群添加定制资源？ 在创建新的 API 时，请考虑是 -[将你的 API 与 Kubernetes 集群 API 聚合起来](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +[将你的 API 与 Kubernetes 集群 API 聚合起来](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 还是让你的 API 独立运行。 {{< note >}} -请使用 [Secret](/zh/docs/concepts/configuration/secret/) 来保存敏感数据。 +请使用 [Secret](/zh-cn/docs/concepts/configuration/secret/) 来保存敏感数据。 Secret 类似于 configMap，但更为安全。 {{< /note >}} @@ -251,7 +251,7 @@ Kubernetes provides two ways to add custom resources to your cluster: Kubernetes 提供了两种方式供你向集群中添加定制资源： - CRD 相对简单，创建 CRD 可以不必编程。 -- [API 聚合](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +- [API 聚合](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 需要编程，但支持对 API 行为进行更多的控制，例如数据如何存储以及在不同 API 版本间如何转换等。 ## CustomResourceDefinitions -[CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) +[CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) API 资源允许你定义定制资源。 定义 CRD 对象的操作会使用你所设定的名字和模式定义（Schema）创建一个新的定制资源， Kubernetes API 负责为你的定制资源提供存储和访问服务。 CRD 对象的名称必须是合法的 -[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)。 | 特性 | 描述 | CRDs | 聚合 API | | ------- | ----------- | ---- | -------------- | -| 合法性检查 | 帮助用户避免错误，允许你独立于客户端版本演化 API。这些特性对于由很多无法同时更新的客户端的场合。| 可以。大多数验证可以使用 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 来设定。其他合法性检查操作可以通过添加[合法性检查 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)来实现。 | 可以，可执行任何合法性检查。| -| 默认值设置 | 同上 | 可以。可通过 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)的 `default` 关键词（自 1.17 正式发布）或[更改性（Mutating）Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)来实现（不过从 etcd 中读取老的对象时不会执行这些 Webhook）。 | 可以。 | -| 多版本支持 | 允许通过两个 API 版本同时提供同一对象。可帮助简化类似字段更名这类 API 操作。如果你能控制客户端版本，这一特性将不再重要。 | [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning)。 | 可以。 | +| 合法性检查 | 帮助用户避免错误，允许你独立于客户端版本演化 API。这些特性对于由很多无法同时更新的客户端的场合。| 可以。大多数验证可以使用 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 来设定。其他合法性检查操作可以通过添加[合法性检查 Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)来实现。 | 可以，可执行任何合法性检查。| +| 默认值设置 | 同上 | 可以。可通过 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)的 `default` 关键词（自 1.17 正式发布）或[更改性（Mutating）Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)来实现（不过从 etcd 中读取老的对象时不会执行这些 Webhook）。 | 可以。 | +| 多版本支持 | 允许通过两个 API 版本同时提供同一对象。可帮助简化类似字段更名这类 API 操作。如果你能控制客户端版本，这一特性将不再重要。 | [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning)。 | 可以。 | | 定制存储 | 支持使用具有不同性能模式的存储（例如，要使用时间序列数据库而不是键值存储），或者因安全性原因对存储进行隔离（例如对敏感信息执行加密）。 | 不可以。 | 可以。 | -| 定制业务逻辑 | 在创建、读取、更新或删除对象时，执行任意的检查或操作。 | 可以。要使用 [Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 | 可以。 | -| 支持 scale 子资源 | 允许 HorizontalPodAutoscaler 和 PodDisruptionBudget 这类子系统与你的新资源交互。 | [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)。 | 可以。 | -| 支持 status 子资源 | 允许在用户写入 spec 部分而控制器写入 status 部分时执行细粒度的访问控制。允许在对定制资源的数据进行更改时增加对象的代际（Generation）；这需要资源对 spec 和 status 部分有明确划分。| [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource)。 | 可以。 | +| 定制业务逻辑 | 在创建、读取、更新或删除对象时，执行任意的检查或操作。 | 可以。要使用 [Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 | 可以。 | +| 支持 scale 子资源 | 允许 HorizontalPodAutoscaler 和 PodDisruptionBudget 这类子系统与你的新资源交互。 | [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)。 | 可以。 | +| 支持 status 子资源 | 允许在用户写入 spec 部分而控制器写入 status 部分时执行细粒度的访问控制。允许在对定制资源的数据进行更改时增加对象的代际（Generation）；这需要资源对 spec 和 status 部分有明确划分。| [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource)。 | 可以。 | | 其他子资源 | 添加 CRUD 之外的操作，例如 "logs" 或 "exec"。 | 不可以。 | 可以。 | -| strategic-merge-patch | 新的端点要支持标记了 `Content-Type: application/strategic-merge-patch+json` 的 PATCH 操作。对于更新既可在本地更改也可在服务器端更改的对象而言是有用的。要了解更多信息，可参见[使用 `kubectl patch` 来更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 | 不可以。 | 可以。 | +| strategic-merge-patch | 新的端点要支持标记了 `Content-Type: application/strategic-merge-patch+json` 的 PATCH 操作。对于更新既可在本地更改也可在服务器端更改的对象而言是有用的。要了解更多信息，可参见[使用 `kubectl patch` 来更新 API 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 | 不可以。 | 可以。 | | 支持协议缓冲区 | 新的资源要支持想要使用协议缓冲区（Protocol Buffer）的客户端。 | 不可以。 | 可以。 | -| OpenAPI Schema | 是否存在新资源类别的 OpenAPI（Swagger）Schema 可供动态从服务器上读取？是否存在机制确保只能设置被允许的字段以避免用户犯字段拼写错误？是否实施了字段类型检查（换言之，不允许在 `string` 字段设置 `int` 值）？ | 可以，依据 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 模式（1.16 中进入正式发布状态）。 | 可以。| +| OpenAPI Schema | 是否存在新资源类别的 OpenAPI（Swagger）Schema 可供动态从服务器上读取？是否存在机制确保只能设置被允许的字段以避免用户犯字段拼写错误？是否实施了字段类型检查（换言之，不允许在 `string` 字段设置 `int` 值）？ | 可以，依据 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 模式（1.16 中进入正式发布状态）。 | 可以。| ## 访问定制资源 -Kubernetes [客户端库](/zh/docs/reference/using-api/client-libraries/)可用来访问定制资源。 +Kubernetes [客户端库](/zh-cn/docs/reference/using-api/client-libraries/)可用来访问定制资源。 并非所有客户端库都支持定制资源。_Go_ 和 _Python_ 客户端库是支持的。 当你添加了新的定制资源后，可以用如下方式之一访问它们： @@ -553,6 +553,6 @@ Kubernetes [客户端库](/zh/docs/reference/using-api/client-libraries/)可用 * Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). * Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). --> -* 了解如何[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) -* 了解如何[使用 CustomResourceDefinition 来扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) +* 了解如何[使用聚合层扩展 Kubernetes API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +* 了解如何[使用 CustomResourceDefinition 来扩展 Kubernetes API](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index c1f94153e0..90a4494d0f 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -67,7 +67,7 @@ to advertise that the node has 2 "Foo" devices installed and available. * 设备插件的 Unix 套接字。 * 设备插件的 API 版本。 * `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循 - [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)， + [扩展资源命名方案](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources)， 类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。） 成功注册后，设备插件就向 kubelet 发送它所管理的设备列表，然后 kubelet @@ -86,7 +86,7 @@ other resources, with the following differences: * Devices cannot be shared between containers. --> 然后，用户可以请求设备作为 Pod 规范的一部分， -参见[Container](/zh/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)。 +参见[Container](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)。 请求扩展资源类似于管理请求和限制的方式， 其他资源，有以下区别： @@ -441,7 +441,7 @@ it does (for example: hotplug/hotunplug, device health changes), client is expec However, calling `GetAllocatableResources` endpoint is not sufficient in case of cpu and/or memory update and Kubelet needs to be restarted to reflect the correct resource capacity and allocatable. --> -`GetAllocatableResources` 应该仅被用于评估一个节点上的[可分配的](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +`GetAllocatableResources` 应该仅被用于评估一个节点上的[可分配的](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 资源。如果目标是评估空闲/未分配的资源，此调用应该与 List() 端点一起使用。 除非暴露给 kubelet 的底层资源发生变化 否则 `GetAllocatableResources` 得到的结果将保持不变。 这种情况很少发生，但当发生时（例如：热插拔，设备健康状况改变），客户端应该调用 `GetAlloctableResources` 端点。 @@ -471,7 +471,7 @@ Preceding Kubernetes v1.23, to enable this feature `kubelet` must be started wit --> 从 Kubernetes v1.23 开始，`GetAllocatableResources` 被默认启用。 你可以通过关闭 `KubeletPodResourcesGetAllocatable` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 来禁用。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 来禁用。 在 Kubernetes v1.23 之前，要启用这一功能，`kubelet` 必须用以下标志启动： @@ -484,7 +484,7 @@ plugins report [when they register themselves to the kubelet](/docs/concepts/ext --> `ContainerDevices` 会向外提供各个设备所隶属的 NUMA 单元这类拓扑信息。 NUMA 单元通过一个整数 ID 来标识，其取值与设备插件所报告的一致。 -[设备插件注册到 kubelet 时](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +[设备插件注册到 kubelet 时](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 会报告这类信息。 -* 查看[调度 GPU 资源](/zh/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 -* 查看在上如何[公布节点上的扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/) -* 学习[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/) -* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](/zh/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) +* 查看[调度 GPU 资源](/zh-cn/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 +* 查看在上如何[公布节点上的扩展资源](/zh-cn/docs/tasks/administer-cluster/extended-resource-node/) +* 学习[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/) +* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](/zh-cn/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/operator.md b/content/zh-cn/docs/concepts/extend-kubernetes/operator.md index 7dd8e6fbd3..5403556037 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/operator.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/operator.md @@ -19,9 +19,9 @@ to manage applications and their components. Operators follow Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller/). --> Operator 是 Kubernetes 的扩展软件，它利用 -[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +[定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 管理应用及其组件。 -Operator 遵循 Kubernetes 的理念，特别是在[控制器](/zh/docs/concepts/architecture/controller/) +Operator 遵循 Kubernetes 的理念，特别是在[控制器](/zh-cn/docs/concepts/architecture/controller/) 方面。 @@ -67,7 +67,7 @@ Kubernetes 的 {{< glossary_tooltip text="Operator 模式" term_id="operator-pat Kubernetes 自身代码的情况下，通过为一个或多个自定义资源关联{{< glossary_tooltip text="控制器" term_id="controller" >}} 来扩展集群的能力。 Operator 是 Kubernetes API 的客户端，充当 -[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 的控制器。 * 阅读 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [Operator 白皮书](https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md)。 -* 详细了解 [定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 详细了解 [定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合你的 Operator * [发布](https://operatorhub.io/)你的 Operator，让别人也可以使用 * 阅读 [CoreOS 原始文章](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html)，它介绍了 Operator 模式（这是一个存档版本的原始文章）。 diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md b/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md index fe5437c1ba..cb4eb28e40 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md @@ -66,7 +66,7 @@ It is implemented using a [CRDs-based](/docs/concepts/extend-kubernetes/api-exte 与服务代理进行通信，并作为 Kubernetes API 服务器的中介，以便协商启动部署和获取 应用程序使用托管服务时必须的凭据。 -它是[基于 CRDs](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) +它是[基于 CRDs](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) 架构实现的。 ![服务目录架构](/images/docs/service-catalog-architecture.svg) @@ -436,9 +436,9 @@ The following example describes how to map secret values into application enviro * Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project. --> * 如果你熟悉 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}， - 可以[使用 Helm 安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-helm/) + 可以[使用 Helm 安装服务目录](/zh-cn/docs/tasks/service-catalog/install-service-catalog-using-helm/) 到 Kubernetes 集群中。或者，你可以 - [使用 SC 工具安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-sc/)。 + [使用 SC 工具安装服务目录](/zh-cn/docs/tasks/service-catalog/install-service-catalog-using-sc/)。 * 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) * 浏览 [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 项目 diff --git a/content/zh-cn/docs/concepts/overview/components.md b/content/zh-cn/docs/concepts/overview/components.md index 902edf5cd3..e7f844aaa6 100644 --- a/content/zh-cn/docs/concepts/overview/components.md +++ b/content/zh-cn/docs/concepts/overview/components.md @@ -63,7 +63,7 @@ for an example control plane setup that runs across multiple machines. 控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。 -请参阅[使用 kubeadm 构建高可用性集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) +请参阅[使用 kubeadm 构建高可用性集群](/zh-cn/docs/setup/production-environment/tools/kubeadm/high-availability/) 中关于跨多机器控制平面设置的示例。 ### kube-apiserver @@ -177,7 +177,7 @@ Selected addons are described below; for an extended list of available addons, p see [Addons](/docs/concepts/cluster-administration/addons/). --> 下面描述众多插件中的几种。有关可用插件的完整列表，请参见 -[插件（Addons）](/zh/docs/concepts/cluster-administration/addons/)。 +[插件（Addons）](/zh-cn/docs/concepts/cluster-administration/addons/)。 ### Web 界面（仪表盘） {#web-ui-dashboard} -[Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) +[Dashboard](/zh-cn/docs/tasks/access-application-cluster/web-ui-dashboard/) 是 Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身， 并进行故障排除。 @@ -218,7 +218,7 @@ about containers in a central database, and provides a UI for browsing that data --> ### 容器资源监控 {#container-resource-monitoring} -[容器资源监控](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) +[容器资源监控](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中， 并提供浏览这些数据的界面。 @@ -230,7 +230,7 @@ saving container logs to a central log store with search/browsing interface. --> ### 集群层面日志 {#cluster-level-logging} -[集群层面日志](/zh/docs/concepts/cluster-administration/logging/) +[集群层面日志](/zh-cn/docs/concepts/cluster-administration/logging/) 机制负责将容器的日志数据保存到一个集中的日志存储中， 这种集中日志存储提供搜索和浏览接口。 @@ -242,7 +242,7 @@ saving container logs to a central log store with search/browsing interface. * Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) * Read etcd's official [documentation](https://etcd.io/docs/) --> -* 进一步了解[节点](/zh/docs/concepts/architecture/nodes/) -* 进一步了解[控制器](/zh/docs/concepts/architecture/controller/) -* 进一步了解 [kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) +* 进一步了解[节点](/zh-cn/docs/concepts/architecture/nodes/) +* 进一步了解[控制器](/zh-cn/docs/concepts/architecture/controller/) +* 进一步了解 [kube-scheduler](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/) * 阅读 etcd 官方[文档](https://etcd.io/docs/) diff --git a/content/zh-cn/docs/concepts/overview/kubernetes-api.md b/content/zh-cn/docs/concepts/overview/kubernetes-api.md index 52b9c32b1e..ce6a1575d7 100644 --- a/content/zh-cn/docs/concepts/overview/kubernetes-api.md +++ b/content/zh-cn/docs/concepts/overview/kubernetes-api.md @@ -35,8 +35,8 @@ API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和 Kubernetes API 使你可以查询和操纵 Kubernetes API 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。 -大部分操作都可以通过 [kubectl](/zh/docs/reference/kubectl/) 命令行接口或 -类似 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行， +大部分操作都可以通过 [kubectl](/zh-cn/docs/reference/kubectl/) 命令行接口或 +类似 [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行， 这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。 如果你正在编写程序来访问 Kubernetes API，可以考虑使用 -[客户端库](/zh/docs/reference/using-api/client-libraries/)之一。 +[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)之一。 @@ -157,7 +157,7 @@ for the kube-apiserver component. Kubernetes {{< param "version" >}} 提供将其 API 以 OpenAPI v3 形式发布的 beta 支持； 这一功能特性处于 beta 状态，默认被开启。 你可以通过为 kube-apiserver 组件关闭 `OpenAPIV3` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来禁用此 beta 特性。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来禁用此 beta 特性。 一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。 删除资源或者字段则要遵从 -[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。 +[API 废弃策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 关于 API 版本分级的定义细节，请参阅 -[API 版本参考](/zh/docs/reference/using-api/#api-versioning)页面。 +[API 版本参考](/zh-cn/docs/reference/using-api/#api-versioning)页面。 -1. 你可以使用[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +1. 你可以使用[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 来以声明式方式定义 API 服务器如何提供你所选择的资源 API。 1. 你也可以选择实现自己的 - [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) + [聚合层](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 来扩展 Kubernetes API。 ## {{% heading "whatsnext" %}} @@ -323,11 +323,11 @@ The Kubernetes API can be extended in one of two ways: [API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). --> - 了解如何通过添加你自己的 - [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) + [CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) 来扩展 Kubernetes API。 -- [控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)页面描述了集群如何针对 +- [控制 Kubernetes API 访问](/zh-cn/docs/concepts/security/controlling-access/)页面描述了集群如何针对 API 访问管理身份认证和鉴权。 -- 通过阅读 [API 参考](/zh/docs/reference/kubernetes-api/)了解 API 端点、资源类型以及示例。 +- 通过阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/)了解 API 端点、资源类型以及示例。 - 阅读 [API 变更（英文）](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme) 以了解什么是兼容性的变更以及如何变更 API。 diff --git a/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md b/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md index e26ea7c861..25feebb7fc 100644 --- a/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md @@ -273,5 +273,5 @@ Kubernetes： * Take a look at the [Kubernetes Components](/docs/concepts/overview/components/) * Ready to [Get Started](/docs/setup/)? --> -* 查阅[Kubernetes 组件](/zh/docs/concepts/overview/components/) -* 开始[Kubernetes 的建置](/zh/docs/setup/)吧！ +* 查阅[Kubernetes 组件](/zh-cn/docs/concepts/overview/components/) +* 开始[Kubernetes 的建置](/zh-cn/docs/setup/)吧！ diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md b/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md index 4d2ff7fc6f..c8a03e0bc6 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md @@ -163,5 +163,5 @@ spec: -* 进一步了解[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。 +* 进一步了解[标签和选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md b/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md index f5a78976da..35fc5cdda4 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md @@ -11,7 +11,7 @@ weight: 60 _Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/working-with-objects/kubernetes-objects) based on the value of one or more resource fields. Here are some example field selector queries: --> “字段选择器（Field selectors）”允许你根据一个或多个资源字段的值 -[筛选 Kubernetes 资源](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。 +[筛选 Kubernetes 资源](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects)。 下面是一些使用字段选择器查询的例子： * `metadata.name=my-service` @@ -21,7 +21,7 @@ _Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/ -下面这个 `kubectl` 命令将筛选出 [`status.phase`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) +下面这个 `kubectl` 命令将筛选出 [`status.phase`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) 字段值为 `Running` 的所有 Pod： ```shell @@ -81,7 +81,7 @@ As with [label](/docs/concepts/overview/working-with-objects/labels) and other s --> ## 链式选择器 {#chained-selectors} -同[标签](/zh/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样， +同[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样， 字段选择器可以通过使用逗号分隔的列表组成一个选择链。 下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod： diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md b/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md index 6a0a784fcf..db6f51514f 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md @@ -99,7 +99,7 @@ any Pods in the cluster with the same label. ## 属主引用、标签和 Finalizers {#owners-labels-finalizers} 与{{}}类似， -[属主引用](/zh/concepts/overview/working-with-objects/owners-dependents/) +[属主引用](/zh-cn/concepts/overview/working-with-objects/owners-dependents/) 描述了 Kubernetes 中对象之间的关系，但它们作用不同。 当一个{{}} 管理类似于 Pod 的对象时，它使用标签来跟踪相关对象组的变化。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 1cd32dc950..36c1212fcd 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -64,7 +64,7 @@ Kubernetes 对象是“目标性记录”——一旦创建对象，Kubernetes 这就是 Kubernetes 集群所谓的 **期望状态（Desired State）**。 操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 -[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api)。 +[Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api)。 比如，当使用 `kubectl` 命令行接口（CLI）时，CLI 会调用必要的 Kubernetes API； 也可以在程序中使用[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)， 来直接调用 Kubernetes API。 @@ -217,7 +217,7 @@ detail the structure of that `.status` field, and its content for each different 另一个对象规约的例子是 StatefulSet API 中的 [`spec` 字段](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)。 对于 StatefulSet 而言，其 `.spec` 字段设置了 StatefulSet 及其期望状态。 -在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的[模板](/zh/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。 +在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的[模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。 不同类型的对象可以由不同的 `.status` 信息。API 参考页面给出了 `.status` 字段的详细结构， 以及针对不同类型 API 对象的具体内容。 @@ -228,7 +228,7 @@ detail the structure of that `.status` field, and its content for each different * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes. * [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts. --> -* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)。 -* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)。 -* [使用 Kubernetes API](/zh/docs/reference/using-api/) 一节解释了一些 API 概念。 +* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh-cn/docs/concepts/workloads/pods/)。 +* 了解 Kubernetes 中的[控制器](/zh-cn/docs/concepts/architecture/controller/)。 +* [使用 Kubernetes API](/zh-cn/docs/reference/using-api/) 一节解释了一些 API 概念。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md b/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md index a1840bacbd..650eb02a4e 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md @@ -40,7 +40,7 @@ and CLIs. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/). --> 标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。 -应使用[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)记录非识别信息。 +应使用[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)记录非识别信息。 @@ -72,7 +72,7 @@ Example labels: -有一些[常用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)的例子；你可以任意制定自己的约定。 +有一些[常用标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/)的例子；你可以任意制定自己的约定。 请记住，标签的 Key 对于给定对象必须是唯一的。 ## 标签选择算符 {#label-selectors} -与[名称和 UID](/zh/docs/concepts/overview/working-with-objects/names/) 不同， +与[名称和 UID](/zh-cn/docs/concepts/overview/working-with-objects/names/) 不同， 标签不支持唯一性。通常，我们希望许多对象携带相同的标签。 ### 在 API 对象中设置引用 -一些 Kubernetes 对象，例如 [`services`](/zh/docs/concepts/services-networking/service/) -和 [`replicationcontrollers`](/zh/docs/concepts/workloads/controllers/replicationcontroller/) ， +一些 Kubernetes 对象，例如 [`services`](/zh-cn/docs/concepts/services-networking/service/) +和 [`replicationcontrollers`](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/) ， 也使用了标签选择算符去指定了其他资源的集合，例如 -[pods](/zh/docs/concepts/workloads/pods/)。 +[pods](/zh-cn/docs/concepts/workloads/pods/)。 #### 支持基于集合需求的资源 -比较新的资源，例如 [`Job`](/zh/docs/concepts/workloads/controllers/job/)、 -[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)、 -[`Replica Set`](/zh/docs/concepts/workloads/controllers/replicaset/) 和 -[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/)， +比较新的资源，例如 [`Job`](/zh-cn/docs/concepts/workloads/controllers/job/)、 +[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/)、 +[`Replica Set`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 和 +[`DaemonSet`](/zh-cn/docs/concepts/workloads/controllers/daemonset/)， 也支持 _基于集合的_ 需求。 ```yaml @@ -400,5 +400,5 @@ See the documentation on [node selection](/docs/concepts/configuration/assign-po #### 选择节点集 通过标签进行选择的一个用例是确定节点集，方便 Pod 调度。 -有关更多信息，请参阅[选择节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)文档。 +有关更多信息，请参阅[选择节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)文档。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/names.md b/content/zh-cn/docs/concepts/overview/working-with-objects/names.md index e7ccb39110..91eb354810 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/names.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/names.md @@ -17,15 +17,15 @@ For example, you can only have one Pod named `myapp-1234` within the same [names 每个 Kubernetes 对象也有一个 [_UID_](#uids) 来标识在整个集群中的唯一性。 -比如，在同一个[名字空间](/zh/docs/concepts/overview/working-with-objects/namespaces/) +比如，在同一个[名字空间](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/) 中有一个名为 `myapp-1234` 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。 对于用户提供的非唯一性的属性，Kubernetes 提供了 -[标签（Labels）](/zh/docs/concepts/working-with-objects/labels)和 -[注解（Annotation）](/zh/docs/concepts/overview/working-with-objects/annotations/)机制。 +[标签（Labels）](/zh-cn/docs/concepts/working-with-objects/labels)和 +[注解（Annotation）](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)机制。 @@ -173,7 +173,7 @@ UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。 * Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes. * See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document. --> -* 进一步了解 Kubernetes [标签](/zh/docs/concepts/overview/working-with-objects/labels/) +* 进一步了解 Kubernetes [标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/) * 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)的设计文档 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md index 62d47ad897..46c3f35ac9 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md @@ -49,7 +49,7 @@ resource can only be in one namespace. -名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh/docs/concepts/policy/resource-quotas/)）。 +名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)）。 ## 使用名字空间 -名字空间的创建和删除在[名字空间的管理指南文档](/zh/docs/tasks/administer-cluster/namespaces/)描述。 +名字空间的创建和删除在[名字空间的管理指南文档](/zh-cn/docs/tasks/administer-cluster/namespaces/)描述。 ## 名字空间和 DNS -当你创建一个[服务](/zh/docs/concepts/services-networking/service/)时， -Kubernetes 会创建一个相应的 [DNS 条目](/zh/docs/concepts/services-networking/dns-pod-service/)。 +当你创建一个[服务](/zh-cn/docs/concepts/services-networking/service/)时， +Kubernetes 会创建一个相应的 [DNS 条目](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。 因此，所有的名字空间名称都必须是合法的 -[RFC 1123 DNS 标签](/zh/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 +[RFC 1123 DNS 标签](/zh-cn/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 {{< warning >}} 为了缓解这类问题，需要将创建名字空间的权限授予可信的用户。 如果需要，你可以额外部署第三方的安全控制机制，例如以 -[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) 的形式，阻止用户创建与公共 [TLD](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) 同名的名字空间。 {{< /warning >}} @@ -224,7 +224,7 @@ persistentVolumes, are not in any namespace. --> 大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。 但是名字空间资源本身并不在名字空间中。而且底层资源，例如 -[节点](/zh/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。 +[节点](/zh-cn/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。 -* 进一步了解[建立新的名字空间](/zh/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。 -* 进一步了解[删除名字空间](/zh/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。 +* 进一步了解[建立新的名字空间](/zh-cn/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。 +* 进一步了解[删除名字空间](/zh-cn/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md b/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md index b1dd99ca60..47c758d267 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md @@ -325,10 +325,10 @@ Disadvantages compared to imperative object configuration: - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) --> -- [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/) -- [使用对象配置管理 Kubernetes 对象（指令式）](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/) -- [使用对象配置管理 Kubernetes 对象（声明式）](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/) -- [使用 Kustomize（声明式）管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/) +- [使用指令式命令管理 Kubernetes 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/imperative-command/) +- [使用对象配置管理 Kubernetes 对象（指令式）](/zh-cn/docs/tasks/manage-kubernetes-objects/imperative-config/) +- [使用对象配置管理 Kubernetes 对象（声明式）](/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config/) +- [使用 Kustomize（声明式）管理 Kubernetes 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/kustomization/) - [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/) - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md b/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md index b7f5d0cb71..a02810877f 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md @@ -31,7 +31,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， 该 Service 使用标签来让控制平面确定，哪些 `EndpointSlice` 对象属于该 Service。 除开标签，每个代表 Service 所管理的 `EndpointSlice` 都有一个属主引用。 @@ -132,7 +132,7 @@ bound to a Pod. ## 属主关系与 Finalizer {#ownership-and-finalizers} 当你告诉 Kubernetes 删除一个资源，API 服务器允许管理控制器处理该资源的任何 -[Finalizer 规则](/zh/docs/concepts/overview/working-with-objects/finalizers/)。 +[Finalizer 规则](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。 {{}} 防止意外删除你的集群所依赖的、用于正常运作的资源。 例如，如果你试图删除一个仍被 Pod 使用的 `PersistentVolume`，该资源不会被立即删除， @@ -150,7 +150,7 @@ specify an orphan deletion policy, Kubernetes adds the `orphan` finalizer so that the controller ignores dependent resources after it deletes the owner object. --> -当你使用[前台或孤立级联删除](/zh/docs/concepts/architecture/garbage-collection/#cascading-deletion)时， +当你使用[前台或孤立级联删除](/zh-cn/docs/concepts/architecture/garbage-collection/#cascading-deletion)时， Kubernetes 也会向属主资源添加 Finalizer。 在前台删除中，会添加 `foreground` Finalizer，这样控制器必须在删除了拥有 `ownerReferences.blockOwnerDeletion=true` 的附属资源后，才能删除属主对象。 @@ -164,6 +164,6 @@ Kubernetes 也会向属主资源添加 Finalizer。 * Learn about [garbage collection](/docs/concepts/architecture/garbage-collection). * Read the API reference for [object metadata](/docs/reference/kubernetes-api/common-definitions/object-meta/#System). --> -* 了解更多关于 [Kubernetes Finalizer](/zh/docs/concepts/overview/working-with-objects/finalizers/)。 -* 了解关于[垃圾收集](/zh/docs/concepts/architecture/garbage-collection)。 +* 了解更多关于 [Kubernetes Finalizer](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。 +* 了解关于[垃圾收集](/zh-cn/docs/concepts/architecture/garbage-collection)。 * 阅读[对象元数据](/docs/reference/kubernetes-api/common-definitions/object-meta/#System)的 API 参考文档。 diff --git a/content/zh-cn/docs/concepts/policy/limit-range.md b/content/zh-cn/docs/concepts/policy/limit-range.md index 8412d9e80c..da2560b6a0 100644 --- a/content/zh-cn/docs/concepts/policy/limit-range.md +++ b/content/zh-cn/docs/concepts/policy/limit-range.md @@ -11,7 +11,7 @@ By default, containers run with unbounded [compute resources](/docs/concepts/con With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis. Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace. --> -默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)没有限制。 +默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)没有限制。 使用资源配额，集群管理员可以以{{< glossary_tooltip text="名字空间" term_id="namespace" >}}为单位，限制其资源的使用与创建。 在命名空间中，一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。 有人担心，一个 Pod 或 Container 会垄断所有可用的资源。 @@ -53,7 +53,7 @@ The name of a LimitRange object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> LimitRange 的名称必须是合法的 -[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)。 关于使用限值的例子，可参看 -- [如何配置每个命名空间最小和最大的 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 -- [如何配置每个命名空间最小和最大的内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 -- [如何配置每个命名空间默认的 CPU 申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 -- [如何配置每个命名空间默认的内存申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 -- [如何配置每个命名空间最小和最大存储使用量](/zh/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 -- [配置每个命名空间的配额的详细例子](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。 +- [如何配置每个命名空间最小和最大的 CPU 约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 +- [如何配置每个命名空间最小和最大的内存约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 +- [如何配置每个命名空间默认的 CPU 申请值和限制值](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 +- [如何配置每个命名空间默认的内存申请值和限制值](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 +- [如何配置每个命名空间最小和最大存储使用量](/zh-cn/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 +- [配置每个命名空间的配额的详细例子](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。 diff --git a/content/zh-cn/docs/concepts/policy/node-resource-managers.md b/content/zh-cn/docs/concepts/policy/node-resource-managers.md index 73f28da383..5636547075 100644 --- a/content/zh-cn/docs/concepts/policy/node-resource-managers.md +++ b/content/zh-cn/docs/concepts/policy/node-resource-managers.md @@ -30,7 +30,7 @@ The main manager, the Topology Manager, is a Kubelet component that co-ordinates The configuration of individual managers is elaborated in dedicated documents: --> 主管理器，也叫拓扑管理器（Topology Manager），是一个 Kubelet 组件， -它通过[策略](/zh/docs/tasks/administer-cluster/topology-manager/)， +它通过[策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)， 协调全局的资源管理过程。 各个管理器的配置方式会在专项文档中详细阐述： @@ -40,6 +40,6 @@ The configuration of individual managers is elaborated in dedicated documents: - [Device Manager](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) - [Memory Manager Policies](/docs/tasks/administer-cluster/memory-manager/) --> -- [CPU 管理器策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/) -- [设备管理器](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) -- [内存管理器策略](/zh/docs/tasks/administer-cluster/memory-manager/) +- [CPU 管理器策略](/zh-cn/docs/tasks/administer-cluster/cpu-management-policies/) +- [设备管理器](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) +- [内存管理器策略](/zh-cn/docs/tasks/administer-cluster/memory-manager/) diff --git a/content/zh-cn/docs/concepts/policy/pid-limiting.md b/content/zh-cn/docs/concepts/policy/pid-limiting.md index 85b1c531aa..61fed9674b 100644 --- a/content/zh-cn/docs/concepts/policy/pid-limiting.md +++ b/content/zh-cn/docs/concepts/policy/pid-limiting.md @@ -105,7 +105,7 @@ and limits. However, you specify it in a different way: rather than defining a Pod's resource limit in the `.spec` for a Pod, you configure the limit as a setting on the kubelet. Pod-defined PID limits are not currently supported. --> -PID 限制是与[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/) +PID 限制是与[计算资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/) 请求和限制相辅相成的一种机制。不过，你需要用一种不同的方式来设置这一限制： 你需要将其设置到 kubelet 上而不是在 Pod 的 `.spec` 中为 Pod 设置资源限制。 目前还不支持在 Pod 级别设置 PID 限制。 @@ -146,7 +146,7 @@ gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` to work. --> 在 Kubernetes 1.20 版本之前，在节点级别通过 PID 资源限制预留 PID 的能力 -需要启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +需要启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` 才行。 {{< /note >}} @@ -166,7 +166,7 @@ Kubernetes 允许你限制 Pod 中运行的进程个数。你可以在节点级 而不是为特定的 Pod 来将其设置为资源限制。 每个节点都可以有不同的 PID 限制设置。 要设置限制值，你可以设置 kubelet 的命令行参数 `--pod-max-pids`，或者 -在 kubelet 的[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/) +在 kubelet 的[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 中设置 `PodPidsLimit`。 {{< note >}} @@ -176,7 +176,7 @@ the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportPodPidsLimit` to work. --> 在 Kubernetes 1.20 版本之前，为 Pod 设置 PID 资源限制的能力需要启用 -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` 才行。 {{< /note >}} @@ -197,7 +197,7 @@ Eviction signal value is calculated periodically and does NOT enforce the limit. 你可以配置 kubelet 使之在 Pod 行为不正常或者消耗不正常数量资源的时候将其终止。 这一特性称作驱逐。你可以针对不同的驱逐信号 -[配置资源不足的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 +[配置资源不足的处理](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 使用 `pid.available` 驱逐信号来配置 Pod 使用的 PID 个数的阈值。 你可以设置硬性的和软性的驱逐策略。不过，即使使用硬性的驱逐策略， 如果 PID 个数增长过快，节点仍然可能因为触及节点 PID 限制而进入一种不稳定状态。 @@ -233,6 +233,6 @@ Pod 行为不正常而没有 PID 可用。 - 关于历史背景，请阅读 [Kubernetes 1.14 中限制进程 ID 以提升稳定性](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/) 的博文。 -- 请阅读[为容器管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。 -- 学习如何[配置资源不足情况的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 +- 请阅读[为容器管理资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。 +- 学习如何[配置资源不足情况的处理](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。