不吹不黑，今天我們來聊一聊 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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術公眾號。”