聚焦 SIG 雲端供應商
開發人員使用 Kubernetes 相關服務最常見的方式之一是透過雲端供應商，但您是否曾想過雲端供應商是如何做到這一點的？Kubernetes 與各種雲端供應商整合的整個過程是如何發生的？為了回答這個問題，讓我們聚焦在 SIG Cloud Provider。
SIG Cloud Provider 致力於在 Kubernetes 和各種雲端供應商之間建立無縫整合。他們的使命？保持 Kubernetes 生態系統對所有人公平開放。透過設定明確的標準和要求，他們確保每個雲端供應商都能與 Kubernetes 良好協同運作。配置叢集組件以啟用雲端供應商整合是他們的責任。
在本 SIG Spotlight 系列的部落格中，Arujjwal Negi 採訪了 SIG Cloud Provider 的聯合主席 Michael McCune (Red Hat)，又名 elmiko，讓我們深入了解這個團隊的運作方式。
簡介
Arujjwal：讓我們從認識您開始。您可以簡單介紹一下自己以及您是如何接觸 Kubernetes 的嗎？
Michael：嗨，我是 Michael McCune，社群中的大多數人都用我的代號 elmiko 稱呼我。我擔任軟體開發人員已經很長一段時間了（當我剛開始時，Windows 3.1 很流行！），而且我的大部分職業生涯都投入在開源軟體上。我最初接觸 Kubernetes 是作為機器學習和資料科學應用程式的開發人員；當時我所在的團隊正在建立教學課程和範例，以示範如何在 Kubernetes 上使用 Apache Spark 等技術。話雖如此，我對分散式系統已經很感興趣多年，當有機會加入直接從事 Kubernetes 工作的團隊時，我立刻抓住了這個機會！
運作與工作方式
Arujjwal：您可以深入介紹一下 SIG Cloud Provider 的職責以及其運作方式嗎？
Michael：SIG Cloud Provider 的成立是為了協助確保 Kubernetes 為所有基礎架構供應商提供中立的整合點。我們迄今為止最大的任務是將樹內雲端控制器提取和遷移到樹外組件。SIG 定期開會討論進度和即將到來的任務，並回答出現的問題和錯誤。此外，我們還充當雲端供應商子專案的協調點，例如雲端供應商框架、特定雲端控制器實作和 Konnectivity proxy project。
Arujjwal：在瀏覽過專案 README 後，我了解到 SIG Cloud Provider 負責 Kubernetes 與雲端供應商的整合。整個過程是如何進行的呢？
Michael：執行 Kubernetes 最常見的方式之一是將其部署到雲端環境（AWS、Azure、GCP 等）。通常，雲端基礎架構具有增強 Kubernetes 效能的功能，例如，為 Service 物件提供彈性負載平衡。為了確保 Kubernetes 可以持續使用雲端特定服務，Kubernetes 社群建立了雲端控制器來解決這些整合點。雲端供應商可以透過使用 SIG 維護的框架或遵循 Kubernetes 程式碼和文件中定義的 API 指南來建立自己的控制器。我想指出的一點是，SIG Cloud Provider 不處理 Kubernetes 叢集中節點的生命週期；對於這些類型的主題，SIG Cluster Lifecycle 和 Cluster API 專案是更合適的場所。
重要子專案
Arujjwal：這個 SIG 中有很多子專案。您可以重點介紹一些最重要的子專案以及它們的職責嗎？
Michael：我認為目前最重要的兩個子專案是 雲端供應商框架 和 提取/遷移專案。雲端供應商框架是一個通用函式庫，旨在協助基礎架構整合商為其基礎架構建立雲端控制器。這個專案通常是新加入 SIG 的人員的起點。提取和遷移專案是另一個大型子專案，也是該框架存在的主要原因之一。一點歷史背景可能有助於進一步解釋：長期以來，Kubernetes 需要與底層基礎架構進行一些整合，不一定是要新增功能，而是要意識到雲端事件，例如實例終止。雲端供應商整合已建置到 Kubernetes 程式碼樹中，因此創造了「樹內」這個術語（請查看這篇關於該主題的 文章 以取得更多資訊）。在主要的 Kubernetes 原始碼樹中維護供應商特定程式碼的活動被社群認為是不理想的。社群的決定啟發了提取和遷移專案的創建，以移除「樹內」雲端控制器，轉而支持「樹外」組件。
Arujjwal：是什麼讓 [雲端供應商框架] 成為一個良好的起點？它是否有持續良好的初學者工作？是什麼類型的？
Michael：我認為雲端供應商框架是一個良好的起點，因為它編碼了社群對於雲端控制器管理器的首選實務，因此，它將使新手能夠強烈理解管理器如何運作以及做什麼。遺憾的是，這個組件沒有持續不斷的初學者工作；部分原因是框架和個別供應商的成熟性。對於有興趣更深入參與的人來說，具備一些 Go 語言 知識是好的，並且了解至少一個雲端 API（例如 AWS、Azure、GCP）的運作方式也很有幫助。以我個人而言，成為 SIG Cloud Provider 的新手可能具有挑戰性，因為圍繞這個專案的大多數程式碼都直接處理特定的雲端供應商互動。我給想要在雲端供應商方面做更多工作的人的最佳建議是，增加您對一兩個雲端 API 的熟悉度，然後在這些雲端的控制器管理器上尋找未解決的問題，並始終盡可能多地與其他貢獻者溝通。
成就
Arujjwal：您可以分享一些您為 SIG 感到驕傲的成就嗎？
Michael：自從我一年多前加入 SIG 以來，我們在推進提取和遷移子專案方面取得了很大的進展。我們已將定義 KEP 的狀態從 alpha 提升到 beta，並且越來越接近從 Kubernetes 原始碼樹中移除舊的供應商程式碼。我真的為看到我們社群成員的積極參與以及我們在提取方面取得的進展感到驕傲。我感覺在接下來的幾個版本中，我們將看到最終移除樹內雲端控制器以及子專案的完成。
給新貢獻者的建議
Arujjwal：對於新貢獻者，關於他們如何從 SIG Cloud Provider 開始，您有任何建議或忠告嗎？
Michael：依我來看，這是一個棘手的問題。SIG Cloud Provider 專注於在 Kubernetes 和底層基礎架構之間整合的程式碼片段。SIG 成員以官方身分代表雲端供應商是很常見的，但並非必要。我建議任何對 Kubernetes 這部分感興趣的人都應該參加 SIG 會議，以了解我們的運作方式，並研究雲端供應商框架專案。我們對未來的工作有一些有趣的構想，例如一個通用的測試框架，它將橫跨所有雲端供應商，並且對於任何希望擴大其 Kubernetes 參與度的人來說，這將是一個絕佳的機會。
Arujjwal：您是否正在尋找我們應該強調的任何特定技能？舉我們自己的 [SIG ContribEx] (https://github.com/kubernetes/community/blob/master/sig-contributor-experience/README.md) 為例：如果您是 Hugo 專家，我們隨時可以獲得 k8s.dev 的協助！
Michael：SIG 目前正在完成我們的提取和遷移過程的最後階段，但我們正在展望未來並開始規劃接下來的步驟。SIG 討論過的一個重要主題是測試。目前，我們沒有一組通用的通用測試，每個雲端供應商都可以執行這些測試，以確認其控制器管理器的行為。如果您是 Ginkgo 和 Kubetest 框架的專家，我們可能可以請您協助設計和實作新的測試。
對話到此結束。我希望這讓您對 SIG Cloud Provider 的目標和工作方式有所了解。這只是冰山一角。若要了解更多資訊並參與 SIG Cloud Provider，請嘗試參加他們的會議，連結請見此處。