GSoC 2020 - 為叢集附加元件建構運算元

簡介

Google Summer of Code 是一項全球計畫，旨在向學生介紹開放原始碼。學生與開放原始碼組織配對，在夏季期間與他們合作三個月。

我的名字是 Somtochi Onyekwere，來自奈及利亞奧韋里聯邦科技大學，今年，我獲得了與 Kubernetes（在 CNCF 組織下）合作的機會，這讓我度過了一個美好的夏天，學習、貢獻並與社群互動。

具體來說，我致力於叢集附加元件：封裝所有事物！專案。該專案的重點是建置運算子，以更好地管理各種叢集附加元件，擴展用於建置這些運算子的工具，並使建立這些運算子的過程順利。

背景

Kubernetes 在過去幾年中取得了長足的進展，擁有蓬勃發展的社群和大量貢獻者。程式碼庫正逐漸從單體結構轉移，過去所有程式碼都位於 kubernetes/kubernetes 儲存庫中，現在則拆分為多個子專案。叢集附加元件的部分重點是使其中一些子專案以易於組裝、自我監控、自我修復且 Kubernetes 原生的方式協同工作。它使它們能夠無縫協同工作，而無需人為干預。

社群正在探索使用運算子作為一種機制，來監控叢集中的各種資源並妥善管理這些資源。除此之外，它還提供自我修復，並且是一種 Kubernetes 原生模式，可以編碼這些附加元件的最佳運作方式並妥善管理它們。

什麼是叢集附加元件？叢集附加元件是資源（如服務和部署）的集合，用於為 Kubernetes 叢集提供額外功能。它們的範圍從像 Kubernetes 儀表板（用於視覺化）這樣簡單的東西，到像 Calico（用於網路功能）這樣更複雜的東西。這些附加元件對於叢集中執行的不同應用程式以及叢集本身至關重要。附加元件運算子提供了一種更友善的方式來管理這些附加元件，並了解構成附加元件的各種資源的健康狀況和狀態。您可以在這篇文章中獲得更深入的概述。

運算子是具有自訂資源定義的自訂控制器，它們編碼特定於應用程式的知識，並用於管理複雜的有狀態應用程式。這是一種廣泛接受的模式。透過運算子管理附加元件，這些運算子編碼了附加元件的最佳運作方式的知識，在設定易於遵循和擴展的標準的同時，引入了許多優勢。這篇文章很好地解釋了運算子。

附加元件運算子可以解決許多問題，但它們也面臨著挑戰。cluster-addons 專案下的那些運算子缺少部分，並且仍然是概念驗證。為運算子產生 RBAC 組態很麻煩，有時運算子被賦予了過多的權限。運算子的可擴展性不是很強，因為它僅從本機檔案系統或 HTTP(s) 伺服器提取資訊清單，並且許多簡單的附加元件產生了相同的程式碼。我整個夏天都在致力於解決這些問題，以全新的眼光看待它們，並為已知和未知問題提出解決方案。

kubebuilder-declarative-pattern 的各種新增功能

kubebuilder-declarative-pattern（以下簡稱 KDP）儲存庫是位於 kubebuilder SDK 之上的附加元件特定工具的額外層，透過將實驗性的 --pattern=addon 標誌傳遞到 kubebuilder create 命令來啟用。它們共同為附加元件運算子建立基礎程式碼。在實習期間，我致力於 KDP 和叢集附加元件中的多項功能。

運算子版本檢查

為運算子啟用版本檢查有助於使升級/降級到不同版本的附加元件更安全，即使運算子具有複雜的邏輯也是如此。這是一種將附加元件版本與知道如何妥善管理它的運算子版本進行匹配的方法。大多數附加元件都有不同的版本，這些版本可能需要以不同的方式進行管理。此功能檢查自訂資源中是否有 addons.k8s.io/min-operator-version 註釋，該註釋聲明了管理版本所需的最低運算子版本，並與運算子的版本進行比較。如果運算子版本低於要求的最低版本，則運算子會暫停並顯示錯誤，告知使用者運算子的版本過低。這有助於確保為附加元件使用正確的運算子。

用於儲存資訊清單的 Git 儲存庫

以前，僅支援本機檔案目錄和 HTTPS 儲存庫來儲存資訊清單。讓附加元件運算子的建立者能夠將資訊清單儲存在 GitHub 儲存庫中，可以更快地進行開發和版本控制。啟動控制器時，您可以傳遞標誌來指定通道目錄的位置。通道目錄包含不同版本的資訊清單，控制器從此目錄中提取資訊清單並將其應用於叢集。在實習期間，我將其擴展為包含 Git 儲存庫。

暫時停用協調的註釋

協調迴圈確保所需狀態與實際狀態匹配，從而防止修改叢集中的物件。這使得難以實驗或調查叢集中可能出現的問題，因為所做的任何變更都會立即還原。我透過允許使用者在他們不希望控制器協調的資源上放置 addons.k8s.io/ignore 註釋來解決此問題。控制器檢查此註釋，並且不協調該物件。若要恢復協調，可以從資源中移除註釋。

kubebuilder-declarative-pattern 中的非結構化支援

我致力於開發的運算子之一是一種通用控制器，它可以管理多個不需要額外組態的叢集附加元件。為此，運算子不能使用特定類型，並且需要 kubebuilder-declarative-repo 支援使用 unstructured.Unstructured 類型。kubebuilder-declarative-pattern 中有各種功能無法處理此類型，並且如果傳入的物件不是 addonsv1alpha1.CommonObject 類型，則會傳回錯誤。這些功能已修改為同時處理 unstructured.Unstructured 和 addonsv1alpha.CommonObject。

工具和 CLI 程式

我也編寫了一些命令列程式，可用於簡化附加元件運算子的使用。它們中的大多數在附加元件運算子之外也有用途，因為它們試圖解決在使用 Kubernetes 時可能隨時出現的特定問題。我鼓勵您在有機會時查看它們！

RBAC 產生器

運算子最受關注的問題之一是 RBAC。您必須手動查看資訊清單，並為每個資源新增 RBAC 規則，因為它需要具有 RBAC 權限才能在叢集中執行時建立、取得、更新和刪除資訊清單中的資源。建置 RBAC 產生器 自動化了編寫 RBAC 角色和角色綁定的過程。RBAC 產生器的功能很簡單。它接受資訊清單的檔案名稱作為標誌。然後，它解析資訊清單並取得資源的 API 群組和資源名稱，並將其新增到角色中。如果解析了 --out 標誌，它會將角色和角色綁定輸出到 stdout 或檔案。

此外，該工具還允許您透過分離資訊清單中的叢集角色來分割 RBAC。這減輕了運算子權限過高的安全性問題，因為它需要擁有 clusterrole 擁有的所有權限。如果您想自行應用 clusterrole，並且不希望將這些權限授予運算子，您可以傳入 --supervisory 布林標誌，以便產生器不會將這些權限新增到角色中。CLI 程式位於此處。

Kubectl Ownerref

很難一眼看出哪些物件是由附加元件自訂資源建立的。此 kubectl 外掛程式透過顯示叢集中資源在其上擁有 ownerref 的所有物件來減輕這種痛苦。您只需將資源的種類和名稱作為引數傳遞給程式，它就會檢查叢集中的物件，並提供此類物件的種類、名稱和命名空間。透過傳入自訂資源的名稱和種類，它可以幫助您大致了解控制器正在協調的所有物件。CLI 程式位於此處。

附加元件運算子

若要充分了解附加元件運算子並變更其建立方式，您必須嘗試建立和使用它們。夏季的部分時間用於為一些流行的附加元件（如 Kubernetes 儀表板、Flannel、NodeLocalDNS 等）建置運算子。請查看 cluster-addons 儲存庫，以了解不同的附加元件運算子。在本節中，我將重點介紹一個與其他運算子略有不同的運算子。

通用控制器

通用控制器可以在不需要太多組態的附加元件之間共用。這最大限度地減少了叢集上的資源消耗，因為它減少了需要執行的控制器數量。此外，您可以直接使用通用控制器，而不是建置自己的運算子，並且每當您覺得自己的需求增加並且需要更複雜的運算子時，您可以隨時使用 kubebuilder 搭建程式碼，並從通用運算子停止的地方繼續。若要使用通用控制器，您可以使用此工具 (generic-addon) 產生 CustomResourceDefinition (CRD)。您傳入種類、群組和通道目錄的位置（它也可以是 Git 儲存庫！）。該工具會為您產生 - CRD、RBAC 資訊清單和兩個自訂資源。

流程如下

• 建立通用 CRD
• 使用 generic-addon 工具 產生所有需要的資訊清單。

此工具會建立

1. 附加元件的 CRD
2. CustomResourceDefinitions 的 RBAC 規則
3. 應用資訊清單的 RBAC 規則
4. 附加元件的自訂資源
5. 通用自訂資源

通用自訂資源如下所示

apiVersion: addons.x-k8s.io/v1alpha1
kind: Generic
metadata:
 	name: generic-sample
spec:
  objectKind:
  kind: NodeLocalDNS
  version: "v1alpha1"
  group: addons.x-k8s.io
channel: "../nodelocaldns/channels"

套用這些資訊清單，但請確保在 CR 之前套用 CRD。然後，在本機或叢集中執行通用控制器。

如果您有興趣建置運算子，請查看本指南。

相關連結

• 實習期間完成工作的詳細分解
• 附加元件運算子 (KEP)
• 原始 GSoC 問題
• 為 GSoC 提交的提案
• kubernetes-sigs/cluster-addons 的所有提交
• kubernetes-sigs/kubebuilder-declarative-pattern 的所有提交

進一步工作

在 GSoC 期間，叢集附加元件方面肯定完成了大量工作。但我們需要更多人建置運算子並在叢集中使用它們。我們需要在社群中更廣泛地採用。為您最喜歡的附加元件建置運算子，並告訴我們進展如何，以及您是否有任何問題。查看此README.md 以開始使用。

感謝

我真的要感謝我的導師 Justin Santa Barbara (Google) 和 Leigh Capili (Weaveworks)。我的實習之所以很棒，是因為他們很棒。他們為指導設定了黃金標準。他們平易近人，隨時可以消除任何困惑。我想我最喜歡的是他們不僅僅是佈置任務，而是我們公開討論了問題所在以及可以改進的地方。他們真的是最好的，我希望我能再次與他們合作！此外，我要非常感謝 Lubomir I. Ivanov 審閱這篇部落格文章！

結論

到目前為止，我學到了很多關於 Go、Kubernetes 內部結構和運算子的知識。最後，我想鼓勵人們為開放原始碼（尤其是 Kubernetes :)) 做出貢獻，無論您的經驗水平如何。對我來說，這是一次全面的體驗，我已經愛上了這個社群。這是一個很棒的倡議，也是學習和結識很棒的人的好方法。特別感謝 Google 組織此計畫。

如果您對叢集附加元件感興趣，並想了解更多關於附加元件運算子的資訊，歡迎加入我們在 Kubernetes #cluster-addons 上的 Slack 頻道。

Somtochi Onyekwere 是一位軟體工程師，熱愛為開放原始碼做出貢獻並探索雲原生解決方案。

• ←上一篇
下一篇→