本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
完成 Kubernetes 歷史上最大規模的遷移
早在 Kubernetes v1.7 時，Kubernetes 專案就設定了移除內建雲驅動整合的宏偉目標 (KEP-2395)。儘管這些整合在 Kubernetes 早期發展和壯大過程中起到了關鍵作用，但移除它們主要出於兩個關鍵因素：一是在數百萬行 Go 程式碼中為每個雲廠商維護原生支援的複雜性日益增加；二是希望將 Kubernetes 打造為一個真正廠商中立的平臺。
經過多個版本的努力，我們激動地宣佈，所有云驅動整合已成功從 Kubernetes 核心倉庫遷移到外部外掛。除了實現我們的初步目標外，我們還透過移除約 150 萬行程式碼，並將核心元件的二進位制檔案大小減少約 40%，顯著精簡了 Kubernetes。
這次遷移是一項複雜而長期的工作，因為它涉及眾多元件和關鍵程式碼路徑，這些都依賴於最初五個雲廠商（Google Cloud、AWS、Azure、OpenStack 和 vSphere）的內建整合。為了成功完成這次遷移，我們必須從頭構建四個新的子系統：
每個子系統對於實現與內建功能完全對等都至關重要，並且需要經過數個版本的迭代，才能使每個子系統達到生產就緒（GA）級別的成熟度，並提供安全可靠的遷移路徑。以下是每個子系統的詳細介紹。
雲控制器管理器
雲控制器管理器是這項工作中引入的第一個外部元件，取代了 kube-controller-manager 和 kubelet 中直接與雲 API 互動的功能。這個關鍵元件負責初始化節點，透過應用元資料標籤來表明節點所在的雲區域和可用區，以及只有雲廠商才知道的 IP 地址。此外，它還執行服務控制器，負責為 LoadBalancer 型別的服務提供雲負載均衡器。
要了解更多資訊，請閱讀 Kubernetes 文件中的雲控制器管理器。
API 伺服器網路代理
API 伺服器網路代理專案於 2018 年與 SIG API Machinery 合作啟動，旨在取代 kube-apiserver 中的 SSH 隧道功能。該隧道曾用於安全地代理 Kubernetes 控制平面和節點之間的流量，但它嚴重依賴於嵌入在 kube-apiserver 中的廠商特定的實現細節來建立這些 SSH 隧道。
現在，API 伺服器網路代理是 kube-apiserver 中一個達到生產就緒（GA）級別的擴充套件點。它提供了一個通用的代理機制，可以透過一個安全的代理將流量從 API 伺服器路由到節點，從而消除了 API 伺服器需要了解其執行在哪家特定雲廠商上的需求。該專案還引入了 Konnectivity 專案，該專案在生產環境中的採用率越來越高。
你可以從其 README 中瞭解更多關於 API 伺服器網路代理的資訊。
Kubelet 的憑證提供程式外掛
Kubelet 憑證提供程式外掛的開發是為了取代 kubelet 內建的動態獲取託管在 Google Cloud、AWS 或 Azure 上的映象倉庫憑證的功能。舊的功能很方便，因為它允許 kubelet 無縫地檢索用於從 GCR、ECR 或 ACR 拉取映象的短期令牌。然而，與 Kubernetes 的其他領域一樣，支援這項功能需要 kubelet 具備對不同雲環境和 API 的特定了解。
憑證提供程式外掛機制於 2019 年引入，為 kubelet 提供了一個通用的擴充套件點，可以執行外掛二進位制檔案，動態地為託管在各種雲上的映象提供憑證。這種可擴充套件性將 kubelet 獲取短期令牌的能力擴充套件到了最初的三家雲廠商之外。
要了解更多資訊，請閱讀用於認證映象拉取的 kubelet 憑證提供程式。
儲存外掛從樹內遷移到 CSI
容器儲存介面（CSI）是一個用於在 Kubernetes 和其他容器編排器中管理塊儲存和檔案儲存系統的控制平面標準，於 1.13 版本達到生產就緒（GA）。它旨在用可以在 Kubernetes 叢集內作為 Pod 執行的驅動程式取代直接內置於 Kubernetes 的樹內卷外掛。這些驅動程式透過 Kubernetes API 與 kube-controller-manager 的儲存控制器通訊，並透過本地 gRPC 端點與 kubelet 通訊。現在，所有主流雲和儲存供應商都提供了超過 100 種 CSI 驅動程式，使得在 Kubernetes 中執行有狀態的工作負載成為現實。
然而，如何處理所有現有的樹內卷 API 使用者仍然是一個重大挑戰。為了保持 API 的向後相容性，我們在控制器中構建了一個 API 轉換層，它將樹內卷 API 轉換為等效的 CSI API。這使我們能夠將所有儲存操作重定向到 CSI 驅動程式，為我們移除內建卷外掛的程式碼而不移除 API 鋪平了道路。
你可以在Kubernetes 樹內捲到 CSI 卷的遷移進入 Beta 階段中瞭解更多關於樹記憶體儲遷移的資訊。
接下來是什麼？
這次遷移是 SIG Cloud Provider 過去幾年的主要工作重點。隨著這一重要里程碑的實現，我們將把精力轉向探索新的創新方式，利用我們多年來構建的外部子系統，讓 Kubernetes 更好地與雲廠商整合。這包括讓 Kubernetes 在混合環境中更加智慧，其中叢集中的節點可以同時執行在公有云和私有云上，以及為外部提供商的開發者提供更好的工具和框架，以簡化和 streamlining 他們的整合工作。
隨著所有新功能、工具和框架的規劃，SIG Cloud Provider 並未忘記問題的另一面：測試。SIG 未來活動的另一個重點是改進雲控制器測試，以包含更多的提供商。這項工作的最終目標是建立一個包含儘可能多提供商的測試框架，以便我們為 Kubernetes 社群提供對其 Kubernetes 環境最高水平的信心。
如果你使用的 Kubernetes 版本低於 v1.29 並且尚未遷移到外部雲驅動，我們建議你查閱我們之前的博文Kubernetes 1.29：雲驅動整合現已分離為獨立元件。該文詳細介紹了我們所做的更改，並提供瞭如何遷移到外部驅動的指導。從 v1.31 開始，樹內雲驅動將被永久停用並從 Kubernetes 核心元件中移除。
如果你有興趣貢獻，歡迎加入我們每兩週一次的 SIG 會議！