完成 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 在混合環境中更智慧化，在混合環境中，叢集中的節點可以同時在公有雲和私有雲上運行，以及為外部供應商的開發人員提供更好的工具和框架，以簡化和精簡他們的整合工作。
隨著所有正在規劃的新功能、工具和框架，SIG Cloud Provider 並未忘記等式的另一面：測試。SIG 未來活動的另一個重點領域是改進雲端控制器測試，以納入更多供應商。這項工作的最終目標是建立一個測試框架，該框架將盡可能多地納入供應商，以便我們為 Kubernetes 社群提供對其 Kubernetes 環境的最高程度的信心。
如果您使用的 Kubernetes 版本低於 v1.29，且尚未遷移到外部雲端供應商，我們建議您查看我們之前的部落格文章 Kubernetes 1.29：雲端供應商整合現在是獨立組件。它提供了關於我們所做變更的詳細資訊，並提供了關於如何遷移到外部供應商的指南。從 v1.31 版本開始，樹狀結構內雲端供應商將被永久停用並從核心 Kubernetes 組件中移除。
如果您有興趣貢獻，請加入我們的 雙週 SIG 會議！