Kubernetes

謝邀，一種現象的出現往往都是多種因素的疊加造成的。

一、天時：當Docker等容器運行時成熟時，越來越多的企業在私有雲和公有雲中運行著成百上千的容器實例，關注點逐漸轉移到如何管理和調度容器了，自然需要在上層架設一套管理系統。

二、地利：K8S由Google背書，是由Google內部穩定運行了十幾年的第一代容器管理系統Borg、第二代容器管理系統Omega演進而來，目前的K8S是第三代容器管理系統，針對大規模應用集羣的自動管理提出了很多先進的理念並且實現了：Pod、ReplicaSet、Service、Kube-proxy等。而且，由於Google的背書，越來越多的第三方加入到K8S生態中來，可以說整個CNCF社區就是圍繞K8S生態構建的。這是其他幾個競爭對手（如Mesos、Swarm等）沒法比的。

CNCF社區的項目清單

三、人累：沒錯，是人累了。2010-2017年可以算是雲計算基礎軟體創新的黃金幾年，這幾年大家一直在圍繞虛擬化和雲計算花式創新，從XEN、KVM一路玩到Eucalyptus、CloudStack、OpenStack，從LXC、Docker玩到Yarn、Mesos、Swarm和Kubernetes。但天下苦秦久矣，創業廠家、科技媒體、IT自媒體隔三差五就跳出來要顛覆已有的IT基礎設施。

1、剛部署完Xen，就說Xen性能不好，要用KVM；

2、換了KVM後，說光有虛擬化不成，需要加一層雲管理平臺OpenStack；

3、剛部署完OpenStack，又說OpenStack太笨重龐大，不好運維，需要考慮容器；

4、剛部署完容器，準備用Mesos+Marathon來管理容器，又說Mesos不好，不適合長任務，要用Kubernetes。

花了這麼多時間在底層折騰，底層迭代比業務系統迭代還快，業務層面沒見更多好轉，人卻疲憊了，所以大家急切需要有一套穩定可靠的軟體來統管雲平臺基礎設施，用穩態的雲平臺基礎設施支撐上層敏態應用的快速迭代更新。

選擇開源的原因一般都是技術先進、生態好、無廠商鎖定之類的，然而並不是所有的開源項目都能成為業界標準，Kubernetes 之所以成為標準，被 Docker、OpenStack 和各大公有雲服務商接受，還是因為其本身的雲原生（Cloud Native）屬性。

就在這個五一假期（美國西部時間 5 月 2 日），作為 Mesos 項目的早期支持者和重度使用者之一的 Twitter，宣佈從 Mesos 遷移到 Kubernetes（內部 Kubernetes 集羣 + 公有雲 Kubernetes 集羣），遷移工作將於 2020 年底之前完成。

2017 年，Kubernetes 被 Docker 接納，已經成為容器編排的標準，此番 Twitter 從 Mesos 全面轉向 Kubernetes，再次證明瞭 Kubernetes 的江湖地位不可動搖。畢竟，Mesos 也是編排工具的三大競爭者之一，而 Twitter 運行著萬級別節點的 Mesos 集羣作為生產環境。

Twitter 對這一改變的解釋，主要是 Mesos 跟不上雲計算的節奏，表現為基礎設施複雜性上升、非雲原生設計、多雲/多集羣管理成本高等，但這些挑戰，在 Kubernetes 以應用為核心的雲原生設計中就不再是問題了。

我雲首席架構師劉超曾經撰文指出：Kubernetes 確實引入了很多概念，但它的這些設計，更適合微服務和 DevOps 的思想與實踐。比如，微服務設計區分無狀態和有狀態，在 Kubernetes 中，無狀態對應 deployment，有狀態對應 StatefulSet。詳見：為什麼 kubernetes 天然適合微服務

Twitter 傾心於 Kubernetes 的原因之一，正是後者原生具備有狀態業務（Stateful Application）的管理語義。

kubernetes成為一個趨勢是必然

過去的xen也好，kvm也罷，還是什麼openstack，都離應用太遠了

他們都在關注如何管理虛擬機，好像管理好虛擬機了，一切就萬事大吉了，應用誰來管理，應用和底層基礎設施的耦合無法處理

舉個例子吧，通常雲廠商有autoscaling對吧，這一套autoscaling是基於什麼的呢，是基於操作系統的快照，和對特定的監控指標，看起來似乎是解決了擴縮容問題，其實還差很遠。操作系統的鏡像製作複雜且麻煩，繁重不堪，迭代相對複雜

kubernetes出來之後，你只需要告訴他，你需要的副本數，就可以實現了，多麼的簡單

另外就是現在隨著kubernetes的能力越來越強，雲基礎設施對kubernetes的支持越來越好，我們以後只需要面向kubernetes進行應用的部署維護，只需要一個yaml聲明（也可能是使用helm工具），告訴我們kubernetes集羣，我需要一個5Gi的磁碟，我需要在負載均衡上面配置一個路由，我需要的一切都可以通過kubernetes的聲明文件來聲明，並且呢，由於對於很多介面，kubernetes都做了很大的抽象，所以在不同的雲廠商間切換，所需要做的修改，也非常小

kubernetes所具備的能力是之前的雲基礎設施沒有解決的，所以當然火了啊

對比下kubernetes和mesos，以本人的淺見，mesos並非是專門調度容器的框架，以其文檔所述，mesos在使用容器的時候會強依賴docker cli，而kubernetes實現了CRI介面，不僅可以支持docker，還可以支持諸如podman, rkt這樣的runtime。

先寫這麼多

因為之前 Docker 實在太熱門了，不管用不用大家都要來湊熱鬧。但是 Kubernetes 誕生不久後直接邊緣化了 Docker。同時讓容器規範的定製權不再專治（減弱了 Docker 公司對 Docker 的控制權），Openstack 底層也接受 K8S，不得不說它實在太流弊了…

出自谷歌，又確實很好，要一統天下的架勢，怎麼能不火呢。

因為微服務架構解決單體應用問題。

但是又引入了新的複雜性需要解決

目前看來只有k8s比較好的解決了這個複雜的問題

k8s本身也是一個微服務分散式架構

因為雲計算髮展越來越快了，Kubernetes現在成為docker編排工具的領頭羊了，微服務框架越來越成熟，標準化，通過Kubernetes快速部署服務效率大大提高，容器化部署服務，快速交互，自動化運維。

2019年5月2日下午，Twitter 公司正式宣佈從 Mesos 全面轉向 Kuberbetes，消息一出，引起了一場互聯網業內的小「地震」。那麼， Kubernetes 現在為什麼如此火熱？為什麼 Twitter 公司會選擇 Kubernetes？

Kubernetes，是一個開源的 Linux 容器自動化運維平臺，它消除了容器化應用程序在部署、伸縮時涉及到的許多手動操作。

它最開始是由谷歌的工程師設計開發的，谷歌作為 Linux 容器技術的早期貢獻者之一，曾公開演講介紹他們是如何將一切都運行於容器之中。Borg 就是 Kubernetes 的前身，谷歌幾年來開發 Borg 的經驗教訓也成了影響 Kubernetes 中許多技術的主要因素。

那麼，為什麼需要 Kubernetes 呢？

其實真實的生產環境應用會包含多個容器，而這些容器還很可能會跨越多個伺服器主機部署。Kubernetes 提供了為那些工作負載大規模部署容器的編排與管理能力。Kubernetes 編排讓人們能夠構建多容器的應用服務，在集羣上調度或伸縮這些容器，以及管理它們隨時間變化的健康狀態。

當然，Kubernetes 也需要與網路、存儲、安全、監控等其它服務集成才能提供綜合性的容器基礎設施。

而企業在生產環境中使用 Kubernetes 的主要優勢在於它提供了在物理機或虛擬機集羣上調度和運行容器的平臺。更寬泛地說，它能幫人們在生產環境中實現可以依賴的基於容器的基礎設施。

以 Twitter 為首的互聯網公司，決定轉向 Kubernetes，主要是基於以下幾個原因：

1/ 雲時代，企業基礎設施面臨新挑戰

在互聯網級別的技術場景下，依託頂級工程師和成熟技術自建基礎設施，一直以來都是一線非雲互聯網廠商的架構首選。正是在這個過程中，相對成熟並且工作層次較低的 Mesos 項目收穫到了大量規模級生產環境部署案例。不過，隨著雲計算的普及和 Kubernetes 這樣以「雲」為核心的容器化基礎設施項目的迅速崛起，這種傳統互聯網基礎技術架構選型方法逐步暴露出很多前所未有的問題。

2/ Mesos 和 Aurora 體系與「雲原生」始終漸行漸遠

雲時代一個重要的技術發展趨勢就是軟體的生命週期會逐步向「生在雲上、長在雲上」的形態靠攏。這也就意味著作為支撐軟體的核心基礎設施項目，必然要向「發揮雲的最大價值」的方向不斷演進。

遺憾的是，Mesos 以及 Aurora 項目或許是由於發布較早，始終沒能夠將「雲」變成整個基礎設施體系中的「一等公民」。相比之下，Kubernetes 體系從發布伊始就不斷倡導「聲明式 API」、「容器設計模式」、「控制器模型」等各項理念。

如今，這些頂層架構設計與各種最佳實踐，被廣大開發者們冠名為「雲原生」。這也成為 Kubernetes 項目與其它競爭對手相比最大的不同。

3/ 大規模生產環境的「Kubernetes Native「技術路徑

作為不斷在快速發展和迭代的互聯網公司，高壓力和快節奏背景下的企業往往無暇顧及基礎設施架構的標準化與兼容性問題，這同樣也是 Twitter 公司面臨的主要問題之一，所以，在這次轉型過程當中，「Kubernetes Native」成為一個被反覆強調的關鍵詞。

在發布會上，Twitter 公司公佈了選擇 Kubernetes Native 方向的諸多評估依據：
  • 良好的開源技術與開源生態；
  • 全世界所有的公有雲都提供 Kubernetes 服務，不必擔心廠商鎖定；
  • 原生具備有狀態業務（Stateful Application）的管理語義；
  • 項目本身快速迭代，具有很強創新能力和先進性；
  • 具備標準的存儲對接介面，幫助 Twitter 無縫遷移各種現有存儲服務。

4/ 傳統的多雲、多集羣管理成本居高不下，並在可預見的未來內迅速攀升

在傳統的互聯網架構中，自建數據中心和基礎設施體系是整個軟體系統的第一假設。而「雲」所扮演的角色，更像是在流量突發時應付峯值的資源「備胎」，與應用開發、交付和運維體系也失去了直接關聯。

而在雲原生體系普及之後，「每朵雲上都有無數個 Kubernetes 集羣」逐漸成為應用基礎設施能夠依賴的常態。在 Twitter 的業務越來越多的需要多雲、多集羣環境交付的趨勢下， Kubernetes 這種從根本上幫助應用迅速向多雲交付的「捷徑」，這也成為 Twitter 選擇變更自身技術體系的另一個重要原因。

從最早 Mesos 「代言人」到如今的全面轉向 「Kubernetes Native」，Twitter 公司的選擇無疑為「Kubernetes 項目成為互聯網級基礎設施標準」又增加了一個重量級佐證。

伴隨著雲計算的進一步普及和像 Kubernetes 這樣以「雲」為核心的容器化基礎設施項目的迅速崛起，越來越多的世界級企業開始思考如何藉助「雲」以及雲原生技術來擁抱開源生態和開放的技術標準，準備迎接一個具備強勁的迭代能力的、面向「雲原生」的未來。

文章轉載自微信公眾號「 雲上馬可君 」（ID: webeye_global）

推薦閱讀：
相關文章