作者 | afotostock、Shutterstock
編輯 | 言征
出品 | 51CTO技術棧（微信號：blog51cto）
6 月 6 日是Kubernetes發布 10 周年紀念日。
值得回想一下 2014 年，當時 Kubernetes 是當時推出的眾多管理容器的方法之一。當時已經存在像 Apache Mesos 這樣的大型開源項目，而啟動容器化的公司Docker則通過其 Docker Swarm 提供了一個很好的選擇。各家公司也在研究像 AWS ECS 管理工具這樣的方法，以及如何將它們用于特定的容器管理。
那么，為什么 Kubernetes 會勝出呢？我們最終會選擇 Kubernetes 作為云原生應用的平臺嗎？還是說這其中存在一些障礙？
1.從無狀態到有狀態的工作負載
大家起初認識Kubernetes時，是作為一個容器管理和編排平臺，它可以更輕松地管理微服務應用程序中的所有軟件容器。Kubernetes 基于Google 的內部容器管理服務Borg，該服務可處理數千個實例，最終以開源形式發布，供其他人利用來運行容器。
首先，必須指出的是，Kubernetes 起步并不顯眼。雖然一開始它被寄希望基于 Google 用于管理大量工作負載和流程的工具，但它事實上并沒有準備好在其他組織中承擔這一角色。它非常適合管理無狀態應用程序容器，并協調如何創建、使用以及在不再需要時拆除這些容器。但它一開始只專注于應用程序組件。
這與構成應用程序基礎架構的所有其他元素并不相符。雖然您的應用程序可能在云中運行并執行處理，但它也會創建必須隨時間存儲的數據。它必須與現有的數據源進行交互。它必須安全地運行，這樣信息就不會泄露，攻擊者也無法訪問這些組件。這些元素在 Kubernetes 的初始發布中不受支持。事實上，在考慮這些工作負載之前，又花了兩年時間才獲得StatefulSets支持和 Kubernetes Operators 的發布。
圖片
StatefulSets 提供了對穩定且唯一的網絡標識符以及穩定且持久的存儲的支持。它還可以執行更有序、更優雅的部署和擴展，以及更有序、更自動化的滾動更新。除此之外，Kubernetes Operators 的推出還允許開發人員隱藏將 Kubernetes 原語與其他應用程序一起使用的復雜性。如果沒有這兩項附加功能，在 Kubernetes 中運行有狀態工作負載需要進行一些嚴肅的 Kubernetes 核心黑客攻擊才能使其正常工作。
除此之外，社區也在努力讓有狀態工作負載在 Kubernetes 上有效運行。雖然圍繞運行 MySQL 和 PostgreSQL 等數據庫的討論始于 Reddit 和 Stack Overflow，但需要更正式的合作才能將其從好主意轉變為真實且可持續的項目。像Kubernetes 上的數據社區這樣的組織齊心協力為這種合作提供了正確的框架，使公司和個人更容易做出貢獻。
圖片
這項工作至關重要，因為一開始在 Kubernetes 上運行數據庫時有很多阻力。對于熟悉設計應用程序的12 個因素方法的人來說，后端服務應被視為附加資源。當時，這對于想要在容器中運行但又必須管理與托管在不同環境中的數據庫或存儲系統的交互的開發人員來說是個問題。理想的方法（也是我們現在擁有的）是數據庫應該以與應用程序組件完全相同的方式在集群中運行，因為這使得從一個點控制和管理整個服務的基礎架構變得更加容易。
2.開源的作用
Kubernetes 成功的主要原因之一是它是開源的。Kubernetes 被捐贈給云原生計算基金會，以便它能夠得到更廣泛的組織而不是一家控制供應商的支持。這有助于分散貢獻方面的負擔并提高接受度。當用戶考慮如何在云計算平臺上下注時，選擇一個不依賴于特定云提供商并且可以在其中任何一個上獨立運行容器的平臺被視為更明智的選擇。
圖片
這需要一個愿意支持 Kubernetes 項目的社區，并且他們必須為它的成功而投資。為了建立這個社區，Kubernetes 必須是開源的，正如 Kubernetes 聯合創始人 Brendan Burns在 Dev Interrupted播客中解釋的那樣。如果不開源，開發人員貢獻或選擇 Kubernetes 作為容器管理工具的動力就會小得多。
隨著時間的推移，Kubernetes 已從眾多容器編排工具之一發展成為云原生應用程序的平臺。它使開發人員能夠在任何云平臺或自己的數據中心環境中構建和運行他們的應用程序，然后將該工作負載轉移到他們未來想要使用的任何平臺上。作為其中的一部分，Kubernetes 已從專注于應用程序組件發展到支持云中的所有內容。
Kubernetes 并不完美。例如，Kubernetes 仍需要在自動擴展和管理數據和存儲等資源方面做更多工作，以便公司能夠更有效地控制成本。但這項工作正在多家公司和社區的支持下進行，因此未來每個人都可以受益。
