concepts/architecture/cloud-controller/
雲控制器管理器（ccm）的概念（不要與二進位制程式碼混淆）最初是為了允許特定於雲的供應商程式碼和kubernetes核心相互獨立地發展而建立的。雲控制器管理器與其他主元件（如kubernetes控制器管理器、api伺服器和排程器）一起執行。它也可以作為kubernetes外掛啟動，在這種情況下，它執行在kubernetes之上。
雲控制器管理器的設計基於一種外掛機制，該機制允許新的雲提供商使用外掛輕鬆地與kubernetes整合。有計劃在kubernetes上加入新的雲提供商，並將雲提供商從舊模型遷移到新的ccm模型。
本文討論了雲控制器管理器背後的概念，並詳細介紹了其相關功能。
下面是沒有云控制器管理器的kubernetes叢集的架構：
- Design
- Components of the CCM
- Functions of the CCM
- Plugin mechanism
- Authorization
- Vendor Implementations
- Cluster Administration
Design
在上圖中，kubernetes和雲提供商通過幾個不同的元件進行整合：
- Kubelet
- Kubernetes controller manager
- Kubernetes API server
ccm整合了前三個元件中所有與雲相關的邏輯，以建立與雲的單點整合。帶有ccm的新體系結構如下所示：
Components of the CCM
ccm分離了kubernetes控制器管理器（kcm）的一些功能，並將其作為單獨的程式執行。具體來說，它分離了kcm中依賴於雲的控制器。KCM具有以下依賴於雲的控制器迴圈：
- Node controller
- Volume controller
- Route controller
- Service controller
在版本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.Volume 控制器被故意選擇為不屬於ccm的一部分。由於所涉及的複雜性以及現有的抽象特定於供應商的卷邏輯的工作，決定不將卷控制器移動到ccm。
使用ccm支援卷的最初計劃是使用flex捲來支援可插入卷。然而，一個被稱為csi的競爭對手正在計劃取代flex。
考慮到這些動態，我們決定在CSI準備就緒之前採取中間的權宜之計。
Functions of the CCM
ccm從依賴於雲提供程式的kubernetes元件繼承其功能。本節是基於這些元件構建的。
1. Kubernetes controller manager
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節點控制器負責通過從雲提供程式獲取有關叢集中執行的節點的資訊來初始化節點。節點控制器執行以下功能：
- Initialize a node with cloud specific zone/region labels. 使用雲特定的區域/區域標籤初始化節點。
- Initialize a node with cloud specific instance details, for example, type and size. 使用特定於雲的例項詳細資訊（例如，型別和大小）初始化節點。
- Obtain the node’s network addresses and hostname. 獲取節點的網路地址和主機名。
- 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.如果某個節點變得無響應，請檢查雲以檢視該節點是否已從雲中刪除。如果該節點已從雲中刪除，請刪除kubernetes節點物件。
Route 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 Engineclusters.路由控制器負責在雲中適當地配置路由，以便kubernetes叢集中不同節點上的容器可以相互通訊。路由控制器僅適用於google計算引擎叢集。
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.服務控制器負責監聽服務建立、更新和刪除事件。基於kubernetes中服務的當前狀態，它配置雲負載平衡器（如elb、google lb或oracle cloud infrastructure lb）以反映kubernetes中服務的狀態。此外，它還確保雲負載平衡器的服務後端是最新的。
2. Kubelet
節點控制器包含kubelet的雲相關功能。在引入ccm之前，kubelet負責使用特定於雲的詳細資訊（如ip地址、區域/區域標籤和例項型別資訊）初始化節點。ccm的引入將此初始化操作從kubelet移到ccm中。
在這個新模型中，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.雲控制器管理器使用go介面允許插入來自任何雲的實現。具體來說，它使用[此處]定義的cloud provider介面 here.
上面強調的四個共享控制器的實現，以及一些腳手架和共享cloudprovider介面，將保留在kubernetes核心中。特定於雲提供商的實現將在核心之外構建，並實現核心中定義的介面。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.
有關開發外掛的更多資訊，請參閱開發雲控制器管理器.
Authorization
本節分解ccm執行其操作所需的對各種api物件的訪問。
Node Controller
節點控制器僅適用於節點物件。它需要完全訪問權才能獲取、列出、建立、更新、修補、監視和刪除節點物件。
v1/Node:
- Get
- List
- Create
- Update
- Patch
- Watch
- Delete
Route controller
路由控制器監聽節點物件的建立並適當地配置路由。它需要訪問節點物件。
v1/Node:
- Get
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 for the Services, it requires access to create, list, get, watch, and update.要為服務設定終結點，需要訪問create、list、get、watch和update。
v1/Service:
- List
- Get
- Watch
- Patch
- Update
Others
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:
- Create
- Patch
- Update
v1/ServiceAccount:
- Create
The RBAC ClusterRole for the CCM looks like this:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cloud-controller-manager
rules:
- apiGroups:
- ""
resources:
- events
verbs:
- create
- patch
- update
- apiGroups:
- ""
resources:
- nodes
verbs:
- '*'
- apiGroups:
- ""
resources:
- nodes/status
verbs:
- patch
- apiGroups:
- ""
resources:
- services
verbs:
- list
- patch
- update
- watch
- apiGroups:
- ""
resources:
- serviceaccounts
verbs:
- create
- apiGroups:
- ""
resources:
- persistentvolumes
verbs:
- get
- list
- update
- watch
- apiGroups:
- ""
resources:
- endpoints
verbs:
- create
- get
- list
- watch
- updateVendor Implementations 不同服務商的實現
The following cloud providers have implemented CCMs:
Cluster Administration
這裡提供了配置和執行ccm的完整說明 here.
Feedback
Was this page helpful?