不吹不黑，今天我們來聊一聊 Kubernetes 落地的三種方式

作者 | 王國梁  Kubernetes 社群成員與項目維護者原文标題《Kubernetes 應用之道：讓 Kubernetes落地的“三闆斧”》，首發于知乎專欄：進擊的雲計算原文位址： https://zhuanlan.zhihu.com/p/82666719 出身豪門、大廠背書的 Kubernetes 項目自 2014 年 6 月開源以來，在衆多廠商和開源愛好者的共同努力下迅速崛起，時至今日已成長為容器管理領域的事實标準。憑借超前的設計理念、開放的參與門檻、國内外大廠和開發者的大力支援，它的成功不言而喻。

Kubernetes 熱度

國内外對 Kubernetes 這波潮流的追捧，包括各大雲廠商，螞蟻金服、京東、美團、滴滴等各大公司都把 Kubernetes 作為自己的基礎設施重心，"一萬個人眼中就有一萬個哈姆雷特"，雖說 Kubernetes 是容器管理領域的事實标準，但實際上在不同背景的企業中，Kubernetes 的落地方式上是存在差異的。大緻可分為三類：

• 一類是完全在 Kubernetes 的之上 (Above) 以其原生方式部署和應用，這類使用者大部分是一些初創企業，沒有過多的技術棧負擔，并且主要集中在使用公有雲的 Kubernetes 方案和服務；
• 一類是基于 Kubernetes (On) 建構的容器管理平台，複用了 Kubernetes 的一些概念但是并沒有把應用的管理交給 Kubernetes 來管理，保持着舊的服務治理方式，這類企業發展時間比較久，技術負擔比較重，無法立即切換到雲原生的服務治理方式，一時無法抛棄多年的技術積累，這類使用者主要集中在一些中型或大型的私有雲的 Kubernetes 使用場景；
• 另一類是基于 Kubernetes 的設計理念 (In) 通過自定義應用負載來解決和适應本地化的應用管理需求，将本地化的負載和管理融入到原生的 Kubernetes 架構中，這也是目前應用管理的一個趨勢，既能吃到雲原生和社群 Kubernetes 的紅利，又能更好地将多年的技術積累發展演進，融入其中，這是一種擁抱雲原生的一種絕佳道路。

基礎"斧"：Above Kubernetes

如果現在讓你選擇一個容器管理平台，相信應該沒人會錯過 Kubernetes，尤其對于沒有任何技術負擔的使用者，選擇 Kubernetes 無疑是最明智的一個選擇。

Above Kubernetes，這種落地方式很好了解，就是你把原生的、标準的、無任何接觸和侵入改動的社群版本的 Kubernetes 拿來，直接部署運作起來即可，完全在 Kubernetes 之上建構自己的應用，通過标準的 Kubernetes API 來通路叢集。你可以完全跟着社群更新演進你的 Kubernetes，保持與社群同步，完全借助于社群的力量維護你的 Kubernetes。

這種落地方式無疑是最理想的，你不必考慮與社群和業界的主流脫離，同時也降低了管理和運維的成本。

如上圖，你可以安裝标準的、主流的雲原生體系來落地 Kubernetes，可以擁抱社群的一整套完整的架構方案，并且足以滿足你的需求。

高階"斧"：On Kubernetes

能夠使用原生的 Kubernetes 叢集誠然非常好，但是有些場景并不一定走得通。大家都知道，Kubernetes 的概念和設計其實是很超前的，谷歌的軟體開發和應用部署理念雖然好，但業界大部分的企業還是陳舊的技術理念和更複雜的場景，對于一些由技術積澱的企業使用者而言，想要一下子抛棄目前的應用管理和部署方式改為原生的 Kubernetes 的應用部署和管理方式，确實有些吃不消。那對于這些使用者而言，肯定不能看着别人吃肉自己啃窩窩頭。

On Kubernetes 的落地形态其實是一種妥協和中間過程，一方面很難一下子抛棄已有的基礎設施，例如服務治理、監控、網絡拓撲等等，隻能在原生的 Kubernetes 基礎上做一些本地化改造使得 Kubernetes 能夠滿足目前的應用管理方式，例如抛棄 kube-proxy 使用扁平化的内網環境、通過富容器的方式包裝一些監控和代理元件等等。

這種落地方式一方面能夠做少了改動就吃到這波技術紅利，一方面可以探索屬于自己的雲原生的道路，内部技術棧也可以朝着雲原生的方向發展演進，不至于在這波潮流中落後太多，而且可以根據自己的場景做定制化的 Kubernetes 開發，甚至比社群的 Kubernetes 走的更遠或者解決一些社群沒有解決的問題。

有得必有失，雖然可以借助于 Kubernetes 的設計理念和管理能力，但是同時由于本地化的改造不能完全與社群版本的 Kubernetes 相容，更新就會比較麻煩，每次更新不得不重新打 patch，還會出現同時維護多個 Kubernetes 版本的窘境，這無疑會給開發和運維帶來很多麻煩，是以這也不是一般的小公司能夠走得通的道路，需要一定的研發和技術能力。比較典型的是阿裡巴巴的 Sigma、美團點評的 HULK 2.0 以及京東的 JDOS 2.0 。

美團點評 HULK2.0

在這種高階的玩法中，沒有标準的套路，隻有符合自己的方案。例如美團點評結合自己已有的設施在 Kubernetes 上建構了 HULK2.0 系統，在存儲、網絡、負載生命周期管理以及應用監控等方面做了本地化改造，但是仍然保持對 Kubernetes API 的完全相容。你可以根據自有的基礎設施，例如存儲、監控、鍊路追蹤、服務釋出以及網絡等等一系列元件融合，甚至根據業務場景和自身需求對 Kubernetes 做深度的定制化，例如網易雲基于 Kubernetes 的深度定制化實踐。

絕殺"斧"：In Kubernetes

雲原生這一說法在技術圈已經廣為流傳，甚至一些同學并不了解什麼是雲原生，但都知道要朝着雲原生的方向發展演進。不管怎樣，對于使用者而言，改變以往虛拟機的部署和管理方式以及服務的治理政策是必要的。不得不說，All in Kubernetes 是一個趨勢，CRD 自 Kubernetes 1.7 版本産生到上周釋出的 1.16 版本的 GA，也就是說我們完全有了可以在生産環境擴充 Kubernetes 的能力。

大家如果深入了解 Kubernetes 會發現，Kubernetes 本身就是一個平台，Kubernetes 除了提供了很多的功能：例如它可以簡化應用程式的工作流，加快開發速度；使用者可以使用 Label 以自己的方式組織管理資源；還可以使用 Annotation 來自定義資源的描述資訊，比如為管理工具提供狀态檢查等。此外，Kubernetes 控制器也是建構在跟開發人員和使用者使用的相同的 API 之上，使用者還可以編寫自己的控制器和排程器，也可以通過各種插件機制擴充系統的功能。

這就是說，我們完全可以在 Kubernetes 裡面通過擴充 API 和負載類型完成任何形式和類型的應用負載和管理方法，即使你有複雜的技術棧不可擺脫或者說有複雜的工作流，沒問題，你可以根據自己的需要在資源和應用生命周期注入任何外部依賴和邏輯。

這種落地方式其實是借助于 Kubernetes 提供的擴充機制，完全将本地化、複雜化的邏輯轉化為 Kubernetes 的設計和管理理念，不僅僅是使用 Kubernetes，而是融入和弱化原生 Kubernetes，最終每個使用者都有着自己的一套獨一無二的 Kubernetes。你中有我，我中有你。此外，它仍然完全和原生的 Kubernetes 相容，可以優雅地更新和合并社群的 patch 等等。比較有代表性的是阿裡開源的 Openkruise 項目。

https://github.com/openkruise/kruise

使用者使用 Kubernetes 核心是對工作負載的管理，其實選擇 On Kubernetes 的一個很大原因是使用者目前的工作負載管理方式與 Kubernetes 的已有工作負載類型不能很好地比對。CRD 和 Operator 很好地解決了這個問題，讓使用者可以定制自己的負載。OpenKruise 項目就是這樣一個典型的例子， 它是一組控制器，可擴充和補充 Kubernetes 核心控制器的工作負載管理。例如它提供三種工作負載控制器：

• 進階 StatefulSet：預設 StatefulSet 的增強版本，具有額外的功能，例如 inplace-update，pasue 和 MaxUnavailable。

• BroadcastJob：在叢集中的所有節點上運作 Pod 以完成的作業。

• SidecarSet：一個控制器，它根據選擇器将邊車容器注入 Pod 規範，并且能夠更新邊車容器。

理想的情況下，任何負載都可以做到 All in Kubernetes，甚至 Kubernetes 本身的負載管理，即 kube-on-kube，以及對于有狀态服務的管理，例如 Mysql 叢集 Operator 等等，你可以在 operatorhub 找到一些非常經典的例子。

總結

雖說不同的落地方式互有差異，但其實都是不同背景下的最好選擇，它們都可以做到完全相容 Kubernetes 的 API，脫離了問題本身，都不能說哪種方式最好。

• Above Kubernetes：如果你是一家初創公司，隻想使用 Kubernetes 滿足正常的容器管理或者服務部署，沒有什麼負擔，同時人力也不足，沒有能力自己維護 Kubernetes；
• On Kubernetes：如果你是一家中型甚至大型公司，有着大量的技術積累和設施，并且有能力和人力改造和開發 Kubernetes 或者原生的 Kubernetes 并不能滿足你的需求；
• In Kubernetes：你不滿足于單純使用 Kubernetes 或者說原生的 Kubernetes 不能滿足你的需求，你可以從 Above Kubernetes 轉變而來；當然，如果痛定思痛，或者想徹底地改造目前的基礎設施和應用管理方式，想更加靠近雲原生的道路或者想要更新陳舊的機器部署和傳遞模式，你可以從 On Kubernetes 轉變而來，最終 All in Kubernetes。

你的 Kubernetes 落地方式是什麼樣子呢？

“ 阿裡巴巴雲原生微信公衆号（ID：Alicloudnative）關注微服務、Serverless、容器、Service Mesh等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公衆号。”