[zh]Update concepts pages(part-2) for links with '/zh/' prefix, using new prefix '/zh-cn/'
This commit is contained in:
howieyuen
@@ -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/).
|
||||
|
||||
<!--
|
||||
Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
|
||||
@@ -97,16 +97,16 @@ Flags and configuration files may not always be changeable in a hosted Kubernete
|
||||
<!--
|
||||
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
|
||||
-->
|
||||
*内置的策略 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 的方案应该优先于配置文件和参数标志。
|
||||
|
||||
<!--
|
||||
@@ -178,8 +178,8 @@ Kubernetes control plane.
|
||||
在 Webhook 模式中，Kubernetes 向远程服务发起网络请求。
|
||||
在 **可执行文件插件（Binary Plugin）** 模式中，Kubernetes
|
||||
执行某个可执行文件（程序）。可执行文件插件在 kubelet （例如，
|
||||
[FlexVolume 插件](/zh/docs/concepts/storage/volumes/#flexvolume))
|
||||
和[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)）
|
||||
[FlexVolume 插件](/zh-cn/docs/concepts/storage/volumes/#flexvolume))
|
||||
和[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)）
|
||||
和 kubectl 中使用。
|
||||
|
||||
下面的示意图中展示了这些扩展点如何与 Kubernetes 控制面交互。
|
||||
@@ -217,7 +217,7 @@ This diagram shows the extension points in a Kubernetes system.
|
||||
If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
|
||||
-->
|
||||
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/)。
|
||||
|
||||
<!--
|
||||
### Combining New APIs with Automation
|
||||
@@ -283,7 +283,7 @@ The combination of a custom resource API and a control loop is called the [Opera
|
||||
### 结合使用新 API 与自动化组件 {#combinding-new-apis-with-automation}
|
||||
|
||||
自定义资源 API 与控制回路的组合称作
|
||||
[Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)。
|
||||
[Operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/)。
|
||||
Operator 模式用来管理特定的、通常是有状态的应用。
|
||||
这些自定义 API 和控制回路也可用来控制其他资源，如存储或策略。
|
||||
|
||||
@@ -313,14 +313,14 @@ Kubernetes has several built-in authentication methods that it supports. It can
|
||||
|
||||
当请求到达 Kubernetes API 服务器时，首先要经过身份认证，之后是鉴权操作，
|
||||
再之后要经过若干类型的准入控制器的检查。
|
||||
参见[控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)
|
||||
参见[控制 Kubernetes API 访问](/zh-cn/docs/concepts/security/controlling-access/)
|
||||
以了解此流程的细节。
|
||||
|
||||
这些步骤中都存在扩展点。
|
||||
|
||||
Kubernetes 提供若干内置的身份认证方法。它也可以运行在某种身份认证代理的后面，
|
||||
并且可以将来自鉴权头部的令牌发送到某个远程服务（Webhook）来执行验证操作。
|
||||
所有这些方法都在[身份认证文档](/zh/docs/reference/access-authn-authz/authentication/)
|
||||
所有这些方法都在[身份认证文档](/zh-cn/docs/reference/access-authn-authz/authentication/)
|
||||
中有详细论述。
|
||||
|
||||
<!--
|
||||
@@ -332,11 +332,11 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
|
||||
-->
|
||||
### 身份认证 {#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)
|
||||
方法以备内置方法无法满足你的要求。
|
||||
|
||||
<!--
|
||||
@@ -346,12 +346,12 @@ Kubernetes 提供若干种内置的认证方法，以及
|
||||
-->
|
||||
### 鉴权 {#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/)来调用用户提供
|
||||
的代码，执行定制的鉴权操作。
|
||||
|
||||
<!--
|
||||
@@ -365,13 +365,13 @@ After a request is authorized, if it is a write operation, it also goes through
|
||||
### 动态准入控制 {#dynamic-admission-control}
|
||||
|
||||
请求的鉴权操作结束之后，如果请求的是写操作，还会经过
|
||||
[准入控制](/zh/docs/reference/access-authn-authz/admission-controllers/)处理步骤。
|
||||
[准入控制](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)处理步骤。
|
||||
除了内置的处理步骤，还存在一些扩展点：
|
||||
|
||||
* [镜像策略 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)
|
||||
* [镜像策略 Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook)
|
||||
能够限制容器中可以运行哪些镜像。
|
||||
* 为了执行任意的准入控制，可以使用一种通用的
|
||||
[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
|
||||
[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
|
||||
机制。这类 Webhook 可以拒绝对象创建或更新请求。
|
||||
|
||||
<!--
|
||||
@@ -412,12 +412,12 @@ Different networking fabrics can be supported via node-level [Network Plugins](/
|
||||
-->
|
||||
### 设备插件 {#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/)，
|
||||
可以支持不同的网络设施。
|
||||
|
||||
<!--
|
||||
@@ -442,7 +442,7 @@ the nodes chosen for a pod.
|
||||
调度器是一种特殊的控制器，负责监视 Pod 变化并将 Pod 分派给节点。
|
||||
默认的调度器可以被整体替换掉，同时继续使用其他 Kubernetes 组件。
|
||||
或者也可以在同一时刻使用
|
||||
[多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)。
|
||||
[多个调度器](/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)。
|
||||
|
||||
这是一项非同小可的任务，几乎绝大多数 Kubernetes
|
||||
用户都会发现其实他们不需要修改调度器。
|
||||
@@ -462,11 +462,11 @@ the nodes chosen for a pod.
|
||||
* Learn about [kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/)
|
||||
* Learn about the [Operator pattern](/docs/concepts/extend-kubernetes/operator/)
|
||||
-->
|
||||
* 进一步了解[自定义资源](/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/)
|
||||
|
||||
|
||||
+4
-4
@@ -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/)。
|
||||
|
||||
@@ -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 独立运行。
|
||||
|
||||
<!--
|
||||
@@ -133,7 +133,7 @@ or let your API stand alone.
|
||||
| 你希望可以是使用 `kubectl` 来读写你的新资源类别。 | 不要求 `kubectl` 支持。 |
|
||||
| 你希望在 Kubernetes UI （如仪表板）中和其他内置类别一起查看你的新资源类别。 | 不需要 Kubernetes UI 支持。 |
|
||||
| 你在开发新的 API。 | 你已经有一个提供 API 服务的程序并且工作良好。 |
|
||||
| 你有意愿取接受 Kubernetes 对 REST 资源路径所作的格式限制，例如 API 组和名字空间。（参阅 [API 概述](/zh/docs/concepts/overview/kubernetes-api/)） | 你需要使用一些特殊的 REST 路径以便与已经定义的 REST API 保持兼容。 |
|
||||
| 你有意愿取接受 Kubernetes 对 REST 资源路径所作的格式限制，例如 API 组和名字空间。（参阅 [API 概述](/zh-cn/docs/concepts/overview/kubernetes-api/)） | 你需要使用一些特殊的 REST 路径以便与已经定义的 REST API 保持兼容。 |
|
||||
| 你的资源可以自然地界定为集群作用域或集群中某个名字空间作用域。 | 集群作用域或名字空间作用域这种二分法很不合适；你需要对资源路径的细节进行控制。 |
|
||||
| 你希望复用 [Kubernetes API 支持特性](#common-features)。 | 你不需要这类特性。 |
|
||||
|
||||
@@ -214,7 +214,7 @@ Use a ConfigMap if any of the following apply:
|
||||
Use a [secret](/docs/concepts/configuration/secret/) for sensitive data, which is similar to a configMap but more secure.
|
||||
-->
|
||||
{{< 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 版本间如何转换等。
|
||||
|
||||
<!--
|
||||
@@ -267,7 +267,7 @@ Kubernetes 提供这两种选项以满足不同用户的需求，这样就既不
|
||||
|
||||
聚合 API 指的是一些下位的 API 服务器，运行在主 API 服务器后面；主 API
|
||||
服务器以代理的方式工作。这种组织形式称作
|
||||
[API 聚合（API Aggregation，AA）](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 。
|
||||
[API 聚合（API Aggregation，AA）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 。
|
||||
对用户而言，看起来仅仅是 Kubernetes API 被扩展了。
|
||||
|
||||
CRD 允许用户创建新的资源类别同时又不必添加新的 API 服务器。
|
||||
@@ -288,12 +288,12 @@ The name of a CRD object must be a valid
|
||||
-->
|
||||
## 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)。
|
||||
|
||||
<!--
|
||||
This frees you from writing your own API server to handle the custom resource,
|
||||
@@ -327,7 +327,7 @@ making them available to all of its clients.
|
||||
Kubernetes API 主服务器能够处理诸如 *pods* 和 *services* 这些内置资源，也可以
|
||||
按通用的方式通过 [CRD](#customresourcedefinitions) 来处理定制资源。
|
||||
|
||||
[聚合层（Aggregation Layer）](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
|
||||
[聚合层（Aggregation Layer）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
|
||||
使得你可以通过编写和部署你自己的 API 服务器来为定制资源提供特殊的实现。
|
||||
主 API 服务器将针对你要处理的定制资源的请求全部委托给你自己的 API 服务器来处理，同时将这些资源
|
||||
提供给其所有客户端。
|
||||
@@ -402,17 +402,17 @@ Aggregated APIs offer more advanced API features and customization of other feat
|
||||
-->
|
||||
| 特性 | 描述 | 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 中进入正式发布状态）。 | 可以。|
|
||||
|
||||
<!--
|
||||
### Common Features
|
||||
@@ -535,7 +535,7 @@ When you add a custom resource, you can access it using:
|
||||
-->
|
||||
## 访问定制资源
|
||||
|
||||
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/)
|
||||
|
||||
|
||||
+10
-10
@@ -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/)
|
||||
会报告这类信息。
|
||||
|
||||
<!--
|
||||
@@ -509,7 +509,7 @@ gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接
|
||||
{{< glossary_tooltip text="卷" term_id="volume" >}}的形式被挂载到设备监控代理中。
|
||||
|
||||
对“PodResourcesLister 服务”的支持要求启用 `KubeletPodResources`
|
||||
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。
|
||||
从 Kubernetes 1.15 开始默认启用，自从 Kubernetes 1.20 开始为 v1。
|
||||
|
||||
<!--
|
||||
@@ -596,7 +596,7 @@ Here are some examples of device plugin implementations:
|
||||
* Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/)
|
||||
* Read about using [hardware acceleration for TLS ingress](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
|
||||
-->
|
||||
* 查看[调度 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/)
|
||||
|
||||
@@ -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/)
|
||||
方面。
|
||||
|
||||
<!-- body -->
|
||||
@@ -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/)
|
||||
的控制器。
|
||||
|
||||
<!--
|
||||
@@ -202,7 +202,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
|
||||
|
||||
如果生态系统中没可以实现你目标的 Operator，你可以自己编写代码。
|
||||
|
||||
你还可以使用任何支持 [Kubernetes API 客户端](/zh/docs/reference/using-api/client-libraries/)
|
||||
你还可以使用任何支持 [Kubernetes API 客户端](/zh-cn/docs/reference/using-api/client-libraries/)
|
||||
的语言或运行时来实现 Operator（即控制器）。
|
||||
|
||||
<!--
|
||||
@@ -248,7 +248,7 @@ you implement yourself
|
||||
-->
|
||||
|
||||
* 阅读 {{< 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 模式（这是一个存档版本的原始文章）。
|
||||
|
||||
@@ -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)
|
||||
架构实现的。
|
||||
|
||||
|
||||
@@ -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) 项目
|
||||
|
||||
|
||||
Reference in New Issue
Block a user