社群協力打造 Kubernetes

編者註：這篇文章是關於 Kubernetes 1.8 新功能的系列深入文章的一部分，由來自微軟的 Jaice Singer DuMars 撰寫。

每次我們發布新版本的 Kubernetes 時，看到社群對所有投入的辛勤工作的回應，總是令人著迷。關於新功能或增強功能的部落格文章像春天的野花一樣在網路上湧現。演講、影片、線上研討會和演示也緊隨其後。社群似乎才剛消化完這一切，我們就轉過身來添加更多內容。成為這個專案，甚至更重要的是這股趨勢的一份子，真是令人興奮。這不再只是軟體而已。

當環境為我打開領導 1.8 版本發布的大門時，我簽署了協議，儘管內心有些忐忑。在與另一位社群成員的私下對話中，他們向我保證，「有條理、持續追蹤以及知道何時尋求幫助」是成為成功領導者的關鍵。那時我知道我可以做到——所以我做了。

從那時起，我就被社群的拼布被包裹著，它在恰好的時刻神奇地出現。社群對品質、一致性和責任感的承諾和真誠的熱情，形成了發布版本本身的基石，並從中雕琢而成。

儘管起步較晚，1.8 版本團隊證明了其令人難以置信的凝聚力。即使面對最困難的情況，我們也以幽默、勤奮和真誠的好奇心來應對。我領導大型團隊的經驗對我很有幫助，並突顯了此版本的另一個不同之處：對我來說，專注於領導力比深入技術細節來解決每個問題更有價值。

此外，不可高估 Slack 中表情符號的鼓舞力量。

Kubernetes 專案正在經歷一個重要的轉折點。如果您曾經搭乘過「新創公司雲霄飛車」，這是一個熟悉的故事。您提出一個瘋狂到可能成功的想法。您建置它、獲得吸引力，然後慢慢地喀嚓喀嚓地爬上第一個大坡。從山頂看到的景色令人眼花撩亂，因為您已經將無數小時的生命投入到完全未知的事物中。一旦您越過山頂，一切都會改變。飛速加速定義或摧毀了已建置的成果。

以我的經驗來看，那個零重力點是公司（或在這種情況下，專案）中的每個人都必須認真對待的不僅僅是建置東西，還有維護它的地方。如果沒有對維護的承諾，事情很快就會出錯。從像溫徹斯特鬼屋一樣的程式碼庫，到生產環境實作崩潰的流行病，儘管表面上看起來很成功，但迅速墜入混亂是可能發生的。值得慶幸的是，Kubernetes 社群似乎在每次發布時都越來越成功地乘坐我們的成長雲霄飛車。

隨著軟體新創公司成熟，勞動分工日益細化反映了自然演變。爆炸式採用意味著需要全職的安全、營運、品質、文件和專案管理人員，以提供穩定性、可靠性和可擴展性。此外，當有意的架構變得必要以確保長期一致性時，您就知道事情變得嚴重了。

Kubernetes 也遵循了類似的路徑。在缺乏公司部門或特定技能團隊的情況下，特別興趣小組 (SIG) 已圍繞核心專案需求有機地形成，例如儲存、網路、API 機制、應用程式和運作生命週期。隨著 SIG 的激增，Kubernetes 治理模型已圍繞它們而具體化，為程式碼所有權和共同責任提供了框架。SIG 也有助於確保社群的可持續性，因為成功通常更多的是關於人而不是程式碼。

在 Kubernetes 領導力峰會上，一項擬議的 SIG 架構獲得一致投票通過，突顯了一個穩定性主題，該主題似乎瀰漫在以各種方式進行的每次對話中。填補主要功能缺口的時代似乎已經結束，取而代之的是功能深度的新時代。

另一個變化是從專案級發布「功能主題」轉向 SIG 級別的倡議，這些倡議在多次發布中分批交付。這是一個重要的轉變：SIG 有使命，他們交付的一切最終都應該為此服務。作為一個社群，我們需要提供促進和支持，以便授權 SIG 以最小的開銷和最大的透明度盡力完成他們的工作。

明智的是，社群也發現了為創新提供安全機制的機會，這些機制越來越少地依賴 kubernetes/kubernetes 中的程式碼。這反過來為實驗創造了一個蓬勃發展的環境，而不會影響整體速度。該專案還可以解決在最初乘坐雲霄飛車上升過程中產生的技術債。然而，新的創新機制在定義 Kubernetes 的範圍方面提出了架構挑戰。SIG 架構解決了定義 Kubernetes 邊界的挑戰。這是一項不斷改進的進行中工作。

這在個人層面上可能有點讓人感到壓力。但實際上，它與任何其他成功的新創公司沒有太大區別，除了權威不是來自傳統的組織結構圖這一事實。它來自 SIG、社群技術領導者、新成立的指導委員會，以及最終的您。

Kubernetes 發布流程提供了一個特殊的機會，讓您了解使這個專案運作的所有要素。我會告訴您我所看到的：人們共同努力，盡其所能，為所有踏上雲原生之旅的人服務。

• ←上一篇
下一篇→