From b4189b5800176f2cfc53aa23a3a53c5d246a0024 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Mon, 3 Aug 2020 21:59:13 +0800 Subject: [PATCH] [zh] Fix links in concepts section (5) --- .../extend-kubernetes/extend-cluster.md | 2 +- .../control-plane-node-communication.md | 29 +-- .../docs/concepts/architecture/controller.md | 114 +++++---- .../docs/concepts/extend-kubernetes/_index.md | 48 ++-- .../api-extension/apiserver-aggregation.md | 80 ++++--- .../compute-storage-net/device-plugins.md | 118 +++++---- .../extend-kubernetes/extend-cluster.md | 226 +++++++++++------- .../concepts/extend-kubernetes/operator.md | 26 +- .../controllers/replicationcontroller.md | 212 ++++++++-------- 9 files changed, 485 insertions(+), 370 deletions(-) diff --git a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md index 7f5fe11807..76c72e74e4 100644 --- a/content/en/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/en/docs/concepts/extend-kubernetes/extend-cluster.md @@ -97,7 +97,7 @@ This diagram shows the extension points in a Kubernetes system. 1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. 2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](/docs/concepts/extend-kubernetes/#api-access-extensions) section. 3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](/docs/concepts/extend-kubernetes/#user-defined-types) section. Custom Resources are often used with API Access Extensions. -4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) section. +4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](/docs/concepts/extend-kubernetes/#scheduler-extensions) section. 5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources. 6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](/docs/concepts/extend-kubernetes/#network-plugins) allow for different implementations of pod networking. 7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](/docs/concepts/extend-kubernetes/#storage-plugins). diff --git a/content/zh/docs/concepts/architecture/control-plane-node-communication.md b/content/zh/docs/concepts/architecture/control-plane-node-communication.md index eafa80f804..23ae4e3919 100644 --- a/content/zh/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/zh/docs/concepts/architecture/control-plane-node-communication.md @@ -5,9 +5,6 @@ weight: 20 --- - -本文对控制面节点（确切说是 apiserver）和 Kubernetes 集群之间的通信路径进行了分类。 +本文列举控制面节点（确切说是 API 服务器）和 Kubernetes 集群之间的通信路径。 目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固，使得集群能够在不可信的网络上 （或者在一个云服务商完全公开的 IP 上）运行。 @@ -31,24 +27,22 @@ This document catalogs the communication paths between the control plane (really Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminate at the apiserver (none of the other control plane components are designed to expose remote services). The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. --> - ## 节点到控制面 Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。 所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver（其它控制面组件都没有被设计为可暴露远程服务）。 apiserver 被配置为在一个安全的 HTTPS 端口（443）上监听远程连接请求， -并启用一种或多种形式的客户端[身份认证](/docs/reference/access-authn-authz/authentication/)机制。 -一种或多种客户端[鉴权机制](/docs/reference/access-authn-authz/authorization/)应该被启用， -特别是在允许使用[匿名请求](/docs/reference/access-authn-autha/authentication/#anonymous-requests) -或[服务账号令牌](/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 +并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。 +一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用， +特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-autha/authentication/#anonymous-requests) +或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 - 应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 apiserver。 例如：在一个默认的 GCE 部署中，客户端凭据以客户端证书的形式提供给 kubelet。 -请查看 [kubelet TLS 启动引导](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +请查看 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) 以了解如何自动提供 kubelet 客户端证书。 - 想要连接到 apiserver 的 Pod 可以使用服务账号安全地进行连接。 当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。 `kubernetes` 服务（位于所有名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发 @@ -68,7 +61,6 @@ The control plane components also communicate with the cluster apiserver over th - 这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，能够在不可信的网络或公网上运行。 - ## 控制面到节点 从控制面（apiserver）到节点有两种主要的通信路径。 @@ -94,8 +85,7 @@ The connections from the apiserver to the kubelet are used for: These connections terminate at the kubelet's HTTPS endpoint. By default, the apiserver does not verify the kubelet's serving certificate, which makes the connection subject to man-in-the-middle attacks, and **unsafe** to run over untrusted and/or public networks. --> - -### apiserver 到 kubelet +### API 服务器到 kubelet 从 apiserver 到 kubelet 的连接用于： @@ -122,7 +112,8 @@ Finally, [Kubelet authentication and/or authorization](/docs/admin/kubelet-authe 如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 apiserver 和 kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。 -最后，应该启用 [Kubelet 用户认证和/或鉴权](/docs/admin/kubelet-authentication-authorization/)来保护 kubelet API。 +最后，应该启用 [Kubelet 用户认证和/或鉴权](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) +来保护 kubelet API。 - -在机器人技术和自动化中，控制回路是一个非终止回路，用于调节系统状态。 +在机器人技术和自动化领域，控制回路（Control Loop）是一个非终止回路，用于调节系统状态。 这是一个控制环的例子：房间里的温度自动调节器。 -当你设置了温度，告诉了温度自动调节器你的*期望状态*。房间的实际温度是*当前状态*。通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。 +当你设置了温度，告诉了温度自动调节器你的*期望状态（Desired State）*。 +房间的实际温度是*当前状态（Current State）*。 +通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。 {{< glossary_definition term_id="controller" length="short">}} - - - ## 控制器模式 {#controller-pattern} -一个控制器至少追踪一种类型的 Kubernetes 资源。这些[对象](/docs/concepts/overview/working-with-objects/kubernetes-objects/)有一个代表期望状态的指定字段。控制器负责确保其追踪的资源对象的当前状态接近期望状态。 +一个控制器至少追踪一种类型的 Kubernetes 资源。这些 +[对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) +有一个代表期望状态的 `spec` 字段。 +该资源的控制器负责确保其当前状态接近期望状态。 -控制器可能会自行执行操作；在 Kubernetes 中更常见的是一个控制器会发送信息给 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}，这会有副作用。看下面这个例子。 +控制器可能会自行执行操作；在 Kubernetes 中更常见的是一个控制器会发送信息给 +{{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}}，这会有副作用。 +具体可参看后文的例子。 {{< comment >}} -一些内置的控制器，比如命名空间控制器，针对没有指定命名空间的对象。为了简单起见，这篇文章没有详细介绍这些细节。 +一些内置的控制器，比如名字空间控制器，针对没有指定 `spec` 的对象。 +为了简单起见，本文没有详细介绍这些细节。 {{< /comment >}} - 创建新 Job 后，所期望的状态就是完成这个 Job。Job 控制器会让 Job 的当前状态不断接近期望状态：创建为 Job 要完成工作所需要的 Pod，使 Job 的状态接近完成。 控制器也会更新配置对象。例如：一旦 Job 的工作完成了，Job 控制器会更新 Job 对象的状态为 `Finished`。 @@ -145,7 +152,8 @@ nodes in your cluster. See 和外部状态交互的控制器从 API 服务器获取到它想要的状态，然后直接和外部系统进行通信并使当前状态更接近期望状态。 -（实际上有一个控制器可以水平地扩展集群中的节点。请看[集群自动扩缩容](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)）。 +（实际上有一个控制器可以水平地扩展集群中的节点。请参阅 +[集群自动扩缩容](/zh/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)）。 - ## 期望状态与当前状态 {#desired-vs-current} Kubernetes 采用了系统的云原生视图，并且可以处理持续的变化。 -在任务执行时，集群随时都可能被修改，并且控制环会自动的修复故障。这意味着很可能集群永远不会达到稳定状态。 +在任务执行时，集群随时都可能被修改，并且控制回路会自动修复故障。这意味着很可能集群永远不会达到稳定状态。 只要集群中控制器的在运行并且进行有效的修改，整体状态的稳定与否是无关紧要的。 @@ -181,12 +188,17 @@ It's useful to have simple controllers rather than one, monolithic set of contro loops that are interlinked. Controllers can fail, so Kubernetes is designed to allow for that. -For example: a controller for Jobs tracks Job objects (to discover -new work) and Pod object (to run the Jobs, and then to see when the work is -finished). In this case something else creates the Jobs, whereas the Job -controller creates Pods. +--> +## 设计 {#design} -{{< note >}} +作为设计原则之一，Kubernetes 使用了很多控制器，每个控制器管理集群状态的一个特定方面。 +最常见的一个特定的控制器使用一种类型的资源作为它的期望状态， +控制器管理控制另外一种类型的资源向它的期望状态演化。 + +使用简单的控制器而不是一组相互连接的单体控制回路是很有用的。 +控制器会失败，所以 Kubernetes 的设计正是考虑到了这一点。 + + - -## 设计 {#design} - -作为设计的一个原则，Kubernetes 使用了很多控制器，每个控制器管理集群状态的一个特定方面。最常见的一个特定的控制器使用一种类型的资源作为它的期望状态，控制器管理控制另外一种类型的资源向它的期望状态发展。 - -使用简单的控制器而不是一组相互连接的单体控制环是很有用的。控制器会失败，所以 Kubernetes 的设计是考虑到了这一点。 - -例如：为 Job 追踪 Job 对象（发现新工作）和 Pod 对象（运行 Job，并且等工作完成）的控制器。在本例中，其它东西创建作业，而作业控制器创建 Pod。 - {{< note >}} -可以有多个控制器来创建或者更新相同类型的对象。在这之后，Kubernetes 控制器确保他们只关心和它们控制资源相关联的资源。 +可以有多个控制器来创建或者更新相同类型的对象。 +在后台，Kubernetes 控制器确保它们只关心与其控制资源相关联的资源。 -例如，你可以有 Deployments 和 Jobs；它们都可以创建 Pod。Job 控制器不删除 Deployment 创建的 Pod，因为有信息({{< glossary_tooltip term_id="label" text="标签" >}})让控制器可以区分这些 Pod。 +例如，你可以创建 Deployment 和 Job；它们都可以创建 Pod。 +Job 控制器不会删除 Deployment 所创建的 Pod，因为有信息 +（{{< glossary_tooltip term_id="label" text="标签" >}}）让控制器可以区分这些 Pod。 {{< /note >}} +## 运行控制器的方式 {#running-controllers} +Kubernetes 内置一组控制器，运行在 {{< glossary_tooltip term_id="kube-controller-manager" >}} 内。 +这些内置的控制器提供了重要的核心功能。 + +Deployment 控制器和 Job 控制器是 Kubernetes 内置控制器的典型例子。 +Kubernetes 允许你运行一个稳定的控制平面，这样即使某些内置控制器失败了， +控制平面的其他部分会接替它们的工作。 + +你会遇到某些控制器运行在控制面之外，用以扩展 Kubernetes。 +或者，如果你愿意，你也可以自己编写新控制器。 +你可以以一组 Pod 来运行你的控制器，或者运行在 Kubernetes 之外。 +最合适的方案取决于控制器所要执行的功能是什么。 + +## {{% heading "whatsnext" %}} + - -## 运行控制器的方式 {#running-controllers} - -Kubernetes 自带有一组内置的控制器，运行在 {{< glossary_tooltip term_id="kube-controller-manager" >}} 内。这些内置的控制器提供了重要的核心功能。 - -Deployment 控制器和 Job 控制器是 Kubernetes 内置控制器的典型例子。Kubernetes 运行一个弹性的控制平面，所以如果任意内置控制器失败了，控制平面的另外一部分会接替它的工作。 - -你会发现控制平面外面运行的控制器，扩展了 Kubernetes 的能力。或者，如果你愿意，你也可以写一个新控制器。你可以以一组 Pod 来运行你的控制器，或者运行在 Kubernetes 外面。什么是最合适的控制器，这将取决于特定控制器的功能。 - - - -## {{% heading "whatsnext" %}} - -* 请阅读 [Kubernetes 控制平面](/docs/concepts/#kubernetes-control-plane) -* 了解一些基本的 [Kubernetes 对象](/docs/concepts/#kubernetes-objects) -* 学习更多的 [Kubernetes API](/docs/concepts/overview/kubernetes-api/) -* 如果你想写自己的控制器，请看 Kubernetes 的[扩展模式](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。 +* 阅读 [Kubernetes 控制面](/zh/docs/concepts/#kubernetes-control-plane) +* 了解 [Kubernetes 对象](/zh/docs/concepts/#kubernetes-objects) 的一些基本知识 +* 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) +* 如果你想编写自己的控制器，请看 Kubernetes 的[扩展模式](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns)。 diff --git a/content/zh/docs/concepts/extend-kubernetes/_index.md b/content/zh/docs/concepts/extend-kubernetes/_index.md index 3d091a51cd..e79067baad 100644 --- a/content/zh/docs/concepts/extend-kubernetes/_index.md +++ b/content/zh/docs/concepts/extend-kubernetes/_index.md @@ -61,20 +61,20 @@ Customization approaches can be broadly divided into *configuration*, which only *Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary: -* [kubelet](/docs/admin/kubelet/) -* [kube-apiserver](/docs/admin/kube-apiserver/) -* [kube-controller-manager](/docs/admin/kube-controller-manager/) -* [kube-scheduler](/docs/admin/kube-scheduler/). +* [kubelet](/docs/reference/command-line-tools-reference/kubelet/) +* [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). --> ## Configuration *配置文件*和*参数标志*的说明位于在线文档的参考章节，按可执行文件组织： -* [kubelet](/docs/admin/kubelet/) -* [kube-apiserver](/docs/admin/kube-apiserver/) -* [kube-controller-manager](/docs/admin/kube-controller-manager/) -* [kube-scheduler](/docs/admin/kube-scheduler/). +* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) +* [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/). ## API 扩展 {#api-extensions} @@ -259,7 +259,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/ 不要使用自定义资源来充当应用、用户或者监控数据的数据存储。 -关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/api-extension/custom-resources/)。 +关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 ### 鉴权 {#authorization} -[鉴权](/docs/reference/access-authn-authz/webhook/)操作负责确定特定的用户 +[鉴权](/zh/docs/reference/access-authn-authz/webhook/)操作负责确定特定的用户 是否可以读、写 API 资源或对其执行其他操作。 此操作仅在整个资源集合的层面进行。 换言之，它不会基于对象的特定字段作出不同的判决。 @@ -392,12 +392,12 @@ Different networking fabrics can be supported via node-level [Network Plugins](/ --> ### 设备插件 {#device-plugins} -使用[设备插件](/zh/docs/concepts/cluster-administration/device-plugins/)， +使用[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)， 节点能够发现新的节点资源（除了内置的类似 CPU 和内存这类资源）。 ### 网络插件 {#network-plugins} -通过节点层面的[网络插件](/docs/admin/network-plugins/)，可以支持 +通过节点层面的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)，可以支持 不同的网络设施。 -* 进一步了解[自定义资源](/zh/docs/concepts/api-extension/custom-resources/) +* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) * 进一步了解基础设施扩展 - * [网络插件](/zh/docs/concepts/cluster-administration/network-plugins/) - * [设备插件](/zh/docs/concepts/cluster-administration/device-plugins/) + * [网络插件](/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/) diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index acac52ab5f..d91546feb6 100644 --- a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -1,7 +1,7 @@ --- title: 通过聚合层扩展 Kubernetes API content_type: concept -weight: 10 +weight: 20 --- @@ -20,57 +20,77 @@ weight: 10 -聚合层允许 Kubernetes 通过额外的 API 进行扩展，而不局限于 Kubernetes 核心 API 提供的功能。 +使用聚合层（Aggregation Layer），用户可以通过额外的 API 扩展 Kubernetes， +而不局限于 Kubernetes 核心 API 提供的功能。 + +这里的附加 API 可以是[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/) +这类已经成熟的解决方案，也可以是你自己开发的 API。 + +聚合层不同于 +[自定义资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 +后者的目的是让 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} +能够认识新的对象类别（Kind）。 -## 概述 - -聚合层使您的集群可以安装其他 Kubernetes 风格的 API。这些 API 可以是预编译的、第三方的解决方案提供的例如[service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md)、或者用户创建的类似[apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md)一样的API可以帮助你上手。 - - -聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。要注册 API，用户必须添加一个 APIService 对象，用它来申领 Kubernetes API 中的 URL 路径。自此以后，聚合层将会把发给该 API 路径的所有内容（例如 /apis/myextension.mycompany.io/v1/…）代理到已注册的 APIService。 +## 聚合层 {#aggregation-layer} + +聚合层在 kube-apiserver 进程内运行。在扩展资源注册之前，聚合层不做任何事情。 +要注册 API，用户必须添加一个 APIService 对象，用它来“申领” Kubernetes API 中的 URL 路径。 +自此以后，聚合层将会把发给该 API 路径的所有内容（例如 `/apis/myextension.mycompany.io/v1/…`） +转发到已注册的 APIService。 -正常情况下，APIService 会实现为运行于集群中某 Pod 内的 extension-apiserver。如果需要对增加的资源进行动态管理，extension-apiserver 经常需要和一个或多个控制器一起使用。因此，apiserver-builder 同时提供用来管理新资源的 API 框架和控制器框架。另外一个例子，当安装了 service-catalog 时，它会为自己提供的服务提供 extension-apiserver 和控制器。 +APIService 的最常见实现方式是在集群中某 Pod 内运行 *扩展 API 服务器*。 +如果你在使用扩展 API 服务器来管理集群中的资源，该扩展 API 服务器（也被写成“extension-apiserver”） +一般需要和一个或多个{{< glossary_tooltip text="控制器" term_id="controller" >}}一起使用。 +apiserver-builder 库同时提供构造扩展 API 服务器和控制器框架代码。 + +### 反应延迟 {#response-latency} -extension-apiserver 与 kube-apiserver 之间的连接应具有低延迟。 -特别是，发现请求需要在五秒钟或更短的时间内从 kube-apiserver 往返。 -如果您的部署无法实现此目的，则应考虑如何进行更改。目前，在 kube-apiserver 上设置 `EnableAggregatedDiscoveryTimeout=false` 功能开关将禁用超时限制。它将在将来的版本中被删除。 - +扩展 API 服务器与 kube-apiserver 之间需要存在低延迟的网络连接。 +发现请求需要在五秒钟或更短的时间内完成到 kube-apiserver 的往返。 +如果你的扩展 API 服务器无法满足这一延迟要求，应考虑如何更改配置已满足需要。 +你也可以为 kube-apiserver 设置 `EnableAggregatedDiscoveryTimeout=false` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +来禁用超时限制。此特性门控已经废弃，将在未来版本中被删除。 ## {{% heading "whatsnext" %}} - -* 阅读[配置聚合层](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/) 文档，了解如何在自己的环境中启用聚合器（aggregator）。 -* 然后[安装扩展的 api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) 来开始使用聚合层。 -* 也可以学习怎样 [使用自定义资源定义扩展 Kubernetes API](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/)。 - - - +* 阅读[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档， + 了解如何在自己的环境中启用聚合器。 +* 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)， + 开始使用聚合层。 +* 也可以学习怎样[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 +* 阅读 [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io) 的规范 diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index e7d020a8b2..964c5dc392 100644 --- a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -19,11 +19,9 @@ The targeted devices include GPUs, high-performance NICs, FPGAs, InfiniBand adap and other similar computing resources that may require vendor specific initialization and setup. --> -Kubernetes 提供了一个[设备插件框架](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)，您可以用来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。 - -供应商可以实现设备插件，由您手动部署或作为 {{< glossary_tooltip term_id="daemonset" >}} 来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、InfiniBand 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。 - +Kubernetes 提供了一个[设备插件框架](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)，你可以用来将系统硬件资源发布到 {{< glossary_tooltip term_id="kubelet" >}}。 +供应商可以实现设备插件，由你手动部署或作为 {{< glossary_tooltip term_id="daemonset" >}} 来部署，而不必定制 Kubernetes 本身的代码。目标设备包括 GPU、高性能 NIC、FPGA、InfiniBand 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。 @@ -32,7 +30,7 @@ Kubernetes 提供了一个[设备插件框架](https://github.com/kubernetes/com -kubelet 输出了一个 `Registration` 的 gRPC 服务： +`kubelet` 提供了一个 `Registration` 的 gRPC 服务： ```gRPC service Registration { @@ -47,7 +45,7 @@ During the registration, the device plugin needs to send: * The name of its Unix socket. * The Device Plugin API version against which it was built. * The `ResourceName` it wants to advertise. Here `ResourceName` needs to follow the - [extended resource naming scheme](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources) + [extended resource naming scheme](/docs/concepts/configuration/manage-resources-container/#extended-resources) as `vendor-domain/resourcetype`. (For example, an NVIDIA GPU is advertised as `nvidia.com/gpu`.) @@ -60,9 +58,11 @@ to advertise that the node has 2 “Foo” devices installed and available. --> 设备插件可以通过此 gRPC 服务在 kubelet 进行注册。在注册期间，设备插件需要发送下面几样内容： - * 设备插件的 Unix 套接字。 - * 设备插件的 API 版本。 - * `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循[扩展资源命名方案](/docs/concepts/configuration/manage-compute-resources-container/#extended-resources)，类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。） +* 设备插件的 Unix 套接字。 +* 设备插件的 API 版本。 +* `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循 + [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-container/#extended-resources)， + 类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。） 成功注册后，设备插件就向 kubelet 发送他所管理的设备列表，然后 kubelet 负责将这些资源发布到 API 服务器，作为 kubelet 节点状态更新的一部分。 @@ -76,16 +76,17 @@ specification as they request other types of resources, with the following limit * Extended resources are only supported as integer resources and cannot be overcommitted. * Devices cannot be shared among Containers. --> -然后用户需要去请求其他类型的资源的时候，就可以在[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)规范请求这类设备，但是有以下的限制： +然后用户需要请求其他类型的资源的时候，就可以在 +[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) +规范请求这类设备，但是有以下的限制： - * 扩展资源仅可作为整数资源使用，并且不能被过量使用 - * 设备不能在容器之间共享 +* 扩展资源仅可作为整数资源使用，并且不能被过量使用 +* 设备不能在容器之间共享 - 假设 Kubernetes 集群正在运行一个设备插件，该插件在一些节点上公布的资源为 `hardware-vendor.example/foo`。 下面就是一个 Pod 示例，请求此资源以运行某演示负载： @@ -125,8 +126,8 @@ The general workflow of a device plugin includes the following steps: 设备插件的常规工作流程包括以下几个步骤： - * 初始化。在这个阶段，设备插件将执行供应商特定的初始化和设置，以确保设备处于就绪状态。 - * 插件使用主机路径 `/var/lib/kubelet/device-plugins/` 下的 Unix socket 启动一个 gRPC 服务，该服务实现以下接口： +* 初始化。在这个阶段，设备插件将执行供应商特定的初始化和设置，以确保设备处于就绪状态。 +* 插件使用主机路径 `/var/lib/kubelet/device-plugins/` 下的 Unix socket 启动一个 gRPC 服务，该服务实现以下接口： ```gRPC service DevicePlugin { @@ -154,9 +155,12 @@ If the operations succeed, the device plugin returns an `AllocateResponse` that runtime configurations for accessing the allocated devices. The kubelet passes this information to the container runtime. --> - - * 插件通过 Unix socket 在主机路径 `/var/lib/kubelet/device-plugins/kubelet.sock` 处向 kubelet 注册自身。 - * 成功注册自身后，设备插件将以服务模式运行，在此期间，它将持续监控设备运行状况，并在设备状态发生任何变化时向 kubelet 报告。它还负责响应 `Allocate` gRPC 请求。在`Allocate`期间，设备插件可能还会做一些设备特定的准备；例如 GPU 清理或 QRNG 初始化。如果操作成功，则设备插件将返回 `AllocateResponse`，其中包含用于访问被分配的设备容器运行时的配置。kubelet 将此信息传递到容器运行时。 +* 插件通过 Unix socket 在主机路径 `/var/lib/kubelet/device-plugins/kubelet.sock` 处向 kubelet 注册自身。 +* 成功注册自身后，设备插件将以服务模式运行，在此期间，它将持续监控设备运行状况， + 并在设备状态发生任何变化时向 kubelet 报告。它还负责响应 `Allocate` gRPC 请求。 + 在 `Allocate` 期间，设备插件可能还会做一些设备特定的准备；例如 GPU 清理或 QRNG 初始化。 + 如果操作成功，则设备插件将返回 `AllocateResponse`，其中包含用于访问被分配的设备容器运行时的配置。 + kubelet 将此信息传递到容器运行时。 ### 处理 kubelet 重启 -设备插件应能监测到 kubelet 重启，并且向新的 kubelet 实例来重新注册自己。在当前实现中，当 kubelet 重启的时候，新的 kubelet 实例会删除 `/var/lib/kubelet/device-plugins` 下所有已经存在的 Unix sockets。设备插件需要能够监控到它的 Unix socket 被删除，并且当发生此类事件时重新注册自己。 +设备插件应能监测到 kubelet 重启，并且向新的 kubelet 实例来重新注册自己。 +在当前实现中，当 kubelet 重启的时候，新的 kubelet 实例会删除 `/var/lib/kubelet/device-plugins` +下所有已经存在的 Unix sockets。 +设备插件需要能够监控到它的 Unix socket 被删除，并且当发生此类事件时重新注册自己。 ## API 兼容性 -Kubernetes 设备插件支持还处于 beta 版本。所以在稳定版本出来之前 API 会以不兼容的方式进行更改。作为一个项目，Kubernetes 建议设备插件开发者： +Kubernetes 设备插件支持还处于 beta 版本。所以在稳定版本出来之前 API 会以不兼容的方式进行更改。 +作为一个项目，Kubernetes 建议设备插件开发者： * 注意未来版本的更改 * 支持多个版本的设备插件 API，以实现向后/向前兼容性。 -如果你启用 DevicePlugins 功能，并在需要升级到 Kubernetes 版本来获得较新的设备插件 API 版本的节点上运行设备插件，请在升级这些节点之前先升级设备插件以支持这两个版本。采用该方法将确保升级期间设备分配的连续运行。 +如果你启用 DevicePlugins 功能，并在需要升级到 Kubernetes 版本来获得较新的设备插件 API +版本的节点上运行设备插件，请在升级这些节点之前先升级设备插件以支持这两个版本。 +采用该方法将确保升级期间设备分配的连续运行。 -gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接字来提供服务。设备插件资源的监控代理程序可以部署为守护进程或者 DaemonSet。规范的路径 `/var/lib/kubelet/pod-resources` 需要特权来进入，所以监控代理程序必须要在获得授权的安全的上下文中运行。如果设备监控代理以 DaemonSet 形式运行，必须要在插件的 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中声明将 `/var/lib/kubelet/pod-resources` 目录以 {{< glossary_tooltip term_id="volume" >}} 形式被 mount 到容器中。 +gRPC 服务通过 `/var/lib/kubelet/pod-resources/kubelet.sock` 的 UNIX 套接字来提供服务。 +设备插件资源的监控代理程序可以部署为守护进程或者 DaemonSet。 +规范的路径 `/var/lib/kubelet/pod-resources` 需要特权来进入， +所以监控代理程序必须要在获得授权的安全的上下文中运行。 +如果设备监控代理以 DaemonSet 形式运行，必须要在插件的 +[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) +中声明将 `/var/lib/kubelet/pod-resources` 目录以 +{{< glossary_tooltip text="卷" term_id="volume" >}}的形式被挂载到容器中。 -对“PodResources 服务”的支持要求启用 `KubeletPodResources` [特性门控](/docs/reference/command-line-tools-reference/feature-gates/)。从 Kubernetes 1.15 开始默认启用。 +对“PodResources 服务”的支持要求启用 `KubeletPodResources` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +从 Kubernetes 1.15 开始默认启用。 -设备插件希望拓扑管理器可以将填充的 TopologyInfo 结构体作为设备注册的一部分以及设备 ID 和设备的运行状况发送回去。然后设备管理器将使用此信息来咨询拓扑管理器并做出资源分配决策。 +设备插件希望拓扑管理器可以将填充的 TopologyInfo 结构体作为设备注册的一部分以及设备 ID +和设备的运行状况发送回去。然后设备管理器将使用此信息来咨询拓扑管理器并做出资源分配决策。 -`TopologyInfo` 支持定义 `nodes` 字段，允许为 `nil`（默认）或者是一个 NUMA nodes 的列表。这样就可以使设备插件可以跨越 NUMA nodes 去发布。 +`TopologyInfo` 支持定义 `nodes` 字段，允许为 `nil`（默认）或者是一个 NUMA 节点的列表。 +这样就可以使设备插件可以跨越 NUMA 节点去发布。 下面是一个由设备插件为设备填充 `TopologyInfo` 结构体的示例： @@ -328,30 +358,28 @@ Here are some examples of device plugin implementations: 下面是一些设备插件实现的示例： -* [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin) -* [Intel device plugins](https://github.com/intel/intel-device-plugins-for-kubernetes) 支持 Intel GPU、FPGA 和 QuickAssist 设备 -* [KubeVirt device plugins](https://github.com/kubevirt/kubernetes-device-plugins) 用于硬件辅助的虚拟化 -* The [NVIDIA GPU device plugin](https://github.com/NVIDIA/k8s-device-plugin) - * 需要 [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) 2.0，允许运行 Docker 容器的时候开启 GPU。 -* [NVIDIA GPU device plugin for Container-Optimized OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu) -* [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin) -* [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin) -* [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin) -* [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) - +* [AMD GPU 设备插件](https://github.com/RadeonOpenCompute/k8s-device-plugin) +* [Intel 设备插件](https://github.com/intel/intel-device-plugins-for-kubernetes) 支持 Intel GPU、FPGA 和 QuickAssist 设备 +* [KubeVirt 设备插件](https://github.com/kubevirt/kubernetes-device-plugins) 用于硬件辅助的虚拟化 +* The [NVIDIA GPU 设备插件](https://github.com/NVIDIA/k8s-device-plugin) + * 需要 [nvidia-docker](https://github.com/NVIDIA/nvidia-docker) 2.0，以允许运行 Docker 容器的时候启用 GPU。 +* [为 Container-Optimized OS 所提供的 NVIDIA GPU 设备插件](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu) +* [RDMA 设备插件](https://github.com/hustcat/k8s-rdma-device-plugin) +* [Solarflare 设备插件](https://github.com/vikaschoudhary16/sfc-device-plugin) +* [SR-IOV 网络设备插件](https://github.com/intel/sriov-network-device-plugin) +* [Xilinx FPGA 设备插件](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) ## {{% heading "whatsnext" %}} - -* 查看 [调度 GPU 资源](/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 -* 查看在 node 上如何[广告扩展资源](/docs/tasks/administer-cluster/extended-resource-node/) -* 阅读如何在 Kubernetes 中如何使用 [TLS 入口的硬件加速](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) -* 学习 [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/) +* 查看[调度 GPU 资源](/zh/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 +* 查看在上如何[公布节点上的扩展资源](/docs/tasks/administer-cluster/extended-resource-node/) +* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) +* 学习[拓扑管理器](/zh/docs/tasks/adminster-cluster/topology-manager/) diff --git a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md index 58e6154f6a..4c2c7cbc53 100644 --- a/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md +++ b/content/zh/docs/concepts/extend-kubernetes/extend-cluster.md @@ -23,19 +23,23 @@ Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or submit patches to the Kubernetes project code. -This guide describes the options for customizing a Kubernetes -cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to -understand how to adapt their Kubernetes cluster to the needs of -their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it -useful as an introduction to what extension points and patterns -exist, and their trade-offs and limitations. +This guide describes the options for customizing a Kubernetes cluster. It is +aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} +who want to understand how to adapt their +Kubernetes cluster to the needs of their work environment. Developers who are prospective +{{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} +or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} +will also find it useful as an introduction to what extension points and +patterns exist, and their trade-offs and limitations. --> Kubernetes 是高度可配置和可扩展的。因此，极少需要分发或提交补丁代码给 Kubernetes 项目。 -本文档介绍自定义 Kubernetes 集群的选项。本文档的目标读者 {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} 是希望了解如何使 Kubernetes 集群满足其业务环境需求的集群运维人员。Kubernetes 项目的贡献者 {{< glossary_tooltip text="Contributors" term_id="contributor" >}} 或潜在的平台开发人员 {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} 也可以从本文找到有用的信息，如对已存在扩展点和模式的介绍，以及它们的权衡和限制。 - - - +本文档介绍自定义 Kubernetes 集群的选项。本文档的目标读者包括希望了解如何使 +Kubernetes 集群满足其业务环境需求的 +{{< glossary_tooltip text="集群运维人员" term_id="cluster-operator" >}}、 +Kubernetes 项目的{{< glossary_tooltip text="贡献者" term_id="contributor" >}}。 +或潜在的{{< glossary_tooltip text="平台开发人员" term_id="platform-developer" >}} +也可以从本文找到有用的信息，如对已存在扩展点和模式的介绍，以及它们的权衡和限制。 @@ -46,27 +50,28 @@ Customization approaches can be broadly divided into *configuration*, which only --> ## 概述 -定制方法可以大致分为 *配置* 和 *扩展* 。*配置* 只涉及更改标志参数、本地配置文件或 API 资源；*扩展* 涉及运行额外的程序或服务。本文档主要内容是关于扩展。 +定制方法可以大致分为 *配置（Configuration）* 和 *扩展（Extension）* 。 +*配置* 只涉及更改标志参数、本地配置文件或 API 资源； +*扩展* 涉及运行额外的程序或服务。本文档主要内容是关于扩展。 -## 配置 - -关于 *配置文件* 和 *标志* 的说明文档位于在线文档的参考部分，按照二进制组件各自描述： +## 配置 {#configuration} -* [kubelet](/docs/admin/kubelet/) -* [kube-apiserver](/docs/admin/kube-apiserver/) -* [kube-controller-manager](/docs/admin/kube-controller-manager/) -* [kube-scheduler](/docs/admin/kube-scheduler/). +关于 *配置文件* 和 *标志* 的说明文档位于在线文档的"参考"部分，按照可执行文件组织： + +* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) +* [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/). -*内置策略 API* ，例如 [ResourceQuota](/docs/concepts/policy/resource-quotas/)、[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)、[NetworkPolicy](/docs/concepts/services-networking/network-policies/) 和基于角色的权限控制 ([RBAC](/docs/reference/access-authn-authz/rbac/))，是内置的 Kubernetes API。API 通常与托管的 Kubernetes 服务和受控的 Kubernetes 安装一起使用。 -它们是声明性的，并使用与其他 Kubernetes 资源（如 Pod ）相同的约定，所以新的集群配置可以重复使用，并以与应用程序相同的方式进行管理。而且，当他们变稳定后，他们和其他 Kubernetes API 一样享受[定义支持政策](/docs/reference/deprecation-policy/)。出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。 +*内置策略 API* ，例如 [ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)、 +[PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/)、 +[NetworkPolicy](/zh/docs/concepts/services-networking/network-policies/) +和基于角色的权限控制 ([RBAC](/zh/docs/reference/access-authn-authz/rbac/))， +是内置的 Kubernetes API。API 通常与托管的 Kubernetes 服务和受控的 Kubernetes 安装一起使用。 +它们是声明性的，并使用与其他 Kubernetes 资源（如 Pod ）相同的约定，所以新的集群配置可以重复使用， +并以与应用程序相同的方式进行管理。 +而且，当它们变稳定后，也遵循和其他 Kubernetes API 一样的 +[支持政策](/zh/docs/reference/using-api/deprecation-policy/)。 +出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。 -## 扩展程序 +## 扩展程序 {#extension} 扩展程序是指对 Kubernetes 进行扩展和深度集成的软件组件。它们适合用于支持新的类型和新型硬件。 -大多数集群管理员会使用托管的或统一分发的 Kubernetes 实例。因此，大多数 Kubernetes 用户需要安装扩展程序，而且还有少部分用户甚至需要编写新的扩展程序。 +大多数集群管理员会使用托管的或统一分发的 Kubernetes 实例。 +因此，大多数 Kubernetes 用户需要安装扩展程序，而且还有少部分用户甚至需要编写新的扩展程序。 -## 扩展模式 +## 扩展模式 {#extension-patterns} -Kubernetes 的设计是通过编写客户端程序来实现自动化的。任何读和（或）写 Kubernetes API 的程序都可以提供有用的自动化工作。*自动化* 程序可以运行在集群之中或之外。按照本文档的指导，您可以编写出高可用的和健壮的自动化程序。自动化程序通常适用于任何 Kubernetes 集群，包括托管集群和受管理安装的集群。 +Kubernetes 的设计是通过编写客户端程序来实现自动化的。 +任何读和（或）写 Kubernetes API 的程序都可以提供有用的自动化工作。 +*自动化* 程序可以运行在集群之中或之外。按照本文档的指导，你可以编写出高可用的和健壮的自动化程序。 +自动化程序通常适用于任何 Kubernetes 集群，包括托管集群和受管理安装的集群。 -*控制器* 模式是编写适合 Kubernetes 的客户端程序的一种特定模式。控制器通常读取一个对象的 `.spec` 字段，可能做出一些处理，然后更新对象的 `.status` 字段。 +*控制器（Controller）* 模式是编写适合 Kubernetes 的客户端程序的一种特定模式。 +控制器通常读取一个对象的 `.spec` 字段，可能做出一些处理，然后更新对象的 `.status` 字段。 -一个控制器是 Kubernetes 的一个客户端。而当 Kubernetes 作为客户端调用远程服务时，它被称为 *Webhook* ，远程服务称为 *Webhook* 后端。 和控制器类似，Webhooks 增加了一个失败点。 +一个控制器是 Kubernetes 的一个客户端。 +当 Kubernetes 作为客户端调用远程服务时，它被称为 *Webhook* ， +远程服务称为 *Webhook* 后端。 和控制器类似，Webhooks 增加了一个失败点。 -在 webhook 模型里，Kubernetes 向远程服务发送一个网络请求。在 *二进制插件* 模型里，Kubernetes 执行一个二进制（程序）。二进制插件被 kubelet（如 [Flex 卷插件](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)和[网络插件](/docs/concepts/cluster-administration/network-plugins/))和 kubectl 所使用。 +在 webhook 模型里，Kubernetes 向远程服务发送一个网络请求。 +在 *可执行文件插件* 模型里，Kubernetes 执行一个可执行文件（程序）。 +可执行文件插件被 kubelet（如 +[Flex 卷插件](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md)和 +[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)和 +`kubectl` 所使用。 -## 扩展点 +## 扩展点 {#extension-points} 下图显示了 Kubernetes 系统的扩展点。 @@ -162,27 +187,38 @@ This diagram shows the extension points in a Kubernetes system. -1. 用户通常使用 `kubectl` 与 Kubernetes API 进行交互。[kubectl 插件](/docs/tasks/extend-kubectl/kubectl-plugins/)扩展了 kubectl 二进制程序。它们只影响个人用户的本地环境，因此不能执行站点范围的策略。 -2. apiserver 处理所有请求。apiserver 中的几种类型的扩展点允许对请求进行身份认证或根据其内容对其进行阻止、编辑内容以及处理删除操作。这些内容在[API 访问扩展](/docs/concepts/overview/extending#api-access-extensions)小节中描述。 -3. apiserver 提供各种 *资源* 。 *内置的资源种类* ，如 `pods`，由 Kubernetes 项目定义，不能更改。您还可以添加您自己定义的资源或其他项目已定义的资源，称为 自定义资源，如[自定义资源](/docs/concepts/overview/extending#user-defined-types)部分所述。自定义资源通常与 API 访问扩展一起使用。 -4. Kubernetes 调度器决定将 Pod 放置到哪个节点。有几种方法可以扩展调度器。这些内容在 [Scheduler Extensions](/docs/concepts/overview/extending#scheduler-extensions) 小节中描述。 -5. Kubernetes 的大部分行为都是由称为控制器的程序实现的，这些程序是 API-Server 的客户端。控制器通常与自定义资源一起使用。 -6. kubelet 在主机上运行，并帮助 pod 看起来就像在集群网络上拥有自己的 IP 的虚拟服务器。[网络插件](/docs/concepts/overview/extending#network-plugins)让您可以实现不同的 pod 网络。 -7. kubelet 也挂载和卸载容器的卷。新的存储类型可以通过[存储插件](/docs/concepts/overview/extending#storage-plugins)支持。 +1. 用户通常使用 `kubectl` 与 Kubernetes API 进行交互。 + [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)扩展了 kubectl 可执行文件。 + 它们只影响个人用户的本地环境，因此不能执行站点范围的策略。 +2. API 服务器处理所有请求。API 服务器中的几种类型的扩展点允许对请求进行身份认证或根据其内容对其进行阻止、 + 编辑内容以及处理删除操作。这些内容在 + [API 访问扩展](/zh/docs/concepts/extend-kubernetes/#api-access-extensions)小节中描述。 +3. API 服务器提供各种 *资源（Resource）* 。 *内置的资源种类（Resource Kinds）* ，如 `pods`， + 由 Kubernetes 项目定义，不能更改。你还可以添加你自己定义的资源或其他项目已定义的资源， + 称为 *自定义资源（Custom Resource）*，如[自定义资源](/zh/docs/concepts/extend-kubernetes/#user-defined-types) + 部分所述。自定义资源通常与 API 访问扩展一起使用。 +4. Kubernetes 调度器决定将 Pod 放置到哪个节点。有几种方法可以扩展调度器。 + 这些内容在[调度器扩展](/zh/docs/concepts/extend-kubernetes/#scheduler-extensions) + 小节中描述。 +5. Kubernetes 的大部分行为都是由称为控制器（Controllers）的程序实现的，这些程序是 API 服务器的客户端。 + 控制器通常与自定义资源一起使用。 +6. `kubelet` 在主机上运行，并帮助 Pod 看起来就像在集群网络上拥有自己的 IP 的虚拟服务器。 + [网络插件](/zh/docs/concepts/extend-kubernetes/#network-plugins/)让你可以实现不同的 pod 网络。 +7. `kubelet` 也负责为容器挂载和卸载卷。新的存储类型可以通过 + [存储插件](/zh/docs/concepts/extend-kubernetes/#storage-plugins/)支持。 - -如果您不确定从哪里开始扩展，此流程图可以提供帮助。请注意，某些解决方案可能涉及多种类型的扩展。 +如果你不确定从哪里开始扩展，下面流程图可以提供一些帮助。请注意，某些解决方案可能涉及多种类型的扩展。 @@ -198,14 +234,16 @@ Do not use a Custom Resource as data storage for application, user, or monitorin For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/). --> -## API 扩展 -### 用户自定义类型 +## API 扩展 {#api-extensions} -如果您想定义新的控制器、应用程序配置对象或其他声明式 API，并使用 Kubernetes 工具（如 `kubectl`）管理它们，请考虑为 Kubernetes 添加一个自定义资源。 +### 用户自定义类型 {#user-defined-types} + +如果你想定义新的控制器、应用程序配置对象或其他声明式 API，并使用 Kubernetes 工具（如 `kubectl`）管理它们，请考虑为 Kubernetes 添加一个自定义资源。 不要使用自定义资源作为应用、用户或者监控数据的数据存储。 -有关自定义资源的更多信息，请查看[自定义资源概念指南](/docs/concepts/api-extension/custom-resources/)。 +有关自定义资源的更多信息，请查看 +[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 ### 将新的 API 与自动化相结合 -自定义资源 API 和控制循环的组合称为 [操作者模式](/docs/concepts/extend-kubernetes/operator/)。操作者模式用于管理特定的，通常是有状态的应用程序。这些自定义 API 和控制循环还可用于控制其他资源，例如存储或策略。 +自定义资源 API 和控制循环的组合称为 +[操作者（Operator）模式](/zh/docs/concepts/extend-kubernetes/operator/)。 +操作者模式用于管理特定的，通常是有状态的应用程序。 +这些自定义 API 和控制循环还可用于控制其他资源，例如存储或策略。 ### 改变内置资源 -当您通过添加自定义资源来扩展 Kubernetes API 时，添加的资源始终属于新的 API 组。您不能替换或更改已有的 API 组。添加 API 不会直接影响现有 API（例如 Pod ）的行为，但是 API 访问扩展可以。 +当你通过添加自定义资源来扩展 Kubernetes API 时，添加的资源始终属于新的 API 组。 +你不能替换或更改已有的 API 组。 +添加 API 不会直接影响现有 API（例如 Pod ）的行为，但是 API 访问扩展可以。 -### API 访问扩展 +### API 访问扩展 {#api-access-extensions} -当请求到达 Kubernetes API Server 时，它首先被要求进行用户认证，然后要进行授权检查，接着受到各种类型的准入控制的检查。有关此流程的更多信息，请参阅 [Kubernetes API访问控制](/docs/reference/access-authn-authz/controlling-access/)。 +当请求到达 Kubernetes API Server 时，它首先被要求进行用户认证，然后要进行授权检查， +接着受到各种类型的准入控制的检查。有关此流程的更多信息，请参阅 +[Kubernetes API 访问控制](/zh/docs/reference/access-authn-authz/controlling-access/)。 上述每个步骤都提供了扩展点。 -Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后，并将授权 header 中的令牌发送给远程服务进行验证（webhook）。所有这些方法都在[身份验证文档](/docs/reference/access-authn-authz/authentication/)中介绍。 +Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验证代理之后，并将 Authorziation 头部 +中的令牌发送给远程服务（webhook）进行验证。所有这些方法都在 +[身份验证文档](/zh/docs/reference/access-authn-authz/authentication/)中介绍。 -### 身份认证 +### 身份认证 {#authentication} -[身份认证](/docs/reference/access-authn-authz/authentication/)将所有请求中的 header 或证书映射为发出请求的客户端的用户名。 +[身份认证](/zh/docs/reference/access-authn-authz/authentication/) +将所有请求中的头部字段或证书映射为发出请求的客户端的用户名。 -Kubernetes 提供了几种内置的身份认证方法，如果这些方法不符合您的需求，可以使用[身份认证 webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。 +Kubernetes 提供了几种内置的身份认证方法，如果这些方法不符合你的需求，可以使用 +[身份认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法。 -### 授权 +### 鉴权 {#authorization} -[授权](/docs/reference/access-authn-authz/webhook/)决定特定用户是否可以对 API 资源执行读取、写入以及其他操作。它只是在整个资源的层面上工作 -- 它不基于任意的对象字段进行区分。如果内置授权选项不能满足您的需求，[授权 webhook](/docs/reference/access-authn-authz/webhook/) 允许调用用户提供的代码来作出授权决定。 +[鉴权组件](/zh/docs/reference/access-authn-authz/authorization/)决定特定用户是否可以对 +API 资源执行读取、写入以及其他操作。它只是在整个资源的层面上工作 -- +它不基于任意的对象字段进行区分。如果内置授权选项不能满足你的需求， +[鉴权 Webhook](/zh/docs/reference/access-authn-authz/webhook/) +允许调用用户提供的代码来作出授权决定。 ### 动态准入控制 -在请求被授权之后，如果是写入操作，它还将进入[准入控制](/docs/reference/access-authn-authz/admission-controllers/)步骤。除了内置的步骤之外，还有几个扩展： +在请求被授权之后，如果是写入操作，它还将进入 +[准入控制](/zh/docs/reference/access-authn-authz/admission-controllers/) +步骤。除了内置的步骤之外，还有几个扩展： -* [镜像策略 webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) 限制了哪些镜像可以在容器中运行。 -* 为了进行灵活的准入控制决策，可以使用通用的 [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。Admission Webhooks 可以拒绝创建或更新操作。 +* [镜像策略 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) + 限制哪些镜像可以在容器中运行。 +* 为了进行灵活的准入控制决策，可以使用通用的 + [准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 + 准入 Webhooks 可以拒绝创建或更新操作。 ## 基础设施扩展 - ### 存储插件 [Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md -) 允许用户挂载无内置插件支持的卷类型，它通过 Kubelet 调用一个二进制插件来挂载卷。 +) +允许用户挂载无内置插件支持的卷类型，它通过 Kubelet 调用一个可执行文件插件来挂载卷。 -### 设备插件 +### 设备插件 {#device-plugins} -设备插件允许节点通过[设备插件](/docs/concepts/cluster-administration/device-plugins/)发现新的节点资源（除了内置的 CPU 和内存之外）。 +设备插件允许节点通过 +[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). +发现新的节点资源（除了内置的 CPU 和内存之外）。 -### 网络插件 +### 网络插件 {#network-plugins} -不同的网络结构可以通过节点级的[网络插件](/docs/admin/network-plugins/)支持。 +不同的网络结构可以通过节点级的 +[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +得到支持。 -### 调度器扩展 - -调度器是一种特殊类型的控制器，用于监视 pod 并将其分配到节点。默认的调度器可以完全被替换，而继续使用其他 Kubernetes 组件，或者可以同时运行[多个调度器](/docs/tasks/administer-cluster/configure-multiple-schedulers/)。 - -这是一个重要的任务，几乎所有的 Kubernetes 用户都发现他们不需要修改调度器。 - -调度器也支持 [webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)，它允许一个 webhook 后端（调度器扩展程序）为 pod 筛选节点和确定节点的优先级。 +### 调度器扩展 {#scheduler-extensions} +调度器是一种特殊类型的控制器，用于监视 pod 并将其分配到节点。 +默认的调度器可以完全被替换，而继续使用其他 Kubernetes 组件，或者可以同时运行 +[多个调度器](/zh/docs/tasks/administer-cluster/configure-multiple-schedulers/)。 +这是一个不太轻松的任务，几乎所有的 Kubernetes 用户都会意识到他们并不需要修改调度器。 +调度器也支持 +[Webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md)， +它允许使用一个 Webhook 后端（调度器扩展程序）为 Pod 筛选节点和确定节点的优先级。 ## {{% heading "whatsnext" %}} - -* 详细了解[自定义资源](/docs/concepts/api-extension/custom-resources/) -* 了解[动态准入控制](/docs/reference/access-authn-authz/extensible-admission-controllers/) +* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) * 详细了解基础设施扩展 - * [网络插件](/docs/concepts/cluster-administration/network-plugins/) - * [设备插件](/docs/concepts/cluster-administration/device-plugins/) -* 了解 [kubectl 插件](/docs/tasks/extend-kubectl/kubectl-plugins/) -* 了解[操作者模式](/docs/concepts/extend-kubernetes/operator/) + * [网络插件](/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/) +* 了解[操作者模式](/zh/docs/concepts/extend-kubernetes/operator/) diff --git a/content/zh/docs/concepts/extend-kubernetes/operator.md b/content/zh/docs/concepts/extend-kubernetes/operator.md index c34a54676e..5cf55cbb8c 100644 --- a/content/zh/docs/concepts/extend-kubernetes/operator.md +++ b/content/zh/docs/concepts/extend-kubernetes/operator.md @@ -5,11 +5,9 @@ weight: 30 --- @@ -21,9 +19,9 @@ to manage applications and their components. Operators follow Kubernetes principles, notably the [control loop](/docs/concepts/#kubernetes-control-plane). --> -Operator 是 Kubernetes 的扩展软件，它利用[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。 -Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/docs/concepts/#kubernetes-control-plane)方面。 - +Operator 是 Kubernetes 的扩展软件，它利用 +[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)管理应用及其组件。 +Operator 遵循 Kubernetes 的理念，特别是在[控制回路](/zh/docs/concepts/#kubernetes-control-plane)方面。 @@ -40,7 +38,6 @@ People who run workloads on Kubernetes often like to use automation to take care of repeatable tasks. The Operator pattern captures how you can write code to automate a task beyond what Kubernetes itself provides. --> - ## 初衷 Operator 模式旨在捕获（正在管理一个或一组服务的）运维人员的关键目标。 @@ -62,14 +59,14 @@ of Kubernetes itself. Operators are clients of the Kubernetes API that act as controllers for a [Custom Resource](/docs/concepts/api-extension/custom-resources/). --> - ## Kubernetes 上的 Operator Kubernetes 为自动化而生。无需任何修改，您即可以从 Kubernetes 核心中获得许多内置的自动化功能。 您可以使用 Kubernetes 自动化部署和运行工作负载， *甚至* 可以自动化 Kubernetes 自身。 Kubernetes {{< glossary_tooltip text="控制器" term_id="controller" >}} 使您无需修改 Kubernetes 自身的代码，即可以扩展集群的行为。 -Operator 是 Kubernetes API 的客户端，充当[自定义资源](/docs/concepts/api-extension/custom-resources/)的控制器。 +Operator 是 Kubernetes API 的客户端，充当 +[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)的控制器。 - ## Operator 示例 {#example} 使用 Operator 可以自动化的事情包括： @@ -147,7 +143,6 @@ The Controller will normally run outside of the much as you would run any containerized application. For example, you can run the controller in your cluster as a Deployment. --> - ## 部署 Operator 部署 Operator 最常见的方法是将自定义资源及其关联的控制器添加到您的集群中。跟运行容器化应用一样，Controller 通常会运行在 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} 之外。例如，您可以在集群中将控制器作为 Deployment 运行。 @@ -198,13 +193,11 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie 如果生态系统中没可以实现您目标的 Operator，您可以自己编写代码。在[接下来](#what-s-next)一节中，您会找到编写自己的云原生 Operator 需要的库和工具的链接。 -您还可以使用任何支持 [Kubernetes API 客户端](/docs/reference/using-api/client-libraries/)的语言或运行时来实现 Operator（即控制器）。 - - +您还可以使用任何支持 [Kubernetes API 客户端](/zh/docs/reference/using-api/client-libraries/) +的语言或运行时来实现 Operator（即控制器）。 ## {{% heading "whatsnext" %}} - -* 详细了解[自定义资源](/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 详细了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合您的 Operator * 借助已有的工具来编写您自己的 Operator，例如： * [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator) @@ -228,6 +221,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie * [Operator 框架](https://github.com/operator-framework/getting-started) * [发布](https://operatorhub.io/)您的 Operator，让别人也可以使用 * 阅读 [CoreOS 原文](https://coreos.com/blog/introducing-operators.html)，其介绍了 Operator 介绍 -* 阅读这篇来自谷歌云的关于构建 Operator 最佳实践的[文章](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) +* 阅读这篇来自谷歌云的关于构建 Operator 最佳实践的 + [文章](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) diff --git a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md b/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md index e5b8b0941a..b719c0661f 100644 --- a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md @@ -31,7 +31,8 @@ weight: 20 A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication. --> {{< note >}} -现在推荐使用配置 [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 的 [`Deployment`](/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。 +现在推荐使用配置 [`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 的 +[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。 {{< /note >}} -_ReplicationController_ 确保在任何时候都有特定数量的 pod 副本处于运行状态。 -换句话说，ReplicationController 确保一个 pod 或一组同类的 pod 总是可用的。 - - +_ReplicationController_ 确保在任何时候都有特定数量的 Pod 副本处于运行状态。 +换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。 -## ReplicationController 如何工作 - -当 pod 数量过多时，ReplicationController 会终止多余的 pod。当 pod 数量太少时，ReplicationController 将会启动新的 pod。 -与手动创建的 pod 不同，由 ReplicationController 创建的 pod 在失败、被删除或被终止时会被自动替换。 -例如，在中断性维护（如内核升级）之后，您的 pod 会在节点上重新创建。 -因此，即使您的应用程序只需要一个 pod，您也应该使用 ReplicationController 创建 Pod。 -ReplicationController 类似于进程管理器，但是 ReplicationController 不是监控单个节点上的单个进程，而是监控跨多个节点的多个 pod。 +## ReplicationController 如何工作 + +当 Pod 数量过多时，ReplicationController 会终止多余的 Pod。当 Pod 数量太少时，ReplicationController 将会启动新的 Pod。 +与手动创建的 Pod 不同，由 ReplicationController 创建的 Pod 在失败、被删除或被终止时会被自动替换。 +例如，在中断性维护（如内核升级）之后，你的 Pod 会在节点上重新创建。 +因此，即使你的应用程序只需要一个 Pod，你也应该使用 ReplicationController 创建 Pod。 +ReplicationController 类似于进程管理器，但是 ReplicationController 不是监控单个节点上的单个进程，而是监控跨多个节点的多个 Pod。 ## 运行一个示例 ReplicationController -这个示例 ReplicationController 配置运行 nginx web 服务器的三个副本。 +这个示例 ReplicationController 配置运行 nginx Web 服务器的三个副本。 {{< codenew file="controllers/replication.yaml" >}} @@ -143,19 +141,20 @@ A little later, the same command may show: 在这里，创建了三个 Pod，但没有一个 Pod 正在运行，这可能是因为正在拉取镜像。 稍后，相同的命令可能会显示： -```shell +``` Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed ``` -要以机器可读的形式列出属于 ReplicationController 的所有 pod，可以使用如下命令： +要以机器可读的形式列出属于 ReplicationController 的所有 Pod，可以使用如下命令： ```shell pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name}) echo $pods ``` + ``` nginx-3ntk0 nginx-4ok8v nginx-qrm3m ``` @@ -165,8 +164,8 @@ Here, the selector is the same as the selector for the ReplicationController (se `kubectl describe` output), and in a different form in `replication.yaml`. The `--output=jsonpath` option specifies an expression that just gets the name from each pod in the returned list. --> -这里，选择器与 ReplicationController 的选择器相同（参见 `kubectl describe` 输出），并以不同的形式出现在 `replication.yaml` 中。 -`--output=jsonpath` 选项指定了一个表达式，只从返回列表中的每个 pod 中获取名称。 +这里，选择算符与 ReplicationController 的选择算符相同（参见 `kubectl describe` 输出），并以不同的形式出现在 `replication.yaml` 中。 +`--output=jsonpath` 选项指定了一个表达式，只从返回列表中的每个 Pod 中获取名称。 -### Pod 模板 - +### Pod 模板 {#pod-template} + `.spec.template` 是 `.spec` 的唯一必需字段。 -`.spec.template` 是一个 [pod 模板](/docs/concepts/workloads/pods/pod-overview/#pod-templates)。它的模式与 [pod](/docs/concepts/workloads/pods/pod/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。 +`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。 +它的模式与 [Pod](/zh/docs/concepts/workloads/pods/) 完全相同，只是它是嵌套的，没有 `apiVersion` 或 `kind` 属性。 -除了 Pod 所需的字段外，ReplicationController 中的 pod 模板必须指定适当的标签和适当的重新启动策略。 -对于标签，请确保不与其他控制器重叠。参考 [pod 选择器](#pod-selector)。 +除了 Pod 所需的字段外，ReplicationController 中的 Pod 模板必须指定适当的标签和适当的重新启动策略。 +对于标签，请确保不与其他控制器重叠。参考 [Pod 选择算符](#pod-selector)。 -只允许 [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。 +只允许 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always`，如果没有指定，这是默认值。 对于本地容器重启，ReplicationController 委托给节点上的代理， -例如 [Kubelet](/docs/admin/kubelet/) 或 Docker。 +例如 [Kubelet](/docs/reference/command-line-toolls-reference/kubelet/) 或 Docker。 -### Pod 选择器 {#pod-selector} - -`.spec.selector` 字段是一个[标签选择器](/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 -ReplicationController 管理标签与选择器匹配的所有 Pod。 +### Pod 选择算符 {#pod-selector} + +`.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 +ReplicationController 管理标签与选择算符匹配的所有 Pod。 它不区分它创建或删除的 Pod 和其他人或进程创建或删除的 Pod。 这允许在不影响正在运行的 Pod 的情况下替换 ReplicationController。 @@ -262,10 +260,11 @@ from doing this. If you do end up with multiple controllers that have overlapping selectors, you will have to manage the deletion yourself (see [below](#working-with-replicationcontrollers)). --> -另外，通常不应直接使用另一个 ReplicationController 或另一个控制器（例如 Job）来创建其标签与该选择器匹配的任何 Pod。如果这样做，ReplicationController 会认为它创建了这些 Pod。 +另外，通常不应直接使用另一个 ReplicationController 或另一个控制器（例如 Job） +来创建其标签与该选择算符匹配的任何 Pod。如果这样做，ReplicationController 会认为它创建了这些 Pod。 Kubernetes 并没有阻止你这样做。 -如果您的确创建了多个控制器并且其选择器之间存在重叠，那么您将不得不自己管理删除操作（参考[后文](#working-with-replicationcontrollers)）。 +如果你的确创建了多个控制器并且其选择算符之间存在重叠，那么你将不得不自己管理删除操作（参考[后文](#working-with-replicationcontrollers)）。 -## 使用 ReplicationController {#working-with-replicationcontrollers} - +## 使用 ReplicationController {#working-with-replicationcontrollers} + ### 删除一个 ReplicationController 以及它的 Pod -要删除一个 ReplicationController 以及它的 Pod，使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)。 +要删除一个 ReplicationController 以及它的 Pod，使用 +[`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete)。 kubectl 将 ReplicationController 缩放为 0 并等待以便在删除 ReplicationController 本身之前删除每个 Pod。 如果这个 kubectl 命令被中断，可以重新启动它。 -当使用 REST API 或 go 客户端库时，您需要明确地执行这些步骤（缩放副本为 0、 等待 Pod 删除，之后删除 ReplicationController 资源）。 +当使用 REST API 或 go 客户端库时，你需要明确地执行这些步骤（缩放副本为 0、 等待 Pod 删除，之后删除 ReplicationController 资源）。 -### 只删除 ReplicationController - -你可以删除一个 ReplicationController 而不影响它的任何 pod。 +### 只删除 ReplicationController -使用 kubectl ，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=false` 选项。 +你可以删除一个 ReplicationController 而不影响它的任何 Pod。 -当使用 REST API 或 go 客户端库时， 只需删除 ReplicationController 对象。 +使用 kubectl，为 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 指定 `--cascade=false` 选项。 + +当使用 REST API 或 go 客户端库时，只需删除 ReplicationController 对象。 -### 从 ReplicationController 中隔离 pod +### 从 ReplicationController 中隔离 Pod -通过更改 Pod 的标签，可以从 ReplicationController 的目标中删除 pod。 -此技术可用于从服务中删除 pod 以进行调试、数据恢复等。以这种方式删除的 pod 将自动替换（假设复制副本的数量也没有更改）。 +通过更改 Pod 的标签，可以从 ReplicationController 的目标中删除 Pod。 +此技术可用于从服务中删除 Pod 以进行调试、数据恢复等。以这种方式删除的 Pod 将自动替换（假设复制副本的数量也没有更改）。 -### 重新调度 +### 重新调度 {#rescheduling} -如上所述，无论您想要继续运行 1 个 pod 还是 1000 个 Pod，一个 ReplicationController 都将确保存在指定数量的 pod，即使在节点故障或 pod 终止(例如，由于另一个控制代理的操作)的情况下也是如此。 +如上所述，无论你想要继续运行 1 个 Pod 还是 1000 个 Pod，一个 ReplicationController 都将确保存在指定数量的 Pod，即使在节点故障或 Pod 终止(例如，由于另一个控制代理的操作)的情况下也是如此。 -### 扩缩容 +### 扩缩容 {#scaling} 通过简单地更新 `replicas` 字段，ReplicationController 可以方便地横向扩容或缩容副本的数量，或手动或通过自动缩放控制代理。 -### 滚动更新 {#rolling-updates} - -ReplicationController 的设计目的是通过逐个替换 pod 以方便滚动更新服务。 +### 滚动更新 {#rolling-updates} -如 [#1353](http://issue.k8s.io/1353) PR 中所述，建议的方法是使用 1 个副本创建一个新的 ReplicationController，逐个缩放新的（+1）和旧的（-1）控制器，然后在旧的控制器达到 0 个副本后将其删除。这一方法能够实现可控的 Pod 集合更新，即使存在意外失效的状况。 +ReplicationController 的设计目的是通过逐个替换 Pod 以方便滚动更新服务。 + +如 [#1353](https://issue.k8s.io/1353) PR 中所述，建议的方法是使用 1 个副本创建一个新的 ReplicationController， +逐个扩容新的（+1）和缩容旧的（-1）控制器，然后在旧的控制器达到 0 个副本后将其删除。 +这一方法能够实现可控的 Pod 集合更新，即使存在意外失效的状况。 理想情况下，滚动更新控制器将考虑应用程序的就绪情况，并确保在任何给定时间都有足够数量的 Pod 有效地提供服务。 -这两个 ReplicationController 将需要创建至少具有一个不同标签的 pod，比如 pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。 +这两个 ReplicationController 将需要创建至少具有一个不同标签的 Pod，比如 Pod 主要容器的镜像标签，因为通常是镜像更新触发滚动更新。 -滚动更新是在客户端工具 [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) 中实现的。 访问 [`kubectl rolling-update` 任务](/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。 +滚动更新是在客户端工具 [`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update) +中实现的。访问 [`kubectl rolling-update` 任务](/zh/docs/tasks/run-application/rolling-update-replication-controller/)以获得更多的具体示例。 -### 多个版本跟踪 - +### 多个版本跟踪 + 除了在滚动更新过程中运行应用程序的多个版本之外，通常还会使用多个版本跟踪来长时间，甚至持续运行多个版本。这些跟踪将根据标签加以区分。 -例如，一个服务可能把具有 `tier in (frontend), environment in (prod)` 的所有 pod 作为目标。 -现在假设您有 10 个副本的 pod 组成了这个层。但是你希望能够 `canary` （`金丝雀`）发布这个组件的新版本。 -您可以为大部分副本设置一个 ReplicationController，其中 `replicas` 设置为 9，标签为 `tier=frontend, environment=prod, track=stable` 而为 `canary` 设置另一个 ReplicationController，其中 `replicas` 设置为 1，标签为 `tier=frontend, environment=prod, track=canary`。 -现在这个服务覆盖了 `canary` 和非 `canary` Pod。但您可以单独处理 ReplicationController，以测试、监控结果等。 +例如，一个服务可能把具有 `tier in (frontend), environment in (prod)` 的所有 Pod 作为目标。 +现在假设你有 10 个副本的 Pod 组成了这个层。但是你希望能够 `canary` （`金丝雀`）发布这个组件的新版本。 +你可以为大部分副本设置一个 ReplicationController，其中 `replicas` 设置为 9， +标签为 `tier=frontend, environment=prod, track=stable` 而为 `canary` +设置另一个 ReplicationController，其中 `replicas` 设置为 1， +标签为 `tier=frontend, environment=prod, track=canary`。 +现在这个服务覆盖了 `canary` 和非 `canary` Pod。但你可以单独处理 ReplicationController，以测试、监控结果等。 ## ReplicationController 的职责 - -ReplicationController 只需确保所需的 pod 数量与其标签选择器匹配，并且是可操作的。 -目前，它的计数中只排除终止的 pod。 -未来，可能会考虑系统提供的[就绪状态](http://issue.k8s.io/620)和其他信息，我们可能会对替换策略添加更多控制，我们计划发出事件，这些事件可以被外部客户端用来实现任意复杂的替换和/或缩减策略。 +ReplicationController 只需确保所需的 Pod 数量与其标签选择算符匹配，并且是可操作的。 +目前，它的计数中只排除终止的 Pod。 +未来，可能会考虑系统提供的[就绪状态](https://issue.k8s.io/620)和其他信息， +我们可能会对替换策略添加更多控制， +我们计划发出事件，这些事件可以被外部客户端用来实现任意复杂的替换和/或缩减策略。 ReplicationController 永远被限制在这个狭隘的职责范围内。 它本身既不执行就绪态探测，也不执行活跃性探测。 -它不负责执行自动缩放，而是由外部自动缩放器控制（如 [#492](http://issue.k8s.io/492) 中所述），后者负责更改其 `replicas` 字段值。 -我们不会向 ReplicationController 添加调度策略(例如，[spreading](http://issue.k8s.io/367#issuecomment-48428019))。 -它也不应该验证所控制的 pod 是否与当前指定的模板匹配，因为这会阻碍自动调整大小和其他自动化过程。 +它不负责执行自动缩放，而是由外部自动缩放器控制（如 [#492](https://issue.k8s.io/492) 中所述），后者负责更改其 `replicas` 字段值。 +我们不会向 ReplicationController 添加调度策略(例如，[spreading](https://issue.k8s.io/367#issuecomment-48428019))。 +它也不应该验证所控制的 Pod 是否与当前指定的模板匹配，因为这会阻碍自动调整大小和其他自动化过程。 类似地，完成期限、整理依赖关系、配置扩展和其他特性也属于其他地方。 -我们甚至计划考虑批量创建 pod 的机制（查阅 [#170](http://issue.k8s.io/170)）。 +我们甚至计划考虑批量创建 Pod 的机制（查阅 [#170](https://issue.k8s.io/170)）。 -## ReplicationController 的替代方案 - - +## ReplicationController 的替代方案 + ### ReplicaSet -[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController ，支持新的[基于集合的标签选择器](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。 -它主要被 [`Deployment`](/docs/concepts/workloads/controllers/deployment/) 用来作为一种编排 pod 创建、删除及更新的机制。 -请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非您需要自定义更新编排或根本不需要更新。 +[`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 是下一代 ReplicationController， +支持新的[基于集合的标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#set-based-requirement)。 +它主要被 [`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 用来作为一种编排 Pod 创建、删除及更新的机制。 +请注意，我们推荐使用 Deployment 而不是直接使用 ReplicaSet，除非你需要自定义更新编排或根本不需要更新。 ### Deployment （推荐） -[`Deployment`](/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，它以类似于 `kubectl rolling-update` 的方式更新其底层 ReplicaSet 及其 Pod。 -如果您想要这种滚动更新功能，那么推荐使用 Deployment，因为与 `kubectl rolling-update` 不同，它们是声明式的、服务端的，并且具有其它特性。 +[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象， +它以类似于 `kubectl rolling-update` 的方式更新其底层 ReplicaSet 及其 Pod。 +如果你想要这种滚动更新功能，那么推荐使用 Deployment，因为与 `kubectl rolling-update` 不同， +它们是声明式的、服务端的，并且具有其它特性。 ### 裸 Pod -与用户直接创建 pod 的情况不同，ReplicationController 能够替换因某些原因被删除或被终止的 pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。 -因此，我们建议您使用 ReplicationController，即使您的应用程序只需要一个 pod。 -可以将其看作类似于进程管理器，它只管理跨多个节点的多个 pod ，而不是单个节点上的单个进程。 +与用户直接创建 Pod 的情况不同，ReplicationController 能够替换因某些原因被删除或被终止的 Pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。 +因此，我们建议你使用 ReplicationController，即使你的应用程序只需要一个 Pod。 +可以将其看作类似于进程管理器，它只管理跨多个节点的多个 Pod ，而不是单个节点上的单个进程。 ReplicationController 将本地容器重启委托给节点上的某个代理(例如，Kubelet 或 Docker)。 ### Job -对于预期会自行终止的 pod (即批处理任务)，使用 [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) 而不是 ReplicationController。 +对于预期会自行终止的 Pod (即批处理任务)，使用 +[`Job`](/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。 ### DaemonSet -对于提供机器级功能（例如机器监控或机器日志记录）的 pod ，使用 [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) 而不是 ReplicationController。 -这些 pod 的生命期与机器的生命期绑定：它们需要在其他 pod 启动之前在机器上运行，并且在机器准备重新启动或者关闭时安全地终止。 +对于提供机器级功能（例如机器监控或机器日志记录）的 Pod， +使用 [`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不是 +ReplicationController。 +这些 Pod 的生命期与机器的生命期绑定：它们需要在其他 Pod 启动之前在机器上运行， +并且在机器准备重新启动或者关闭时安全地终止。 ## 更多信息 -请阅读[运行无状态的 Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/)。 - +请阅读[运行无状态的 ReplicationController](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。