眾人拾柴火焰高，共建 Kubernetes

編者按：這篇帖子是關於 Kubernetes 1.8 新特性的系列深度文章的一部分，由 Microsoft 的 Jaice Singer DuMars 撰寫。

每當我們釋出新版本的 Kubernetes 時，看到社群對所有辛勤工作的回應都令人著迷。關於新功能或增強功能的部落格像春天裡的野花一樣遍佈網路。講座、影片、網路研討會和演示也緊隨其後。一旦社群似乎消化了所有這些，我們就會轉身在其中新增更多內容。能成為這個專案的一部分，甚至更重要的是，成為這場運動的一部分，這是一個激動人心的時刻。它不再僅僅是軟體了。

當情況為我領導 1.8 版本開啟大門時，儘管我有點緊張，但我還是答應了。在與另一位社群成員的私人談話中，他們向我保證，“有條不紊、跟進並知道何時尋求幫助”是成功的領導者的關鍵。那時我知道我能做到——所以我做到了。

從那時起，我被一張社群的拼布被子包裹著，它總是在恰當的時刻神奇地出現。社群對質量、一致性和責任的承諾和真誠熱情構成了釋出本身賴以形成的基石。

儘管起步較晚，1.8 釋出團隊仍表現出令人難以置信的凝聚力。我們甚至以幽默、勤奮和真誠的好奇心處理最困難的情況。我領導大型團隊的經驗對我很有幫助，並突顯了這次釋出的另一個不同之處：對我來說，專注於領導力比深入技術細節解決每個問題更有價值。

此外，Slack 中的表情符號的提升力量不可低估。

Kubernetes 專案正在經歷一個重要的轉折點。如果您曾乘坐過“創業過山車”，這是一個熟悉的故事。您想出了一個瘋狂的想法，它可能會成功。您構建它，獲得關注，然後慢慢地咯噠咯噠地爬上第一個大山坡。從山頂俯瞰，令人眩暈，因為您將無數的生命時間投入到完全未知的事物中。一旦您越過那個山坡，一切都改變了。驚人的加速定義或摧毀了已經建立起來的一切。

根據我的經驗，那個零重力點是公司（或在這種情況下，專案）中的每個人都必須認真對待不僅要構建東西，還要維護它的時候。如果沒有維護承諾，事情會很快出錯。從像溫徹斯特神秘屋一樣的程式碼庫到生產實現崩潰的流行病，儘管表面上成功，但混亂的火熱下墜會很快發生。值得慶幸的是，Kubernetes 社群似乎在每次釋出中都越來越成功地駕馭著我們的增長過山車。

隨著軟體初創公司的成熟，勞動分工的增加反映了一種自然的演變。爆炸性的採用意味著全職的安全、運營、質量、文件和專案管理人員變得必要，以提供穩定性、可靠性和可擴充套件性。此外，當有意的架構變得必要以確保長期的一致性時，您就會知道事情正在變得嚴肅。

Kubernetes 也遵循了類似的道路。在沒有公司部門或特定技能團隊的情況下，圍繞儲存、網路、API 機制、應用程式和操作生命週期等核心專案需求，自發形成了特殊興趣小組 (SIG)。隨著 SIG 的增多，Kubernetes 治理模型圍繞它們逐漸形成，為程式碼所有權和共同責任提供了框架。SIG 還有助於確保社群的可持續性，因為成功往往更多地取決於人而不是程式碼。

在六月份的 Kubernetes 領導力峰會上，一項擬議的 SIG 架構以全票透過獲得批准，這突顯了以某種方式滲透到每次對話中的穩定性主題。填補主要功能空白的日子似乎已經結束，取而代之的是一個功能深度的新時代。

另一個變化是，從專案層面的釋出“功能主題”轉向在幾次釋出過程中逐步交付的 SIG 層面倡議。這是一個重要的轉變：SIG 有其使命，它們交付的一切最終都應服務於該使命。作為一個社群，我們需要提供便利和支援，以便 SIG 能夠在最小的開銷和最大的透明度下完成最佳工作。

明智的是，社群也看到了提供安全創新機制的機會，這些機制越來越不依賴於 kubernetes/kubernetes 中的程式碼。這反過來又為實驗創造了一個蓬勃發展的棲息地，而不會阻礙整體速度。該專案還可以解決在過山車初始階段產生的技術債務。然而，新的創新機制在定義什麼是 Kubernetes 和什麼不是 Kubernetes 方面提出了架構挑戰。SIG 架構解決了定義 Kubernetes 邊界的挑戰。這是一項持續改進的進行中的工作。

這在個人層面可能有點讓人不知所措。實際上，它與任何其他成功的初創公司並沒有太大不同，除了權力不是來自傳統的組織結構圖。它來自 SIG、社群技術領導者、新成立的指導委員會，最終是您。

Kubernetes 釋出過程提供了一個特殊的機會，可以瞭解使該專案運轉的一切。我看到了什麼：人們齊心協力，盡力而為，為所有踏上雲原生之旅的人們服務。

• ←上一篇
• 下一篇→