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

Merge pull request #22941 from tengqm/zh-ccm 

[zh] Rework cloud controller
pull/23721/head
Kubernetes Prow Robot 2020-09-06 20:25:41 -07:00 committed by GitHub
parent 7454f35abf 1d05d2cba2
commit 4bc6ff7f7d
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 190 additions and 346 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

536
content/zh/docs/concepts/architecture/cloud-controller.md
View File

@ -1,359 +1,208 @@
---
title: 云控制器管理器的基础概念
content_type: concept
weight: 30
weight: 40
---
<!--
---
title: Concepts Underlying the Cloud Controller Manager
content_type: concept
weight: 30
---
weight: 40
-->
<!-- overview -->
<!--
The cloud controller manager (CCM) concept (not to be confused with the binary) was originally created to allow cloud specific vendor code and the Kubernetes core to evolve independent of one another. The cloud controller manager runs alongside other master components such as the Kubernetes controller manager, the API server, and scheduler. It can also be started as a Kubernetes addon, in which case it runs on top of Kubernetes.
-->
云控制器管理器（cloud controller manager，CCM）这个概念 （不要与二进制文件混淆）创建的初衷是为了让特定的云服务供应商代码和 Kubernetes 核心相互独立演化。云控制器管理器与其他主要组件（如 Kubernetes 控制器管理器，API 服务器和调度程序）一起运行。它也可以作为 Kubernetes 的插件启动，在这种情况下，它会运行在 Kubernetes 之上。
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
<!--
The cloud controller manager's design is based on a plugin mechanism that allows new cloud providers to integrate with Kubernetes easily by using plugins. There are plans in place for on-boarding new cloud providers on Kubernetes and for migrating cloud providers from the old model to the new CCM model.
Cloud infrastructure technologies let you run Kubernetes on public, private, and hybrid clouds.
Kubernetes believes in automated, API-driven infrastructure without tight coupling between
components.
-->
使用云基础设施技术，你可以在共有云、私有云或者混合云环境中运行 Kubernetes。
Kubernetes 的信条是基于自动化的、API 驱动的基础设施，同时避免组件间紧密耦合。
云控制器管理器基于插件机制设计，允许新的云服务供应商通过插件轻松地与 Kubernetes 集成。目前已经有在 Kubernetes 上加入新的云服务供应商计划，并为云服务供应商提供从原先的旧模式迁移到新 CCM 模式的方案。
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="组件 cloud-controller-manager 是">}}
<!--
This document discusses the concepts behind the cloud controller manager and gives details about its associated functions.
The cloud-controller-manager is structured using a plugin
mechanism that allows different cloud providers to integrate their platforms with Kubernetes.
-->
本文讨论了云控制器管理器背后的概念，并提供了相关功能的详细信息。
<!--
Here's the architecture of a Kubernetes cluster without the cloud controller manager:
-->
这是没有云控制器管理器的 Kubernetes 集群的架构：
<!--
![Pre CCM Kube Arch](/images/docs/pre-ccm-arch.png)
-->
![没有云控制器管理器的 Kubernetes 架构](/images/docs/pre-ccm-arch.png)
`cloud-controller-manager` 组件是基于一种插件机制来构造的，
这种机制使得不同的云厂商都能将其平台与 Kubernetes 集成。
<!-- body -->
<!--
## Design
![Kubernetes components](/images/docs/components-of-kubernetes.png)
The cloud controller manager runs in the control plane as a replicated set of processes
(usually, these are containers in Pods). Each cloud-controller-manager implements
multiple {{< glossary_tooltip text="controllers" term_id="controller" >}} in a single
process.
-->
## 设计 {#design}
![Kubernetes 组件](/images/docs/components-of-kubernetes.png)
## 设计
云控制器管理器以一组多副本的进程集合的形式运行在控制面中，通常表现为 Pod
中的容器。每个 `cloud-controller-manager` 在同一进程中实现多个
{{< glossary_tooltip text="控制器" term_id="controller" >}}。
<!--
In the preceding diagram, Kubernetes and the cloud provider are integrated through several different components:
You can also run the cloud controller manager as a Kubernetes
{{< glossary_tooltip text="addon" term_id="addons" >}} rather than as part
of the control plane.
-->
在上图中，Kubernetes 和云服务供应商通过几个不同的组件进行了集成，分别是：
<!--
* Kubelet
* Kubernetes controller manager
* Kubernetes API server
-->
* Kubelet
* Kubernetes 控制管理器
* Kubernetes API 服务器
<!--
The CCM consolidates all of the cloud-dependent logic from the preceding three components to create a single point of integration with the cloud. The new architecture with the CCM looks like this:
-->
CCM 整合了前三个组件中的所有依赖于云的逻辑，以创建与云的单一集成点。CCM 的新架构如下所示：
<!--
![CCM Kube Arch](/images/docs/post-ccm-arch.png)
-->
![含有云控制器管理器的 Kubernetes 架构](/images/docs/post-ccm-arch.png)
<!--
## Components of the CCM
-->
## CCM 的组成部分
<!--
The CCM breaks away some of the functionality of Kubernetes controller manager (KCM) and runs it as a separate process. Specifically, it breaks away those controllers in the KCM that are cloud dependent. The KCM has the following cloud dependent controller loops:
-->
CCM 打破了 Kubernetes 控制器管理器（KCM）的一些功能，并将其作为一个单独的进程运行。具体来说，它打破了 KCM 中依赖于云的控制器。KCM 具有以下依赖于云的控制器：
<!--
* Node controller
* Volume controller
* Route controller
* Service controller
-->
* 节点控制器
* 卷控制器
* 路由控制器
* 服务控制器
<!--
In version 1.9, the CCM runs the following controllers from the preceding list:
-->
在 1.9 版本中，CCM 运行前述列表中的以下控制器：
<!--
* Node controller
* Route controller
* Service controller
-->
* 节点控制器
* 路由控制器
* 服务控制器
{{< note >}}
<!--
Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM.
-->
注意卷控制器不属于 CCM，由于其中涉及到的复杂性和对现有供应商特定卷的逻辑抽象，因此决定了卷控制器不会被移动到 CCM 之中。
你也可以以 Kubernetes {{< glossary_tooltip text="插件" term_id="addons" >}}
的形式而不是控制面中的一部分来运行云控制器管理器。
{{< /note >}}
<!--
The original plan to support volumes using CCM was to use Flex volumes to support pluggable volumes. However, a competing effort known as CSI is being planned to replace Flex.
-->
## Cloud controller manager functions {#functions-of-the-ccm}
使用 CCM 支持 volume 的最初计划是使用 Flex volume 来支持可插拔卷，但是现在正在计划一项名为 CSI 的项目以取代 Flex。
The controllers inside the cloud controller manager include:
-->
## 云控制器管理器的功能 {#functions-of-the-ccm}
云控制器管理器中的控制器包括：
<!--
Considering these dynamics, we decided to have an intermediate stop gap measure until CSI becomes ready.
-->
### Node controller
考虑到这些正在进行中的变化，在 CSI 准备就绪之前，我们决定停止当前的工作。
The node controller is responsible for creating {{< glossary_tooltip text="Node" term_id="node" >}} objects
when new servers are created in your cloud infrastructure. The node controller obtains information about the
hosts running inside your tenancy with the cloud provider. The node controller performs the following functions:
-->
### 节点控制器 {#node-controller}
节点控制器负责在云基础设施中创建了新服务器时为之 创建
{{< glossary_tooltip text="节点（Node）" term_id="node" >}}对象。
节点控制器从云提供商获取当前租户中主机的信息。节点控制器执行以下功能：
<!--
## Functions of the CCM
1. Initialize a Node object for each server that the controller discovers through the cloud provider API.
2. Annotating and labelling the Node object with cloud-specific information, such as the region the node
is deployed into and the resources (CPU, memory, etc) that it has available.
3. Obtain the node's hostname and network addresses.
4. Verifying the node's health. In case a node becomes unresponsive, this controller checks with
your cloud provider's API to see if the server has been deactivated / deleted / terminated.
If the node has been deleted from the cloud, the controller deletes the Node object from your Kubernetes
cluster.
-->
## CCM 的功能
<!--
The CCM inherits its functions from components of Kubernetes that are dependent on a cloud provider. This section is structured based on those components.
-->
CCM 从依赖于云提供商的 Kubernetes 组件继承其功能，本节基于这些组件组织。
<!--
### 1. Kubernetes controller manager
-->
### 1. Kubernetes 控制器管理器
<!--
The majority of the CCM's functions are derived from the KCM. As mentioned in the previous section, the CCM runs the following control loops:
-->
CCM 的大多数功能都来自 KCM，如上一节所述，CCM 运行以下控制器。
<!--
* Node controller
* Route controller
* Service controller
-->
* 节点控制器
* 路由控制器
* 服务控制器
<!--
#### Node controller
-->
#### 节点控制器
<!--
The Node controller is responsible for initializing a node by obtaining information about the nodes running in the cluster from the cloud provider. The node controller performs the following functions:
-->
节点控制器负责通过从云提供商获取有关在集群中运行的节点的信息来初始化节点，节点控制器执行以下功能：
<!--
1. Initialize a node with cloud specific zone/region labels.
2. Initialize a node with cloud specific instance details, for example, type and size.
3. Obtain the node's network addresses and hostname.
4. In case a node becomes unresponsive, check the cloud to see if the node has been deleted from the cloud.
If the node has been deleted from the cloud, delete the Kubernetes Node object.
-->
1. 使用特定于云的域（zone）/区（region）标签初始化节点；
2. 使用特定于云的实例详细信息初始化节点，例如，类型和大小；
1. 针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象；
2. 利用特定云平台的信息为 Node 对象添加注解和标签，例如节点所在的
区域（Region）和所具有的资源（CPU、内存等等）；
3. 获取节点的网络地址和主机名；
4. 如果节点无响应，请检查云以查看该节点是否已从云中删除。如果已从云中删除该节点，请删除 Kubernetes 节点对象。
4. 检查节点的健康状况。如果节点无响应，控制器通过云平台 API ll 查看该节点是否
已从云中禁用、删除或终止。如果节点已从云中删除，则控制器从 Kubernetes 集群
中删除 Node 对象。
<!--
#### Route controller
Some cloud provider implementations split this into a node controller and a separate node
lifecycle controller.
-->
#### 路由控制器
<!--
The Route controller is responsible for configuring routes in the cloud appropriately so that containers on different nodes in the Kubernetes cluster can communicate with each other. The route controller is only applicable for Google Compute Engine clusters.
-->
Route 控制器负责适当地配置云中的路由，以便 Kubernetes 集群中不同节点上的容器可以相互通信。route 控制器仅适用于 Google Compute Engine 群集。
<!--
#### Service Controller
-->
#### 服务控制器
<!--
The Service controller is responsible for listening to service create, update, and delete events. Based on the current state of the services in Kubernetes, it configures cloud load balancers (such as ELB , Google LB, or Oracle Cloud Infrastructure LB) to reflect the state of the services in Kubernetes. Additionally, it ensures that service backends for cloud load balancers are up to date.
-->
<!--
### 2. Kubelet
-->
### 2. Kubelet
<!--
The Node controller contains the cloud-dependent functionality of the kubelet. Prior to the introduction of the CCM, the kubelet was responsible for initializing a node with cloud-specific details such as IP addresses, region/zone labels and instance type information. The introduction of the CCM has moved this initialization operation from the kubelet into the CCM.
-->
节点控制器包含 kubelet 中云依赖的功能，在引入 CCM 之前，kubelet 负责使用特定于云平台的功能特性（如 IP 地址，域/区标签和实例类型信息）初始化节点。CCM 的引入已将此初始化操作从 kubelet 转移到 CCM 中。
<!--
In this new model, the kubelet initializes a node without cloud-specific information. However, it adds a taint to the newly created node that makes the node unschedulable until the CCM initializes the node with cloud-specific information. It then removes this taint.
-->
在这个新模型中，kubelet 初始化一个没有特定于云平台的功能特性的节点。但是，它会为新创建的节点添加污点，使节点不可调度，直到 CCM 使用云的规格信息初始化节点后，才会清除这种污点，便得该节点可被调度。
<!--
## Plugin mechanism
-->
## 插件机制
<!--
The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the CloudProvider Interface defined [here](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
-->
云控制器管理器使用 Go 接口允许插入任何云的实现。具体来说，它使用[此处](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62)定义的 CloudProvider 接口。
<!--
The implementation of the four shared controllers highlighted above, and some scaffolding along with the shared cloudprovider interface, will stay in the Kubernetes core. Implementations specific to cloud providers will be built outside of the core and implement interfaces defined in the core.
-->
上面强调的四个共享控制器的实现，以及一些辅助设施（scaffolding）和共享的 cloudprovider 接口，将被保留在 Kubernetes 核心中。但特定于云提供商的实现将在核心之外构建，并实现核心中定义的接口。
<!--
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
-->
有关开发插件的更多信息，请参阅[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)。
<!--
## Authorization
-->
## 授权
<!--
This section breaks down the access required on various API objects by the CCM to perform its operations.
-->
本节分解了 CCM 执行其操作时各种 API 对象所需的访问权限。
<!--
### Node Controller
-->
### 节点控制器
<!--
The Node controller only works with Node objects. It requires full access to get, list, create, update, patch, watch, and delete Node objects.
-->
Node 控制器仅适用于 Node 对象，它需要完全访问权限来获取、列出、创建、更新、修补、监视和删除 Node 对象。
<!--
v1/Node:
- Get
- List
- Create
- Update
- Patch
- Watch
- Delete
-->
v1/Node:
- Get
- List
- Create
- Update
- Patch
- Watch
- Delete
某些云驱动实现中，这些任务被划分到一个节点控制器和一个节点生命周期控制器中。
<!--
### Route controller
-->
### 路由控制器
The route controller is responsible for configuring routes in the cloud
appropriately so that containers on different nodes in your Kubernetes
cluster can communicate with each other.
Depending on the cloud provider, the route controller might also allocate blocks
of IP addresses for the Pod network.
-->
### 路由控制器 {#route-controller}
Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的
容器之间可以相互通信。
取决于云驱动本身，路由控制器可能也会为 Pod 网络分配 IP 地址块。
<!--
The route controller listens to Node object creation and configures routes appropriately. It requires get access to Node objects.
### Service controller
{< glossary_tooltip text="Services" term_id="service" >}} integrate with cloud
infrastructure components such as managed load balancers, IP addresses, network
packet filtering, and target health checking. The service controller interacts with your
cloud provider's APIs to set up load balancers and other infrastructure components
when you declare a Service resource that requires them.
-->
### 服务控制器 {#service-controller}
路由控制器侦听 Node 对象创建并适当地配置路由，它需要访问 Node 对象。
{{< glossary_tooltip text="服务（Service）" term_id="service" >}}与受控的负载均衡器、
IP 地址、网络包锅里煮、目标健康检查等云基础设施组件集成。
服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。
你所创建的 Service 资源会需要这些组件服务。
v1/Node:
<!--
## Authorization
This section breaks down the access that the cloud controller managers requires
on various API objects, in order to perform its operations.
-->
## 鉴权 {#authorization}
本节分别讲述云控制器管理器为了完成自身工作而产生的对各类 API 对象的访问需求。
<!--
### Node controller {#authorization-node-controller}
The Node controller only works with Node objects. It requires full access
to read and modify Node objects.
-->
### 节点控制器 {#authorization-node-controller}
节点控制器只操作 Node 对象。它需要读取和修改 Node 对象的完全访问权限。
`v1/Node`:
- Get
- List
- Create
- Update
- Patch
- Watch
- Delete
<!--
### Route controller {#authorization-route-controller}
The route controller listens to Node object creation and configures
routes appropriately. It requires Get access to Node objects.
-->
### 路由控制器 {#authorization-route-controller}
路由控制器会监听 Node 对象的创建事件，并据此配置路由设施。
它需要读取 Node 对象的 Get 权限。
`v1/Node`:
- Get
<!--
### Service controller
### Service controller {#authorization-service-controller}
The service controller listens to Service object Create, Update and Delete events and then configures Endpoints for those Services appropriately.
To access Services, it requires List, and Watch access. To update Services, it requires Patch and Update access.
To set up Endpoints resources for the Services, it requires access to Create, List, Get, Watch, and Update.
-->
### 服务控制器 {#authorization-service-controller}
### 服务控制器
服务控制器监测 Service 对象的 Create、Update 和 Delete 事件，并配置
对应服务的 Endpoints 对象。
为了访问 Service 对象，它需要 List、Watch 访问权限；为了更新 Service 对象
它需要 Patch 和 Update 访问权限。
为了能够配置 Service 对应的 Endpoints 资源，它需要 Create、List、Get、Watch
和 Update 等访问权限。
<!--
The service controller listens to Service object create, update and delete events and then configures endpoints for those Services appropriately.
-->
服务控制器侦听 Service 对象创建、更新和删除事件，然后适当地为这些服务配置端点。
<!--
To access Services, it requires list, and watch access. To update Services, it requires patch and update access.
-->
要访问服务，它需要列表和监视访问权限。要更新服务，它需要修补和更新访问权限。
<!--
To set up endpoints for the Services, it requires access to create, list, get, watch, and update.
-->
要为服务设置端点，需要访问 create、list、get、watch 和 update。
v1/Service:
`v1/Service`:
- List
- Get
@ -362,32 +211,40 @@ v1/Service:
- Update
<!--
### Others
-->
### Others {#authorization-miscellaneous}
### 其它
The implementation of the core of the cloud controller manager requires access to create Event objects, and to ensure secure operation, it requires access to create ServiceAccounts.
<!--
The implementation of the core of CCM requires access to create events, and to ensure secure operation, it requires access to create ServiceAccounts.
-->
CCM 核心的实现需要访问权限以创建事件，并且为了确保安全操作，它需要访问权限以创建服务账户。
v1/Event:
`v1/Event`:
- Create
- Patch
- Update
v1/ServiceAccount:
`v1/ServiceAccount`:
- Create
<!--
The RBAC ClusterRole for the CCM looks like this:
The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole for the cloud
controller manager looks like:
-->
### 其他 {#authorization-miscellaneous}
针对 CCM 的 RBAC ClusterRole 看起来像这样：
云控制器管理器的实现中，其核心部分需要创建 Event 对象的访问权限以及
创建 ServiceAccount 资源以保证操作安全性的权限。
`v1/Event`:
- Create
- Patch
- Update
`v1/ServiceAccount`:
- Create
用于云控制器管理器 {{< glossary_tooltip term_id="rbac" text="RBAC" >}}
的 ClusterRole 如下例所示：
```yaml
apiVersion: rbac.authorization.k8s.io/v1
@ -451,50 +308,37 @@ rules:
- update
```
<!--
## Vendor Implementations
-->
## 供应商实施
## {{% heading "whatsnext" %}}
<!--
The following cloud providers have implemented CCMs:
-->
[Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
has instructions on running and managing the cloud controller manager.
以下云服务提供商已实现了 CCM：
Want to know how to implement your own cloud controller manager, or extend an existing project?
-->
[云控制器管理器的管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
给出了运行和管理云控制器管理器的指南。
想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？
<!--
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the `CloudProvider` interface defined in [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62) from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
-->
* [Alibaba Cloud](https://github.com/kubernetes/cloud-provider-alibaba-cloud)
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
* [OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
云控制器管理器使用 Go 语言的接口，从而使得针对各种云平台的具体实现都可以接入。
其中使用了在 [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider)
项目中 [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62)
文件所定义的 `CloudProvider` 接口。
<!--
## Cluster Administration
The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface.
For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
-->
本文中列举的共享控制器（节点控制器、路由控制器和服务控制器等）的实现以及
其他一些生成具有 CloudProvider 接口的框架的代码，都是 Kubernetes 的核心代码。
特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。
## 群集管理
<!--
Complete instructions for configuring and running the CCM are provided
[here](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager).
-->
[这里](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)提供了有关配置和运行 CCM 的完整说明。
关于如何开发插件的详细信息，可参考
[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/)
文档。