押注 Kubernetes，一個 Red Hat 的視角

兩年前，紅帽在 Kubernetes 上下了重注。我們押注了一個簡單的想法：開源社群是構建應用編排未來的最佳場所，並且只有開源社群才能成功整合成功所需的多樣化能力。作為一名紅帽人，這個想法並非遙不可及——我們已經在許多社群成功應用過它，但也看到它失敗過，尤其是在廣泛的覆蓋範圍沒有堅實基礎支援的情況下。在 Kubernetes 1.0 釋出一週年，也就是 Kubernetes 專案首次開源提交兩年後，值得提出這個問題：

Kubernetes 是正確的選擇嗎？

軟體的成功取決於其使用者的成功——該軟體是否為他們帶來了新的機會或效率。在這方面，Kubernetes 超出了我們最瘋狂的夢想。我們知道有數百個 Kubernetes 的實際生產部署，包括透過紅帽支援多租戶的 OpenShift 發行版在企業中部署，在 Google Container Engine (GKE) 上部署，由一些全球最大的軟體公司執行的高度定製版本，以及透過教育、娛樂、初創企業和自制社群部署。這些部署者報告稱，交付時間縮短，應用生命週期標準化，資源利用率提高，以及應用程式更具彈性和健壯性。這僅僅是來自客戶或社群貢獻者的報告——如果現在有成千上萬的 Kubernetes 安裝管理著成千上萬個實際應用程式，我也不會感到驚訝。

我相信這種覆蓋範圍驗證了 Kubernetes 的核心願景：透過為分散式計算中的每個核心模式提供工具，構建一個適用於所有應用程式的平臺。這些模式包括：

• 簡單的複製型 Web 軟體
• 分散式負載均衡和服務發現
• 在容器中執行不可變映象
• 將相關軟體並置到 Pod 中
• 簡化網路附加儲存的使用
• 靈活而強大的資源排程
• 在服務工作負載旁邊執行批處理和計劃任務
• 管理和維護叢集軟體，如資料庫和訊息佇列

允許開發人員和運營商轉移到更高一級的抽象，就像它們使谷歌和技術生態系統中的其他公司能夠擴充套件到資料中心計算機及更遠一樣。從 Kubernetes 1.0 到 1.3，我們不斷提高平臺的強大性和靈活性，同時還改進了效能、可伸縮性、可靠性和可用性。Kubernetes 之上整合和工具的爆炸式增長進一步驗證了核心架構決策的可組合性，暴露開放靈活的 API，以及有意識地限制核心平臺並鼓勵擴充套件。

今天，Kubernetes 擁有開源生態系統中最大、最活躍的社群之一，擁有近千名貢獻者，是 GitHub 上任何單一倉庫專案中人工生成提交率最高的專案之一，有超過一千個圍繞 Kubernetes 的專案，以及同樣活躍的 Stack Overflow 和 Slack 頻道。紅帽很榮幸能作為 Google 之後 Kubernetes 最大的貢獻者之一，成為這個生態系統的一部分，每天都有更多的公司和個人加入我們。Kubernetes 的理念找到了肥沃的土壤，而你們，社群，提供了讓它成長的熱情和承諾。

那麼，我們押對寶了嗎？基於以上所有原因，以及數百個其他原因：是的。

下一步是什麼？

儘管我們對 Kubernetes 的成功感到高興，但現在還不是休息的時候！雖然我們希望在 Kubernetes 中構建更多功能和改進，但我認為普遍的共識是，我們希望專注於唯一重要的長期目標——圍繞 Kubernetes 建立一個健康、成功和蓬勃發展的技術社群。正如約翰·F·肯尼迪可能說過的那樣： 

> 不要問你的社群能為你做什麼，而要問你能為你的社群做什麼

在最近釋出到 kubernetes-dev 列表的帖子中，Brian Grant 闡述了一系列出色的近期目標——這些目標有助於社群成長、完善我們的執行方式並實現未來的擴充套件。在每個 Kubernetes 特別興趣小組中，我們都在努力建立可持續的團隊，這些團隊可以在公司和社群之間進行協作，我們正在積極努力確保每個 SIG 都能在專案的一個願景下，跨越不同興趣領域進行貢獻、協調和交付。

我們特別感興趣的是擴充套件的故事——Kubernetes 的核心如何成為資料中心作業系統的心臟，並支援更多應用程式管理模式在 Kubernetes 之上構建，而不僅僅是構建到其中。1.2 和 1.3 版本中圍繞第三方 API、API 發現、靈活的排程器策略、外部授權和認證（超出 Kubernetes 內建的那些）所做的工作只是一個開始。當有人有需求時，我們希望他們能夠輕鬆找到解決方案，我們也希望其他人能夠輕鬆使用並貢獻該解決方案。同樣，驗證想法的最佳方式是針對實際需求進行原型設計，並針對實際問題進行迭代，這應該簡單自然。

在 Kubernetes 的兩歲生日之際，我希望回顧一年來的完善、使用者成功和社群參與。能為 Kubernetes 做出貢獻是我的榮幸，感覺我們才剛剛開始。謝謝大家，希望大家能一起踏上這段旅程！

• ←上一篇
• 下一篇→