本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
聚焦 SIG Cloud Provider
開發人員使用 Kubernetes 相關服務最流行的方式之一是透過雲提供商，但你是否想過雲提供商是如何做到的？Kubernetes 與各種雲提供商整合的整個過程是如何發生的？為了回答這個問題，讓我們聚焦於 SIG Cloud Provider。
SIG Cloud Provider 致力於在 Kubernetes 和各種雲提供商之間建立無縫整合。他們的使命是什麼？為所有人保持 Kubernetes 生態系統的公平和開放。透過設定明確的標準和要求，他們確保每個雲提供商都能與 Kubernetes 良好協作。他們負責配置叢集元件以啟用雲提供商整合。
在 SIG Spotlight 系列的這篇部落格中，Arujjwal Negi 採訪了 Michael McCune (Red Hat)，也被稱為 elmiko，他是 SIG Cloud Provider 的聯合主席，為我們深入介紹了這個小組的工作情況。
引言
Arujjwal：讓我們從認識你開始吧。你能簡單介紹一下自己以及你是如何接觸到 Kubernetes 的嗎？
Michael：大家好，我是 Michael McCune，社群裡大多數人都用我的暱稱 elmiko 稱呼我。我從事軟體開發已經很長時間了（我剛開始工作時 Windows 3.1 還很流行！），而且我職業生涯的大部分時間都與開源軟體打交道。我最初接觸 Kubernetes 是作為一名機器學習和資料科學應用的開發者；當時我所在的團隊正在建立教程和示例，以演示如何在 Kubernetes 上使用像 Apache Spark 這樣的技術。也就是說，我對分散式系統感興趣很多年了，當有機會加入一個直接從事 Kubernetes 工作的團隊時，我毫不猶豫地抓住了它！
運作和工作
Arujjwal：你能給我們介紹一下 SIG Cloud Provider 做什麼以及它是如何運作的嗎？
Michael：SIG Cloud Provider 的成立是為了幫助確保 Kubernetes 為所有基礎設施提供商提供一箇中立的整合點。我們迄今為止最大的任務是將樹內（in-tree）雲控制器提取和遷移到樹外（out-of-tree）元件。該 SIG 定期開會討論進展和即將到來的任務，並回答出現的問題和錯誤。此外，我們還充當雲提供商子專案的協調點，例如雲提供商框架、特定的雲控制器實現以及 Konnectivity 代理專案。
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 程式碼樹中，因此產生了“樹內（in-tree）”這個術語（可以檢視這篇關於該主題的文章瞭解更多資訊）。在主 Kubernetes 原始碼樹中維護特定於提供商的程式碼的活動被社群認為是不受歡迎的。社群的決定促使了提取和遷移專案的建立，以移除“樹內”雲控制器，轉而支援“樹外（out-of-tree）”元件。
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，請嘗試參加他們的會議，連結在這裡。