介紹適用於 Yandex.Cloud 的 Kubernetes CCM（雲端控制器管理器）

延續最近的 CSI驅動程式發布 對於 Yandex.Cloud，我們正在為此雲端發布另一個開源專案 - 雲端控制器管理器。 CCM 不僅對於整個叢集是必需的，對於 CSI 驅動程式本身也是如此。 有關其目的和一些實現功能的詳細資訊正在討論中。

介紹

為什麼是這樣？

促使我們為 Yandex.Cloud 開發 CCM 的動機與中已經描述的完全一致 公告 CSI 驅動程式。 我們維護來自不同雲端提供者的許多 Kubernetes 集群，為此我們使用單一工具。 它「繞過」這些提供者的託管解決方案，實現了許多便利。 是的，我們有一個相當具體的案例和需求，但因此而創建的開發可能對其他使用者有用。

CCM到底是什麼？

通常我們會為集群準備周圍的環境 從外面 - 例如，使用 Terraform。 但有時需要管理周遭的雲端環境 來自集群。 提供了這種可能性，實現的正是它 CCM.

具體來說，Cloud Controller Manager 提供五種主要的互動類型：

1. 實例 – 在 Kubernetes 中實作節點物件之間的 1:1 關係（Node）和雲端提供者中的虛擬機器。 為此我們：
   • 填寫字段 spec.providerID 在物件中 Node。 例如，對於 OpenStack CCM，該欄位具有以下格式： openstack:///d58a78bf-21b0-4682-9dc6-2132406d2bb0。 可以看到該物件的雲端提供者的名稱和伺服器（OpenStack中的虛擬機器）的唯一UUID；
   • 補充 nodeInfo 在物件中 Node 有關虛擬機器的資訊。 例如，我們在AWS中指定實例類型；
   • 我們檢查雲端中是否存在虛擬機器。 例如，如果一個對象 Node 進入一種狀態 NotReady，您可以透過以下方式檢查虛擬機器是否存在於雲端提供者中 providerID。 如果不存在，則刪除該對象 Node，否則它將永遠保留在集群中；
2. 區 – 設定物件的故障域 Node，以便調度器可以根據雲端提供者中的地域和可用區為Pod選擇節點；
3. 負載平衡器 – 建立物件時 Service 與類型 LoadBalancer 建立一種平衡器，將流量從外部引導到叢集節點。 例如，在 Yandex.Cloud 中您可以使用 NetworkLoadBalancer и TargetGroup 出於這些目的；
4. 路線 – 在節點之間建立網絡，因為根據 Kubernetes 的要求，每個 Pod 必須有自己的 IP 位址，並且能夠存取任何其他 Pod。 為此，您可以使用覆蓋網路（VXLAN、GENEVE）或直接在雲端提供者的虛擬網路中設定路由表：

   

5. 體積 – 允許使用 PVC 和 SC 動態排序 PV。 最初，此功能是 CCM 的一部分，但由於其非常複雜，它被轉移到一個單獨的項目，即容器儲存介面 (CSI)。 我們不只一次談論CSI писали 而且，正如已經提到的，甚至 獲釋 CSI 驅動程式。

此前，所有與雲端互動的程式碼都位於 Kubernetes 專案的主 Git 儲存庫中，位址為 k8s.io/kubernetes/pkg/cloudprovider/providers，但由於使用大型程式碼庫的不便，他們決定放棄這一點。 所有舊的實作都已移至 單獨的儲存庫。 為了方便進一步的支援和開發，所有通用元件也移至 單獨的儲存庫.

與 CSI 一樣，許多大型雲端供應商已經設計了他們的 CCM 以利用 Kubernetes 上的雲端。 如果供應商沒有CCM，但所有必要的功能都可以透過API取得，那麼您可以自行實作CCM。

要編寫自己的 CCM 實現，只需實現 所需的 Go 接口.

И 這就是我們得到的.

履行

你是怎麼到這個地步的

我們開始開發（或更確切地說，甚至使用） 準備好（！）CCM 一年前的 Yandex.Cloud。

然而，在這個實現中我們遺漏了：

• 透過 JWT IAM 令牌進行身份驗證；
• 服務控制器支援。

與作者一致 （德利辛） 在 Telegram 中，我們分叉了 yandex-cloud-controller-manager 並添加了缺少的功能。

主要特點

目前，CCM支援以下介面：

• 實例;
• 區;
• 負載平衡器.

將來，當Yandex.Cloud開始使用高級VPC功能時，我們將新增一個介面 路線.

LoadBalancer 是主要挑戰

最初，我們嘗試像其他 CCM 實作一樣建立一對 LoadBalancer и TargetGroup 對於每個 Service 與類型 LoadBalancer。 然而，Yandex.Cloud 發現了一個有趣的限制：你不能使用 TargetGroups 與相交 Targets （一對 SubnetID - IpAddress).

因此，在建立的 CCM 內部，會啟動一個控制器，當物件發生變化時，該控制器將啟動 Node 收集有關每個虛擬機器上所有介面的信息，根據其所屬的特定群組對它們進行分組 NetworkID, 創建者 TargetGroup 上 NetworkID，並且還監視相關性。 隨後，在建立物件時 Service 與類型 LoadBalanacer 我們只需附加一個預先創建的 TargetGroup 到新的 NetworkLoadBalanacer'是。

如何開始使用它？

CCM 支援 Kubernetes 1.15 及更高版本。 在集群中，要使其工作，需要標誌 --cloud-provider=external 被設定為 true 對於 kube-apiserver、kube-controller-manager、kube-scheduler 和所有 kubelet。

安裝本身的所有必要步驟均在 自述。 安裝歸結為從清單在 Kubernetes 中建立物件。

要使用 CCM，您還需要：

• 表明 在清單中的目錄識別碼（folder-id) Yandex.Cloud;
• 用於與 Yandex.Cloud API 互動的服務帳戶。 在宣言中 Secret 必要 傳輸授權金鑰 來自服務帳戶。 在文件中 描述，如何建立服務帳戶並取得金鑰。

我們將很高興收到您的回饋並 新問題如果您遇到任何問題！

結果

過去兩週，我們一直在 20 個 Kubernetes 集群中使用已實施的 CCM，並計劃在下個月將其數量擴大到 8 個。 我們目前不建議對大型且關鍵的 KXNUMXs 安裝使用 CCM。

與 CSI 的情況一樣，如果 Yandex 開發人員承擔該專案的開發和支持，我們將很高興 - 我們準備根據他們的要求轉移儲存庫，以便處理與我們更相關的任務。

聚苯乙烯

另請閱讀我們的博客：

• «我們在 Kubernetes 中為 Yandex.Cloud 開發 CSI 驅動程序的經驗“;
• «準備一個Kubernetes集群是不是簡單方便？ 宣布插件運營商“;
• «擴展和補充 Kubernetes（評論和視頻報告）“。

來源： www.habr.com