不吹不黑，今天咱們來聊一聊 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 。

<p style="text-align:center">美團點評 HULK2.0</p>

在這種高階的玩法中，沒有標準的套路，只有符合本身的方案。例如美團點評結合本身已有的設施在 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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」