kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

[zh] Fix links in concepts section (5)

This commit is contained in:
Qiming Teng 2020-08-03 21:59:13 +08:00
parent dab8047c85
commit b4189b5800
9 changed files with 485 additions and 370 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
content/en/docs/concepts/extend-kubernetes/extend-cluster.md
View File

@ -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).

29
content/zh/docs/concepts/architecture/control-plane-node-communication.md
View File

@ -5,9 +5,6 @@ weight: 20
---
<!--
reviewers:
- dchen1107
- liggitt
title: Control Plane-Node Communication
content_type: concept
weight: 20
@ -20,8 +17,7 @@ aliases:
<!--
This document catalogs the communication paths between the control plane (really the apiserver) and the Kubernetes cluster. The intent is to allow users to customize their installation to harden the network configuration such that the cluster can be run on an untrusted network (or on fully public IPs on a cloud provider).
-->
本文对控制面节点（确切说是 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)的时候。
<!--
Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. For example, on a default GKE deployment, the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
-->
应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 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 客户端证书。
<!--
@ -57,7 +51,6 @@ The `kubernetes` service (in all namespaces) is configured with a virtual IP add
The control plane components also communicate with the cluster apiserver over the secure port.
-->
想要连接到 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
<!--
As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.
-->
这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的，能够在不可信的网络或公网上运行。
<!--
@ -76,7 +68,6 @@ As a result, the default operating mode for connections from the nodes and pods
There are two primary communication paths from the control plane (apiserver) to the nodes. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver's proxy functionality.
-->
## 控制面到节点
从控制面（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。
<!--
### apiserver to nodes, pods, and services
@ -177,5 +168,5 @@ Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity
控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。
启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。
请浏览 [Konnectivity 服务任务](/docs/tasks/extend-kubernetes/setup-konnectivity/)
请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/)
在你的集群中配置 Konnectivity 服务。

114
content/zh/docs/concepts/architecture/controller.md
View File

@ -16,18 +16,16 @@ about your *desired state*. The actual room temperature is the
*current state*. The thermostat acts to bring the current state
closer to the desired state, by turning equipment on or off.
-->
在机器人技术和自动化中，控制回路是一个非终止回路，用于调节系统状态。
在机器人技术和自动化领域，控制回路（Control Loop）是一个非终止回路，用于调节系统状态。
这是一个控制环的例子：房间里的温度自动调节器。
当你设置了温度，告诉了温度自动调节器你的*期望状态*。房间的实际温度是*当前状态*。通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。
当你设置了温度，告诉了温度自动调节器你的*期望状态（Desired State）*。
房间的实际温度是*当前状态（Current State）*。
通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。
{{< glossary_definition term_id="controller" length="short">}}
<!-- body -->
<!--
## Controller pattern
@ -51,12 +49,18 @@ detail.
-->
## 控制器模式 {#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 >}}
<!--
@ -87,15 +91,19 @@ and eventually the work is done.
### 通过 API 服务器来控制 {#control-via-API-server}
{{< glossary_tooltip term_id="job" >}} 控制器是一个 Kubernetes 内置控制器的例子。内置控制器通过和集群 API 服务器交互来管理状态。
{{< glossary_tooltip text="Job" term_id="job" >}} 控制器是一个 Kubernetes 内置控制器的例子。
内置控制器通过和集群 API 服务器交互来管理状态。
Job 是一种 Kubernetes 资源，它运行一个 {{< glossary_tooltip term_id="pod" >}}，或者可能是多个 Pod，来执行一个任务然后停止。
Job 是一种 Kubernetes 资源，它运行一个或者多个 {{< glossary_tooltip term_id="pod" >}}，
来执行一个任务然后停止。
（一旦[被调度了](/zh/docs/concepts/scheduling-eviction/)，对 `kubelet` 来说 Pod
对象就会变成了期望状态的一部分）。
（一旦[被调度了](/docs/concepts/scheduling/)），对 kubelet 来说 Pod 对象就会变成了期望状态的一部分。
在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 kubelet 可以运行正确数量的 Pod 来完成工作。
在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 `kubelet`
可以运行正确数量的 Pod 来完成工作。
Job 控制器不会自己运行任何的 Pod 或者容器。Job 控制器是通知 API 服务器来创建或者移除 Pod。
{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}中的其它组件根据新的消息而反应（调度新的 Pod 并且运行它）并且最终完成工作。
{{< glossary_tooltip text="控制面" term_id="control-plane" >}}中的其它组件
根据新的消息作出反应（调度并运行新 Pod）并且最终完成工作。
<!--
After you create a new Job, the desired state is for that Job to be completed.
@ -110,7 +118,6 @@ updates that Job object to mark it `Finished`.
(This is a bit like how some thermostats turn a light off to
indicate that your room is now at the temperature you set).
-->
创建新 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 versus current state {#desired-vs-current}
@ -160,12 +168,11 @@ potentially, your cluster never reaches a stable state.
As long as the controllers for your cluster are running and able to make
useful changes, it doesn't matter if the overall state is or is not stable.
-->
## 期望状态与当前状态 {#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 的设计正是考虑到了这一点。
<!--
There can be several controllers that create or update the same kind of object.
Behind the scenes, Kubernetes controllers make sure that they only pay attention
to the resources linked to their controlling resource.
@ -195,21 +207,14 @@ For example, you can have Deployments and Jobs; these both create Pods.
The Job controller does not delete the Pods that your Deployment created,
because there is information ({{< glossary_tooltip term_id="label" text="labels" >}})
the controllers can use to tell those Pods apart.
{{< /note >}}
-->
## 设计 {#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 >}}
<!--
@ -229,27 +234,30 @@ Or, if you want, you can write a new controller yourself.
You can run your own controller as a set of Pods,
or externally to Kubernetes. What fits best will depend on what that particular
controller does.
-->
## 运行控制器的方式 {#running-controllers}
Kubernetes 内置一组控制器，运行在 {{< glossary_tooltip term_id="kube-controller-manager" >}} 内。
这些内置的控制器提供了重要的核心功能。
Deployment 控制器和 Job 控制器是 Kubernetes 内置控制器的典型例子。
Kubernetes 允许你运行一个稳定的控制平面，这样即使某些内置控制器失败了，
控制平面的其他部分会接替它们的工作。
你会遇到某些控制器运行在控制面之外，用以扩展 Kubernetes。
或者，如果你愿意，你也可以自己编写新控制器。
你可以以一组 Pod 来运行你的控制器，或者运行在 Kubernetes 之外。
最合适的方案取决于控制器所要执行的功能是什么。
## {{% heading "whatsnext" %}}
<!--
* Read about the [Kubernetes control plane](/docs/concepts/#kubernetes-control-plane)
* Discover some of the basic [Kubernetes objects](/docs/concepts/#kubernetes-objects)
* Learn more about the [Kubernetes API](/docs/concepts/overview/kubernetes-api/)
* If you want to write your own controller, see [Extension Patterns](/docs/concepts/extend-kubernetes/extend-cluster/#extension-patterns) in Extending Kubernetes.
-->
## 运行控制器的方式 {#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)。

48
content/zh/docs/concepts/extend-kubernetes/_index.md
View File

@ -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/).
<!--
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,7 +97,7 @@ API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境
这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定，所以
新的集群配置是可复用的，并且可以当作应用程序来管理。
此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样，采纳的是
一种[预定义的支持策略](/zh/docs/reference/deprecation-policy/)。
一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。
出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于*配置文件*和*参数标志*。
<!--
@ -171,7 +171,7 @@ Kubernetes control plane.
在*可执行文件插件（Binary Plugin）*模式中，Kubernetes 执行某个可执行文件（程序）。
可执行文件插件在 kubelet （例如，
[FlexVolume 插件](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md)
和[网络插件](/zh/docs/concepts/cluster-administration/network-plugins/)）
和[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)）
和 kubectl 中使用。
下面的示意图中展示了这些扩展点如何与 Kubernetes 控制面交互。
@ -210,28 +210,28 @@ If you are unsure where to start, this flowchart can help. Note that some soluti
2. API 服务器处理所有请求。API 服务器中的几种扩展点能够使用户对请求执行身份认证、
基于其内容阻止请求、编辑请求内容、处理删除操作等等。
这些扩展点在 [API 访问扩展](/zh/docs/concepts/overview/extending#api-access-extensions)
这些扩展点在 [API 访问扩展](#api-access-extensions)
节详述。
3. API 服务器向外提供不同类型的*资源（resources）*。
*内置的资源类型*，如 `pods`，是由 Kubernetes 项目所定义的，无法改变。
你也可以添加自己定义的或者其他项目所定义的称作*自定义资源（Custom Resources）*
的资源，正如[自定义资源](/zh/docs/concepts/overview/extending#user-defined-types)节所描述的那样。
的资源，正如[自定义资源](#user-defined-types)节所描述的那样。
自定义资源通常与 API 访问扩展点结合使用。
4. Kubernetes 调度器负责决定 Pod 要放置到哪些节点上执行。
有几种方式来扩展调度行为。这些方法将在
[调度器扩展](/zh/docs/concepts/overview/extending#scheduler-extensions)节中展开。
[调度器扩展](#scheduler-extensions)节中展开。
5. Kubernetes 中的很多行为都是通过称为控制器（Controllers）的程序来实现的，这些程序也都是 API 服务器
的客户端。控制器常常与自定义资源结合使用。
6. 组件 kubelet 运行在各个节点上，帮助 Pod 展现为虚拟的服务器并在集群网络中拥有自己的 IP。
[网络插件](/zh/docs/concepts/overview/extending#network-plugins)使得 Kubernetes 能够采用
[网络插件](#network-plugins)使得 Kubernetes 能够采用
不同实现技术来连接 Pod 网络。
7. 组件 kubelet 也会为容器增加或解除存储卷的挂载。
通过[存储插件](/zh/docs/concepts/overview/extending#storage-plugins)，可以支持新的存储类型。
通过[存储插件](#storage-plugins)，可以支持新的存储类型。
如果你无法确定从何处入手，下面的流程图可能对你有些帮助。
注意，某些方案可能需要同时采用几种类型的扩展。
@ -248,7 +248,7 @@ Consider adding a Custom Resource to Kubernetes if you want to define new contro
Do not use a Custom Resource as data storage for application, user, or monitoring data.
For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/api-extension/custom-resources/).
For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
-->
## 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/)。
<!--
### Combining New APIs with Automation
@ -333,7 +333,7 @@ Kubernetes 提供若干种内置的认证方法，以及
-->
### 鉴权 {#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/)，可以支持
不同的网络设施。
<!--
@ -435,7 +435,7 @@ the nodes chosen for a pod.
## {{% heading "whatsnext" %}}
<!--
* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
* Learn more about Infrastructure extensions
* [Network Plugins](/docs/concepts/cluster-administration/network-plugins/)
@ -443,11 +443,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/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/)

80
content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
View File

@ -1,7 +1,7 @@
---
title: 通过聚合层扩展 Kubernetes API
content_type: concept
weight: 10
weight: 20
---
<!--
---
@ -11,7 +11,7 @@ reviewers:
- cheftako
- chenopis
content_type: concept
weight: 10
weight: 20
---
-->
@ -20,57 +20,77 @@ weight: 10
<!--
The aggregation layer allows Kubernetes to be extended with additional APIs, beyond what is offered by the core Kubernetes APIs.
-->
聚合层允许 Kubernetes 通过额外的 API 进行扩展，而不局限于 Kubernetes 核心 API 提供的功能。
使用聚合层（Aggregation Layer），用户可以通过额外的 API 扩展 Kubernetes，
而不局限于 Kubernetes 核心 API 提供的功能。
<!--
The additional APIs can either be ready-made solutions such as [service-catalog](/docs/concepts/extend-kubernetes/service-catalog/), or APIs that you develop yourself.
The aggregation layer is different from [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/), which are a way to make the {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} recognise new kinds of object.
-->
这里的附加 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）。
<!-- body -->
<!--
## Overview
## Aggregation layer
The aggregation layer enables installing additional Kubernetes-style APIs in your cluster. These can either be pre-built, existing 3rd party solutions, such as [service-catalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/README.md), or user-created APIs like [apiserver-builder](https://github.com/kubernetes-incubator/apiserver-builder/blob/master/README.md), which can get you started.
-->
## 概述
聚合层使您的集群可以安装其他 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可以帮助你上手。
<!--
The aggregation layer runs in-process with the kube-apiserver. Until an extension resource is registered, the aggregation layer will do nothing. To register an API, users must add an APIService object, which "claims" the URL path in the Kubernetes API. At that point, the aggregation layer will proxy anything sent to that API path (e.g. /apis/myextension.mycompany.io/v1/…) to the registered APIService.
-->
聚合层在 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。
<!--
Ordinarily, the APIService will be implemented by an *extension-apiserver* in a pod running in the cluster. This extension-apiserver will normally need to be paired with one or more controllers if active management of the added resources is needed. As a result, the apiserver-builder will actually provide a skeleton for both. As another example, when the service-catalog is installed, it provides both the extension-apiserver and controller for the services it provides.
The most common way to implement the APIService is to run an *extension API server* in Pod(s) that run in your cluster. If you're using the extension API server to manage resources in your cluster, the extension API server (also written as "extension-apiserver") is typically paired with one or more {{< glossary_tooltip text="controllers" term_id="controller" >}}. The apiserver-builder library provides a skeleton for both extension API servers and the associated controller(s).
-->
正常情况下，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 服务器和控制器框架代码。
<!--
Extension-apiservers should have low latency connections to and from the kube-apiserver.
In particular, discovery requests are required to round-trip from the kube-apiserver in five seconds or less.
If your deployment cannot achieve this, you should consider how to change it. For now, setting the
`EnableAggregatedDiscoveryTimeout=false` feature gate on the kube-apiserver
will disable the timeout restriction. It will be removed in a future release.
### Response latency
Extension API servers should have low latency networking to and from the kube-apiserver.
Discovery requests are required to round-trip from the kube-apiserver in five seconds or less.
If your extension API server cannot achieve that latency requirement, consider making changes that let you meet it. You can also set the
`EnableAggregatedDiscoveryTimeout=false` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on the kube-apiserver
to disable the timeout restriction. This deprecated feature gate will be removed in a future release.
-->
### 反应延迟 {#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" %}}
<!--
* To get the aggregator working in your environment, [configure the aggregation layer](/docs/tasks/access-kubernetes-api/configure-aggregation-layer/).
* Then, [setup an extension api-server](/docs/tasks/access-kubernetes-api/setup-extension-api-server/) to work with the aggregation layer.
* Also, learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/access-kubernetes-api/extend-api-custom-resource-definitions/).
* Read the specification for [APIService](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#apiservice-v1-apiregistration-k8s-io)
-->
* 阅读[配置聚合层](/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) 的规范

118
content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
View File

@ -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 适配器以及其他类似的、可能需要特定于供应商的初始化和设置的计算资源。
<!-- body -->
@ -32,7 +30,7 @@ Kubernetes 提供了一个[设备插件框架](https://github.com/kubernetes/com
<!--
The kubelet exports a `Registration` gRPC service:
-->
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)
规范请求这类设备，但是有以下的限制：
* 扩展资源仅可作为整数资源使用，并且不能被过量使用
* 设备不能在容器之间共享
* 扩展资源仅可作为整数资源使用，并且不能被过量使用
* 设备不能在容器之间共享
<!--
Suppose a Kubernetes cluster is running a device plugin that advertises resource `hardware-vendor.example/foo`
on certain nodes. Here is an example of a pod requesting this resource to run a demo workload:
-->
假设 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 将此信息传递到容器运行时。
<!--
### Handling kubelet restarts
@ -168,7 +172,10 @@ of its Unix socket and re-register itself upon such an event.
-->
### 处理 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 被删除，并且当发生此类事件时重新注册自己。
<!--
## Device plugin deployment
@ -190,9 +197,13 @@ Pod onto Nodes, to restart the daemon Pod after failure, and to help automate up
你可以将你的设备插件作为节点操作系统的软件包来部署、作为 DaemonSet 来部署或者手动部署。
规范目录 `/var/lib/kubelet/device-plugins` 是需要特权访问的，所以设备插件必须要在被授权的安全的上下文中运行。如果你将设备插件部署为 DaemonSet，`/var/lib/kubelet/device-plugins` 目录必须要在插件的 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中声明作为 {{< glossary_tooltip term_id="volume" >}} 被 mount 到插件中。
规范目录 `/var/lib/kubelet/device-plugins` 是需要特权访问的，所以设备插件必须要在被授权的安全的上下文中运行。
如果你将设备插件部署为 DaemonSet，`/var/lib/kubelet/device-plugins` 目录必须要在插件的
[PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
中声明作为 {{< glossary_tooltip term_id="volume" >}} 被 mount 到插件中。
如果你选择 DaemonSet 方法，你可以通过 Kubernetes 进行以下操作：将设备插件的 Pod 放置在节点上，在出现故障后重新启动 daemon Pod，来进行自动进行升级。
如果你选择 DaemonSet 方法，你可以通过 Kubernetes 进行以下操作：
将设备插件的 Pod 放置在节点上，在出现故障后重新启动守护进程 Pod，来进行自动升级。
<!--
## API compatibility
@ -210,12 +221,15 @@ ensure the continuous functioning of the device allocations during the upgrade.
-->
## API 兼容性
Kubernetes 设备插件支持还处于 beta 版本。所以在稳定版本出来之前 API 会以不兼容的方式进行更改。作为一个项目，Kubernetes 建议设备插件开发者：
Kubernetes 设备插件支持还处于 beta 版本。所以在稳定版本出来之前 API 会以不兼容的方式进行更改。
作为一个项目，Kubernetes 建议设备插件开发者：
* 注意未来版本的更改
* 支持多个版本的设备插件 API，以实现向后/向前兼容性。
如果你启用 DevicePlugins 功能，并在需要升级到 Kubernetes 版本来获得较新的设备插件 API 版本的节点上运行设备插件，请在升级这些节点之前先升级设备插件以支持这两个版本。采用该方法将确保升级期间设备分配的连续运行。
如果你启用 DevicePlugins 功能，并在需要升级到 Kubernetes 版本来获得较新的设备插件 API
版本的节点上运行设备插件，请在升级这些节点之前先升级设备插件以支持这两个版本。
采用该方法将确保升级期间设备分配的连续运行。
<!--
## Monitoring Device Plugin Resources
@ -233,7 +247,11 @@ identifying containers using `pod`, `namespace`, and `container` prometheus labe
{{< feature-state for_k8s_version="v1.15" state="beta" >}}
为了监控设备插件提供的资源，监控代理程序需要能够发现节点上正在使用的设备，并获取元数据来描述哪个指标与容器相关联。设备监控代理暴露给 [Prometheus](https://prometheus.io/) 的指标应该遵循 [Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md)，使用 `pod`、`namespace` 和 `container` 标签来标识容器。
为了监控设备插件提供的资源，监控代理程序需要能够发现节点上正在使用的设备，
并获取元数据来描述哪个指标与容器相关联。
设备监控代理暴露给 [Prometheus](https://prometheus.io/) 的指标应该遵循
[Kubernetes Instrumentation Guidelines](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/instrumentation.md)，
使用 `pod`、`namespace` 和 `container` 标签来标识容器。
<!--
The kubelet provides a gRPC service to enable discovery of in-use devices, and to provide metadata
@ -260,9 +278,18 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
Support for the "PodResources service" requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled. It is enabled by default starting with Kubernetes 1.15.
-->
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 开始默认启用。
<!--
## Device Plugin integration with the Topology Manager
@ -275,7 +302,8 @@ The Topology Manager is a Kubelet component that allows resources to be co-ordin
{{< feature-state for_k8s_version="v1.17" state="alpha" >}}
拓扑管理器是 Kubelet 的一个组件，它允许以拓扑对齐方式来调度资源。为了做到这一点，设备插件 API 进行了扩展来包括一个 `TopologyInfo` 结构体。
拓扑管理器是 Kubelet 的一个组件，它允许以拓扑对齐方式来调度资源。
为了做到这一点，设备插件 API 进行了扩展来包括一个 `TopologyInfo` 结构体。
```gRPC
message TopologyInfo {
@ -298,9 +326,11 @@ An example `TopologyInfo` struct populated for a device by a Device Plugin:
pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{&pluginapi.NUMANode{ID: 0,},}}}
```
-->
设备插件希望拓扑管理器可以将填充的 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" %}}
<!--
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
* Learn about the [Topology Manager] (/docs/tasks/adminster-cluster/topology-manager/)
-->
* 查看 [调度 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/)

226
content/zh/docs/concepts/extend-kubernetes/extend-cluster.md
View File

@ -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" >}}
也可以从本文找到有用的信息，如对已存在扩展点和模式的介绍，以及它们的权衡和限制。
<!-- body -->
@ -46,27 +50,28 @@ Customization approaches can be broadly divided into *configuration*, which only
-->
## 概述
定制方法可以大致分为 *配置* 和 *扩展* 。*配置* 只涉及更改标志参数、本地配置文件或 API 资源；*扩展* 涉及运行额外的程序或服务。本文档主要内容是关于扩展。
定制方法可以大致分为 *配置（Configuration）* 和 *扩展（Extension）* 。
*配置* 只涉及更改标志参数、本地配置文件或 API 资源；
*扩展* 涉及运行额外的程序或服务。本文档主要内容是关于扩展。
<!--
## Configuration
-->
## 配置
<!--
*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/).
<!--
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.
@ -74,10 +79,18 @@ Flags and configuration files may not always be changeable in a hosted Kubernete
在托管的 Kubernetes 服务或受控安装的 Kubernetes 版本中，标志和配置文件可能并不总是可以更改的。而且当它们可以进行更改时，它们通常只能由集群管理员进行更改。此外，标志和配置文件在未来的 Kubernetes 版本中可能会发生变化，并且更改设置后它们可能需要重新启动进程。出于这些原因，只有在没有其他选择的情况下才使用它们。
<!--
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/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/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/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](/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/)。
出于这些原因，在合适的情况下它们优先于 *配置文件* 和 *标志* 被使用。
<!--
## Extensions
@ -89,16 +102,17 @@ Most cluster administrators will use a hosted or distribution
instance of Kubernetes. As a result, most Kubernetes users will need to
install extensions and fewer will need to author new ones.
-->
## 扩展程序
## 扩展程序 {#extension}
扩展程序是指对 Kubernetes 进行扩展和深度集成的软件组件。它们适合用于支持新的类型和新型硬件。
大多数集群管理员会使用托管的或统一分发的 Kubernetes 实例。因此，大多数 Kubernetes 用户需要安装扩展程序，而且还有少部分用户甚至需要编写新的扩展程序。
大多数集群管理员会使用托管的或统一分发的 Kubernetes 实例。
因此，大多数 Kubernetes 用户需要安装扩展程序，而且还有少部分用户甚至需要编写新的扩展程序。
<!--
## Extension Patterns
-->
## 扩展模式
## 扩展模式 {#extension-patterns}
<!--
Kubernetes is designed to be automated by writing client programs. Any
@ -108,7 +122,10 @@ the guidance in this doc you can write highly available and robust automation.
Automation generally works with any Kubernetes cluster, including hosted
clusters and managed installations.
-->
Kubernetes 的设计是通过编写客户端程序来实现自动化的。任何读和（或）写 Kubernetes API 的程序都可以提供有用的自动化工作。*自动化* 程序可以运行在集群之中或之外。按照本文档的指导，您可以编写出高可用的和健壮的自动化程序。自动化程序通常适用于任何 Kubernetes 集群，包括托管集群和受管理安装的集群。
Kubernetes 的设计是通过编写客户端程序来实现自动化的。
任何读和（或）写 Kubernetes API 的程序都可以提供有用的自动化工作。
*自动化* 程序可以运行在集群之中或之外。按照本文档的指导，你可以编写出高可用的和健壮的自动化程序。
自动化程序通常适用于任何 Kubernetes 集群，包括托管集群和受管理安装的集群。
<!--
There is a specific pattern for writing client programs that work well with
@ -120,9 +137,12 @@ calls out to a remote service, it is called a *Webhook*. The remote service
is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of
failure.
-->
*控制器* 模式是编写适合 Kubernetes 的客户端程序的一种特定模式。控制器通常读取一个对象的 `.spec` 字段，可能做出一些处理，然后更新对象的 `.status` 字段。
*控制器（Controller）* 模式是编写适合 Kubernetes 的客户端程序的一种特定模式。
控制器通常读取一个对象的 `.spec` 字段，可能做出一些处理，然后更新对象的 `.status` 字段。
一个控制器是 Kubernetes 的一个客户端。而当 Kubernetes 作为客户端调用远程服务时，它被称为 *Webhook* ，远程服务称为 *Webhook* 后端。 和控制器类似，Webhooks 增加了一个失败点。
一个控制器是 Kubernetes 的一个客户端。
当 Kubernetes 作为客户端调用远程服务时，它被称为 *Webhook* ，
远程服务称为 *Webhook* 后端。 和控制器类似，Webhooks 增加了一个失败点。
<!--
In the webhook model, Kubernetes makes a network request to a remote service.
@ -133,7 +153,12 @@ and [Network
Plugins](/docs/concepts/cluster-administration/network-plugins/))
and by kubectl.
-->
在 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` 所使用。
<!--
Below is a diagram showing how the extensions points interact with the
@ -152,7 +177,7 @@ This diagram shows the extension points in a Kubernetes system.
<img src="https://docs.google.com/drawings/d/e/2PACX-1vSH5ZWUO2jH9f34YHenhnCd14baEb4vT-pzfxeFC7NzdNqRDgdz4DDAVqArtH4onOGqh0bhwMX0zGBb/pub?w=425&h=809">
-->
## 扩展点
## 扩展点 {#extension-points}
下图显示了 Kubernetes 系统的扩展点。
@ -162,27 +187,38 @@ 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/overview/extending#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/overview/extending#user-defined-types) section. Custom Resources are often used with API Access Extensions.
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.
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/overview/extending#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/overview/extending#storage-plugins).
-->
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/)支持。
<!--
If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions.
-->
如果您不确定从哪里开始扩展，此流程图可以提供帮助。请注意，某些解决方案可能涉及多种类型的扩展。
如果你不确定从哪里开始扩展，下面流程图可以提供一些帮助。请注意，某些解决方案可能涉及多种类型的扩展。
<img src="https://docs.google.com/drawings/d/e/2PACX-1vRWXNNIVWFDqzDY0CsKZJY3AR8sDeFDXItdc5awYxVH8s0OLherMlEPVUpxPIB1CSUu7GPk7B2fEnzM/pub?w=1440&h=1080">
@ -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/)。
<!--
### Combining New APIs with Automation
@ -214,7 +252,10 @@ The combination of a custom resource API and a control loop is called the [Opera
-->
### 将新的 API 与自动化相结合
自定义资源 API 和控制循环的组合称为 [操作者模式](/docs/concepts/extend-kubernetes/operator/)。操作者模式用于管理特定的，通常是有状态的应用程序。这些自定义 API 和控制循环还可用于控制其他资源，例如存储或策略。
自定义资源 API 和控制循环的组合称为
[操作者（Operator）模式](/zh/docs/concepts/extend-kubernetes/operator/)。
操作者模式用于管理特定的，通常是有状态的应用程序。
这些自定义 API 和控制循环还可用于控制其他资源，例如存储或策略。
<!--
### Changing Built-in Resources
@ -224,7 +265,9 @@ Adding an API does not directly let you affect the behavior of existing APIs (e.
-->
### 改变内置资源
当您通过添加自定义资源来扩展 Kubernetes API 时，添加的资源始终属于新的 API 组。您不能替换或更改已有的 API 组。添加 API 不会直接影响现有 API（例如 Pod ）的行为，但是 API 访问扩展可以。
当你通过添加自定义资源来扩展 Kubernetes API 时，添加的资源始终属于新的 API 组。
你不能替换或更改已有的 API 组。
添加 API 不会直接影响现有 API（例如 Pod ）的行为，但是 API 访问扩展可以。
<!--
### API Access Extensions
@ -235,13 +278,17 @@ Each of these steps offers extension points.
Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/).
-->
### 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
@ -250,20 +297,26 @@ Kubernetes 有几个它支持的内置认证方法。它还可以位于身份验
Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs.
-->
### 身份认证
### 身份认证 {#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
[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It just works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
-->
### 授权
### 鉴权 {#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/)
允许调用用户提供的代码来作出授权决定。
<!--
### Dynamic Admission Control
@ -275,10 +328,15 @@ After a request is authorized, if it is a write operation, it also goes through
-->
### 动态准入控制
在请求被授权之后，如果是写入操作，它还将进入[准入控制](/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 可以拒绝创建或更新操作。
<!--
## Infrastructure Extensions
@ -292,11 +350,11 @@ Kubelet call a Binary Plugin to mount the volume.
-->
## 基础设施扩展
### 存储插件
[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md
) 允许用户挂载无内置插件支持的卷类型，它通过 Kubelet 调用一个二进制插件来挂载卷。
)
允许用户挂载无内置插件支持的卷类型，它通过 Kubelet 调用一个可执行文件插件来挂载卷。
<!--
### Device Plugins
@ -305,18 +363,22 @@ Device plugins allow a node to discover new Node resources (in addition to the
builtin ones like cpu and memory) via a [Device
Plugin](/docs/concepts/cluster-administration/device-plugins/).
-->
### 设备插件
### 设备插件 {#device-plugins}
设备插件允许节点通过[设备插件](/docs/concepts/cluster-administration/device-plugins/)发现新的节点资源（除了内置的 CPU 和内存之外）。
设备插件允许节点通过
[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/).
发现新的节点资源（除了内置的 CPU 和内存之外）。
<!--
### Network Plugins
Different networking fabrics can be supported via node-level [Network Plugins](/docs/admin/network-plugins/).
-->
### 网络插件
### 网络插件 {#network-plugins}
不同的网络结构可以通过节点级的[网络插件](/docs/admin/network-plugins/)支持。
不同的网络结构可以通过节点级的
[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
得到支持。
<!--
### Scheduler Extensions
@ -335,20 +397,20 @@ The scheduler also supports a
that permits a webhook backend (scheduler extension) to filter and prioritize
the nodes chosen for a pod.
-->
### 调度器扩展
调度器是一种特殊类型的控制器，用于监视 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" %}}
<!--
* Learn more about [Custom Resources](/docs/concepts/api-extension/custom-resources/)
* Learn about [Dynamic admission control](/docs/reference/access-authn-authz/extensible-admission-controllers/)
@ -358,12 +420,12 @@ 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/)
-->
* 详细了解[自定义资源](/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/)

26
content/zh/docs/concepts/extend-kubernetes/operator.md
View File

@ -5,11 +5,9 @@ weight: 30
---
<!--
---
title: Operator pattern
content_type: concept
weight: 30
---
-->
<!-- overview -->
@ -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)方面。
<!-- body -->
@ -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/)的控制器。
<!--
## An example Operator {#example}
@ -86,7 +83,6 @@ Some of the things that you can use an operator to automate include:
* choosing a leader for a distributed application without an internal
member election process
-->
## 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" %}}
<!--
* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case
@ -219,7 +212,7 @@ that can act as a [client for the Kubernetes API](/docs/reference/using-api/clie
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
-->
* 详细了解[自定义资源](/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)

212
content/zh/docs/concepts/workloads/controllers/replicationcontroller.md
View File

@ -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 >}}
<!--
@ -39,19 +40,14 @@ A _ReplicationController_ ensures that a specified number of pod replicas are ru
time. In other words, a ReplicationController makes sure that a pod or a homogeneous set of pods is
always up and available.
-->
_ReplicationController_ 确保在任何时候都有特定数量的 pod 副本处于运行状态。
换句话说，ReplicationController 确保一个 pod 或一组同类的 pod 总是可用的。
_ReplicationController_ 确保在任何时候都有特定数量的 Pod 副本处于运行状态。
换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。
<!-- body -->
<!--
## How a ReplicationController Works
-->
## ReplicationController 如何工作
<!--
If there are too many pods, the ReplicationController terminates the extra pods. If there are too few, the
ReplicationController starts more pods. Unlike manually created pods, the pods maintained by a
ReplicationController are automatically replaced if they fail, are deleted, or are terminated.
@ -61,11 +57,13 @@ only a single pod. A ReplicationController is similar to a process supervisor,
but instead of supervising individual processes on a single node, the ReplicationController supervises multiple pods
across multiple nodes.
-->
当 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 is often abbreviated to "rc" in discussion, and as a shortcut in
@ -87,7 +85,7 @@ This example ReplicationController config runs three copies of the nginx web ser
-->
## 运行一个示例 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
```
<!--
To list all the pods that belong to the ReplicationController in a machine readable form, you can use a command like this:
-->
要以机器可读的形式列出属于 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 中获取名称。
<!--
## Writing a ReplicationController Spec
@ -179,23 +178,23 @@ A ReplicationController also needs a [`.spec` section](https://git.k8s.io/commun
## 编写一个 ReplicationController Spec
与所有其它 Kubernetes 配置一样，ReplicationController 需要 `apiVersion`、`kind` 和 `metadata` 字段。
有关使用配置文件的常规信息，参考[对象管理](/docs/concepts/overview/working-with-objects/object-management/)。
有关使用配置文件的常规信息，参考[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management/)。
ReplicationController 也需要一个 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。
<!--
### Pod Template
-->
### Pod 模板
<!--
The `.spec.template` is the only required field of the `.spec`.
The `.spec.template` is a [pod template](/docs/concepts/workloads/pods/pod-overview/#pod-templates). It has exactly the same schema as a [pod](/docs/concepts/workloads/pods/pod/), except it is nested and does not have an `apiVersion` or `kind`.
-->
### 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` 属性。
<!--
In addition to required fields for a Pod, a pod template in a ReplicationController must specify appropriate
@ -206,13 +205,13 @@ Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-l
For local container restarts, ReplicationControllers delegate to an agent on the node,
for example the [Kubelet](/docs/admin/kubelet/) or Docker.
-->
除了 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。
<!--
### Labels on the ReplicationController
@ -225,23 +224,22 @@ different, and the `.metadata.labels` do not affect the behavior of the Replicat
### ReplicationController 上的标签
ReplicationController 本身可以有标签 （`.metadata.labels`）。
通常，您可以将这些设置为 `.spec.template.metadata.labels`；
通常，你可以将这些设置为 `.spec.template.metadata.labels`；
如果没有指定 `.metadata.labels` 那么它默认为 `.spec.template.metadata.labels`。
但是，Kubernetes 允许它们是不同的，`.metadata.labels` 不会影响 ReplicationController 的行为。
<!--
### Pod Selector
-->
### Pod 选择器 {#pod-selector}
<!--
The `.spec.selector` field is a [label selector](/docs/concepts/overview/working-with-objects/labels/#label-selectors). A ReplicationController
manages all the pods with labels that match the selector. It does not distinguish
between pods that it created or deleted and pods that another person or process created or
deleted. This allows the ReplicationController to be replaced without affecting the running pods.
-->
`.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)）。
<!--
### Multiple Replicas
@ -280,16 +279,13 @@ If you do not specify `.spec.replicas`, then it defaults to 1.
### 多个副本
你可以通过设置 `.spec.replicas` 来指定应该同时运行多少个 Pod。
在任何时候，处于运行状态的 Pod 个数都可能高于或者低于设定值。例如，副本个数刚刚被增加或减少时，或者一个 pod 处于优雅终止过程中而其替代副本已经提前开始创建时。
在任何时候，处于运行状态的 Pod 个数都可能高于或者低于设定值。例如，副本个数刚刚被增加或减少时，或者一个 Pod 处于优雅终止过程中而其替代副本已经提前开始创建时。
如果你没有指定 `.spec.replicas` ，那么它默认是 1。
<!--
## Working with ReplicationControllers
-->
## 使用 ReplicationController {#working-with-replicationcontrollers}
<!--
### Deleting a ReplicationController and its Pods
To delete a ReplicationController and all its pods, use [`kubectl
@ -300,31 +296,33 @@ command is interrupted, it can be restarted.
When using the REST API or go client library, you need to do the steps explicitly (scale replicas to
0, wait for pod deletions, then delete the ReplicationController).
-->
## 使用 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 资源）。
<!--
### Deleting just a ReplicationController
-->
### 只删除 ReplicationController
<!--
You can delete a ReplicationController without affecting any of its pods.
Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).
When using the REST API or go client library, simply delete the ReplicationController object.
-->
你可以删除一个 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 对象。
<!--
Once the original is deleted, you can create a new ReplicationController to replace it. As long
@ -342,10 +340,10 @@ To update pods to a new spec in a controlled way, use a [rolling update](#rollin
Pods may be removed from a ReplicationController's target set by changing their labels. This technique may be used to remove pods from service for debugging, data recovery, etc. Pods that are removed in this way will be replaced automatically (assuming that the number of replicas is not also changed).
-->
### 从 ReplicationController 中隔离 pod
### 从 ReplicationController 中隔离 Pod
通过更改 Pod 的标签，可以从 ReplicationController 的目标中删除 pod。
此技术可用于从服务中删除 pod 以进行调试、数据恢复等。以这种方式删除的 pod 将自动替换（假设复制副本的数量也没有更改）。
通过更改 Pod 的标签，可以从 ReplicationController 的目标中删除 Pod。
此技术可用于从服务中删除 Pod 以进行调试、数据恢复等。以这种方式删除的 Pod 将自动替换（假设复制副本的数量也没有更改）。
<!--
## Common usage patterns
@ -357,31 +355,32 @@ Pods may be removed from a ReplicationController's target set by changing their
As mentioned above, whether you have 1 pod you want to keep running, or 1000, a ReplicationController will ensure that the specified number of pods exists, even in the event of node failure or pod termination (for example, due to an action by another control agent).
-->
### 重新调度
### 重新调度 {#rescheduling}
如上所述，无论您想要继续运行 1 个 pod 还是 1000 个 Pod，一个 ReplicationController 都将确保存在指定数量的 pod，即使在节点故障或 pod 终止(例如，由于另一个控制代理的操作)的情况下也是如此。
如上所述，无论你想要继续运行 1 个 Pod 还是 1000 个 Pod，一个 ReplicationController 都将确保存在指定数量的 Pod，即使在节点故障或 Pod 终止(例如，由于另一个控制代理的操作)的情况下也是如此。
<!--
### Scaling
The ReplicationController makes it easy to scale the number of replicas up or down, either manually or by an auto-scaling control agent, by simply updating the `replicas` field.
-->
### 扩缩容
### 扩缩容 {#scaling}
通过简单地更新 `replicas` 字段，ReplicationController 可以方便地横向扩容或缩容副本的数量，或手动或通过自动缩放控制代理。
<!--
### Rolling updates
-->
### 滚动更新 {#rolling-updates}
<!--
The ReplicationController is designed to facilitate rolling updates to a service by replacing pods one-by-one.
As explained in [#1353](http://issue.k8s.io/1353), the recommended approach is to create a new ReplicationController with 1 replica, scale the new (+1) and old (-1) controllers one by one, and then delete the old controller after it reaches 0 replicas. This predictably updates the set of pods regardless of unexpected failures.
-->
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 集合更新，即使存在意外失效的状况。
<!--
Ideally, the rolling update controller would take application readiness into account, and would ensure that a sufficient number of pods were productively serving at any given time.
@ -393,26 +392,29 @@ Rolling update is implemented in the client tool
-->
理想情况下，滚动更新控制器将考虑应用程序的就绪情况，并确保在任何给定时间都有足够数量的 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/)以获得更多的具体示例。
<!--
### Multiple release tracks
-->
### 多个版本跟踪
<!--
In addition to running multiple releases of an application while a rolling update is in progress, it's common to run multiple releases for an extended period of time, or even continuously, using multiple release tracks. The tracks would be differentiated by labels.
For instance, a service might target all pods with `tier in (frontend), environment in (prod)`. Now say you have 10 replicated pods that make up this tier. But you want to be able to 'canary' a new version of this component. You could set up a ReplicationController with `replicas` set to 9 for the bulk of the replicas, with labels `tier=frontend, environment=prod, track=stable`, and another ReplicationController with `replicas` set to 1 for the canary, with labels `tier=frontend, environment=prod, track=canary`. Now the service is covering both the canary and non-canary pods. But you can mess with the ReplicationControllers separately to test things out, monitor the results, etc.
-->
### 多个版本跟踪
除了在滚动更新过程中运行应用程序的多个版本之外，通常还会使用多个版本跟踪来长时间，甚至持续运行多个版本。这些跟踪将根据标签加以区分。
例如，一个服务可能把具有 `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，以测试、监控结果等。
<!--
### Using ReplicationControllers with Services
@ -427,7 +429,8 @@ A ReplicationController will never terminate on its own, but it isn't expected t
多个 ReplicationController 可以位于一个服务的后面，例如，一部分流量流向旧版本，一部分流量流向新版本。
一个 ReplicationController 永远不会自行终止，但它不会像服务那样长时间存活。
服务可以由多个 ReplicationController 控制的 Pod 组成，并且在服务的生命周期内（例如，为了执行 pod 更新而运行服务），可以创建和销毁许多 ReplicationController。
服务可以由多个 ReplicationController 控制的 Pod 组成，并且在服务的生命周期内
（例如，为了执行 Pod 更新而运行服务），可以创建和销毁许多 ReplicationController。
服务本身和它们的客户端都应该忽略负责维护服务 Pod 的 ReplicationController 的存在。
<!--
@ -439,31 +442,35 @@ Pods created by a ReplicationController are intended to be fungible and semantic
由 ReplicationController 创建的 Pod 是可替换的，语义上是相同的，尽管随着时间的推移，它们的配置可能会变得异构。
这显然适合于多副本的无状态服务器，但是 ReplicationController 也可以用于维护主选、分片和工作池应用程序的可用性。
这样的应用程序应该使用动态的工作分配机制，例如 [RabbitMQ 工作队列](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)，而不是静态的或者一次性定制每个 pod 的配置，这被认为是一种反模式。
执行的任何 pod 定制，例如资源的垂直自动调整大小(例如，cpu 或内存)，都应该由另一个在线控制器进程执行，这与 ReplicationController 本身没什么不同。
这样的应用程序应该使用动态的工作分配机制，例如
[RabbitMQ 工作队列](https://www.rabbitmq.com/tutorials/tutorial-two-python.html)，
而不是静态的或者一次性定制每个 Pod 的配置，这被认为是一种反模式。
执行的任何 Pod 定制，例如资源的垂直自动调整大小（例如，CPU 或内存），
都应该由另一个在线控制器进程执行，这与 ReplicationController 本身没什么不同。
<!--
## Responsibilities of the ReplicationController
The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
-->
## ReplicationController 的职责
<!--
The ReplicationController simply ensures that the desired number of pods matches its label selector and are operational. Currently, only terminated pods are excluded from its count. In the future, [readiness](http://issue.k8s.io/620) and other information available from the system may be taken into account, we may add more controls over the replacement policy, and we plan to emit events that could be used by external clients to implement arbitrarily sophisticated replacement and/or scale-down policies.
-->
ReplicationController 只需确保所需的 pod 数量与其标签选择器匹配，并且是可操作的。
目前，它的计数中只排除终止的 pod。
未来，可能会考虑系统提供的[就绪状态](http://issue.k8s.io/620)和其他信息，我们可能会对替换策略添加更多控制，我们计划发出事件，这些事件可以被外部客户端用来实现任意复杂的替换和/或缩减策略。
ReplicationController 只需确保所需的 Pod 数量与其标签选择算符匹配，并且是可操作的。
目前，它的计数中只排除终止的 Pod。
未来，可能会考虑系统提供的[就绪状态](https://issue.k8s.io/620)和其他信息，
我们可能会对替换策略添加更多控制，
我们计划发出事件，这些事件可以被外部客户端用来实现任意复杂的替换和/或缩减策略。
<!--
The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](http://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](http://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](http://issue.k8s.io/170)).
-->
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)）。
<!--
The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
@ -471,7 +478,8 @@ The ReplicationController is intended to be a composable building-block primitiv
ReplicationController 旨在成为可组合的构建基元。
我们希望在它和其他补充原语的基础上构建更高级别的 API 或者工具，以便于将来的用户使用。
kubectl 目前支持的 "macro" 操作（运行、缩放、滚动更新）就是这方面的概念示例。
例如，我们可以想象类似于 [Asgard](http://techblog.netflix.com/2012/06/asgaard-web-based-cloud-management-and.html) 的东西管理 ReplicationController、自动定标器、服务、调度策略、 canary 等。
例如，我们可以想象类似于 [Asgard](https://techblog.netflix.com/2012/06/asgaard-web-based-cloud-management-and.html)
的东西管理 ReplicationController、自动定标器、服务、调度策略、金丝雀发布等。
<!--
## API Object
@ -488,21 +496,20 @@ API object can be found at:
<!--
## Alternatives to ReplicationController
-->
## ReplicationController 的替代方案
<!--
### ReplicaSet
[`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is the next-generation ReplicationController that supports the new [set-based label selector](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement).
It’s mainly used by [`Deployment`](/docs/concepts/workloads/controllers/deployment/) as a mechanism to orchestrate pod creation, deletion and updates.
It’s mainly used by [`Deployment`](/docs/concepts/workloads/controllers/deployment/) as a mechanism to orchestrate Pod creation, deletion and updates.
Note that we recommend using Deployments instead of directly using Replica Sets, unless you require custom update orchestration or don’t require updates at all.
-->
## 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 (Recommended)
@ -513,8 +520,10 @@ because unlike `kubectl rolling-update`, they are declarative, server-side, and
-->
### 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` 不同，
它们是声明式的、服务端的，并且具有其它特性。
<!--
### Bare Pods
@ -523,20 +532,21 @@ Unlike in the case where a user directly created pods, a ReplicationController r
-->
### 裸 Pod
与用户直接创建 pod 的情况不同，ReplicationController 能够替换因某些原因被删除或被终止的 pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。
因此，我们建议您使用 ReplicationController，即使您的应用程序只需要一个 pod。
可以将其看作类似于进程管理器，它只管理跨多个节点的多个 pod ，而不是单个节点上的单个进程。
与用户直接创建 Pod 的情况不同，ReplicationController 能够替换因某些原因被删除或被终止的 Pod ，例如在节点故障或中断节点维护的情况下，例如内核升级。
因此，我们建议你使用 ReplicationController，即使你的应用程序只需要一个 Pod。
可以将其看作类似于进程管理器，它只管理跨多个节点的多个 Pod ，而不是单个节点上的单个进程。
ReplicationController 将本地容器重启委托给节点上的某个代理(例如，Kubelet 或 Docker)。
<!--
### Job
Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicationController for pods that are expected to terminate on their own
Use a [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) instead of a ReplicationController for Pods that are expected to terminate on their own
(that is, batch jobs).
-->
### Job
对于预期会自行终止的 pod (即批处理任务)，使用 [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) 而不是 ReplicationController。
对于预期会自行终止的 Pod (即批处理任务)，使用
[`Job`](/docs/concepts/workloads/controllers/job/) 而不是 ReplicationController。
<!--
### DaemonSet
@ -548,8 +558,11 @@ safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
-->
### DaemonSet
对于提供机器级功能（例如机器监控或机器日志记录）的 pod ，使用 [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) 而不是 ReplicationController。
这些 pod 的生命期与机器的生命期绑定：它们需要在其他 pod 启动之前在机器上运行，并且在机器准备重新启动或者关闭时安全地终止。
对于提供机器级功能（例如机器监控或机器日志记录）的 Pod，
使用 [`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) 而不是
ReplicationController。
这些 Pod 的生命期与机器的生命期绑定：它们需要在其他 Pod 启动之前在机器上运行，
并且在机器准备重新启动或者关闭时安全地终止。
<!--
## For more information
@ -558,6 +571,5 @@ Read [Run Stateless AP Replication Controller](/docs/tutorials/stateless-applica
-->
## 更多信息
请阅读[运行无状态的 Replication Controller](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/)。
请阅读[运行无状态的 ReplicationController](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。