作者 | 孫健波（阿里巴巴技術專家）、趙鈺瑩

導讀：雲原生時代，Kubernetes 的重要性日益凸顯。然而，大多數網際網路公司在 Kubernetes 上的探索並非想象中順利，Kubernetes 自帶的複雜性足以讓一批開發者望而卻步。本文中，阿里巴巴技術專家孫健波在接受採訪時基於阿里巴巴 Kubernetes 應用管理實踐過程提供了一些經驗與建議，以期對開發者有所幫助。

在網際網路時代，開發者更多是通過頂層架構設計，比如多叢集部署和分散式架構的方式來實現出現資源相關問題時的快速切換，做了很多事情來讓彈性變得更加簡單，並通過混部計算任務來提高資源利用率，雲端計算的出現則解決了從 CAPEX 到 OPEX 的轉變問題。

雲端計算時代讓開發可以聚焦在應用價值本身，相較於以前開發者除了業務模組還要投入大量精力在儲存、網路等基礎設施，如今這些基礎設施都已經像水電煤一樣便捷易用。雲端計算的基礎設施具有穩定、高可用、彈性伸縮等一系列能力，除此之外還配套解決了一系列應用開發“最佳實踐”的問題，比如監控、審計、日誌分析、灰度釋出等。原來，一個工程師需要非常全面才能做好一個高可靠的應用，現在只要瞭解足夠多的基礎設施產品，這些最佳實踐就可以信手拈來了。但是，在面對天然複雜的 Kubernetes 時，很多開發者都無能為力。

作為 Jira 和程式碼庫 Bitbucket 背後的公司，Atlassian 的 Kubernetes 團隊首席工程師 Nick Young 在採訪中表示：

雖然當初選擇 Kubernetes 的戰略是正確的（至少到現在也沒有發現其他可能的選擇），解決了現階段遇到的許多問題，但部署過程異常艱辛。

那麼，有好的解決辦法嗎？

太過複雜的 Kubernetes

“如果讓我說 Kubernetes 存在的問題，當然是‘太複雜了’”，孫健波在採訪中說道，“不過，這其實是由於 Kubernetes 本身的定位導致的。”

孫健波補充道，Kubernetes 的定位是“platform for platform”。它的直接使用者，既不是應用開發者，也不是應用運維，而是“platform builder”，也就是基礎設施或者平臺級工程師。但是，長期以來，我們對 Kubernetes 專案很多時候都在錯位使用，大量的應用運維人員、甚至應用研發都在直接圍繞 Kubernetes 很底層的 API 進行協作，這是導致很多人抱怨 “Kubernetes 實在是太複雜了”的根本原因之一。

這就好比一名 Java Web 工程師必須直接使用 Linux Kernel 系統呼叫來部署和管理業務程式碼，自然會覺得 Linux “太反人類了”。所以，目前 Kubernetes 專案實際上欠缺一層更高層次的封裝，來使得這個專案能夠對上層的軟體研發和運維人員更加友好。

如果可以理解上述的定位，那麼 Kubernetes 將 API 物件設計成 all-in-one 是合理的，這就好比 Linux Kernel 的 API，也不需要區分使用者是誰。但是，當開發者真正要基於 K8s 管理應用、並對接研發、運維工程師時，就必然要考慮這個問題，也必然要考慮如何做到像另一層 Linux Kernel API 那樣以標準、統一的方式解決這個問題，這也是阿里雲和微軟聯合開放雲原生應用模型 Open Application Model （OAM）的原因。

有狀態應用支援

除了天然的複雜性問題，Kubernetes 對於有狀態應用的支援也一直是眾多開發者花費大量時間研究和解決的問題，並不是不可以支援，只是沒有相對較優的解決方案。目前，業內主流的針對有狀態應用的解法是 Operator，但是編寫 Operator 其實是很困難的。

在採訪中，孫健波表示，這是因為 Operator 本質上是一個“高階版”的 K8s 客戶端，但是 K8s API Server 的設計，是“重客戶端”的模型，這當然是為了簡化 API Server 本身的複雜度，但也導致了無論是 K8s client 庫，還是以此為基礎的 Operator，都變的異常複雜和難以理解：它們都夾雜了大量 K8s 本身的實現細節，比如 reflector、cache store、informer 等。這些，並不應該是 Operator 編寫者需要關心的，Operator 編寫者應該是有狀態應用本身的領域專家（比如 TiDB 的工程師），而不應該是 K8s 專家。這是現在 K8s 有狀態應用管理最大的痛點，而這可能需要一個新的 Operator 框架來解決這個問題。

另一方面，複雜應用的支援不止編寫 Operator 這麼簡單，這裡還需要有狀態應用交付的技術支撐，這是目前社群上各種持續交付專案都有意或者無意間忽略掉的事情。事實上，持續交付一個基於 Operator 的有狀態應用，跟交付一個無狀態的 K8s Deployment 的技術挑戰完全不是一個量級的。這也是孫健波所在團隊在 CNCF 應用交付領域小組（CNCF SIG App Deliver）倡導“應用交付分層模型”的重要原因：如下圖所示，四層模型分別為“應用定義”、“應用交付”、“應用運維與自動化”、“平臺層”，只有通過這四個層不同能力的合力協作，才能真正做到高質量和高效率的交付有狀態應用。

舉個例子，Kubernetes API 物件的設計是“all-in-one”的， 即：應用管理過程中的所有參與者，都必須在同一個 API 物件上進行協作。這就導致開發者會看到，像 K8s Deployment 這樣的 API 物件描述裡， 既有應用開發關注的欄位，也可以看到運維關注的欄位，還有一些欄位可能還是被多方關注的。

實際上，無論是應用開發、應用運維，還是 HPA 這樣的 K8s 自動化能力，它們都有可能需要控制一個 API 物件裡的同一個欄位。最典型的情況就是副本數（replica）這種引數。但是，到底誰 own 這個欄位，是一個非常棘手的問題。

綜上，既然 K8s 的定位是雲時代的 Linux Kernel，那麼 Kubernetes 就必須在 Operator 支援、API 層以及各類介面定義的完善上不斷進行突破，使得更多生態參與者可以更好的基於 K8s 構建自己的能力和價值。

阿里巴巴大規模 Kubernetes 實踐

如今，Kubernetes 在阿里經濟體的應用場景涵蓋了阿里方方面面的業務，包括電商、物流、離線上計算等，這也是目前支撐阿里 618、雙 11 等網際網路級大促的主力軍之一。阿里集團和螞蟻金服內部運行了數十個超大規模的 K8s 叢集，其中最大的叢集約 1 萬個機器節點，而且這其實還不是能力上限。每個叢集都會服務上萬個應用。在阿里雲 Kubernetes 服務（ACK）上，我們還維護了上萬個使用者的 K8s 叢集，這個規模和其中的技術挑戰在全世界也是首屈一指的。

孫健波透露，阿里內部早在 2011 年便開始了應用容器化，當時最開始是基於 LXC 技術構建容器，隨後開始用自研的容器技術和編排排程系統。整套系統本身沒有什麼問題，但是作為基礎設施技術團隊，目標一定是希望阿里的基礎技術棧能夠支撐更廣泛的上層生態，能夠不斷演進和升級，因此，整個團隊又花了一年多時間逐漸補齊了 K8s 的規模和效能短板。總體來看，升級為 K8s 是一個非常自然的過程，整個實踐過程其實也很簡單：

• 第一：解決應用容器化的問題，這裡需要合理利用 K8s 的容器設計模式；
• 第二：解決應用定義與描述的問題，這裡需要合理的利用 OAM，Helm 等應用定義工具和模型來實現，並且要能夠對接現有的應用管理能力；
• 第三：構建完整的應用交付鏈，這裡可以考慮使用和整合各種持續交付能力。

如上的三步完成，就具備了對接研發、運維、上層 PaaS 的能力，能夠講清楚自己的平臺價值。接下來就可以試點開始，在不影響現有應用管理體系的前提下，一步步換掉下面的基礎設施。

Kubernetes 本身並不提供完整的應用管理體系，這個體系是整個雲原生的生態基於 K8s 構建出來的，可以用下圖表示：

Helm 就是其中最成功的一個例子，它位於整個應用管理體系的最上面，也就是第 1 層，還有 Kustomize 等各種 YAML 管理工具，CNAB 等打包工具，它們都對應在第 1.5 層。然後有 Tekton、Flagger 、Kepton 等應用交付專案，對應在第 2 層。Operator ，以及 K8s 的各種工作負載元件，比如 Deployment、StatefulSet，對應在第 3 層。最後才是 K8s 的核心功能，負責對工作負載的容器進行管理，封裝基礎設施能力，對各種不同的工作負載對接底層基礎設施提供 API 等。

初期，整個團隊最大的挑戰來自於規模和效能瓶頸，但這個解法也是最直接的。孫健波表示，隨著規模逐漸增大，我們看到規模化鋪開 K8s 最大的挑戰實際上是如何基於 K8s 進行應用管理和對接上層生態。比如，我們需要統一的管控來自數十個團隊、數百個不同目的的 Controller；我們需要以每天近萬次的頻率交付來自不同團隊的生產級應用，這些應用的釋出、擴容策略可能完全不同；我們還需要對接數十個更加複雜的上層平臺，混合排程和部署不同形態的作業以追求最高的資源利用率，這些訴求才是阿里巴巴 Kubernetes 實踐要解決的問題，規模和效能只是其中一個組成部分。

除了 Kubernetes 的原生功能外，在阿里巴巴內部會開發大量的基礎設施以 K8s 外掛的形式對接到這些功能上，隨著規模的擴大，用統一的方式發現和管理這些能力成為了一個關鍵問題。

此外，阿里巴巴內部也有眾多存量 PaaS，這些是為了滿足使用者不同業務場景上雲所構建的，比如有的使用者希望上傳一個 Java 的 War 包就可以執行，有的使用者希望上傳一個映象就可以執行。在這些需求背後，阿里各團隊幫使用者做了許多應用管理的工作，這也是存量 PaaS 出現的原因，而這些存量 PaaS 與 Kubernetes 對接過程可能會產生各種問題。目前，阿里正在通過 OAM 這個統一標準的應用管理模型，幫助這些 PaaS 向 K8s 底盤進行對接和靠攏，實現標準化和雲原生化。

解耦運維和研發

通過解耦，Kubernetes 專案以及對應的雲服務商就可以為不同的角色暴露不同維度、更符合對應使用者訴求的宣告式 API。比如，應用開發者只需要在 YAML 檔案中宣告”應用 A 要使用 5G 可讀寫空間“，應用運維人員則只需要在對應的 YAML 檔案裡宣告”Pod A 要掛載 5G 的可讀寫資料卷“。這種”讓使用者只關心自己所關心的事情“所帶來的專注力，是降低 Kubernetes 使用者學習門檻和上手難度的關鍵所在。

孫健波表示，現在大多數的解法實際上是“悲觀處理”。比如，阿里內部的 PaaS 平臺，為了減輕研發使用的負擔，長期以來只開放給研發設定 5 個 Deployment 的欄位。這當然是因為 K8s YAML "all-in-one"的設計，使得完整的 YAML 對研發來說太複雜，但這也導致 K8s 本身的能力，絕大多數情況下對研發來說是完全沒有體感的。而對 PaaS 平臺運維來說，他反而覺得 K8s YAML 太簡單，不夠描述平臺的運維能力，所以要給 YAML 檔案新增大量 annotation。

此外，這裡的核心問題在於，對運維人員而言，這種“悲觀處理”的結果就是他自己太“獨裁”，包攬了大量細節工作，還費力不討好。比如擴容策略，目前就是完全由運維一方說了算。可是，研發作為編寫程式碼的實際人員，才是對應用怎麼擴容最有發言權的，而且研發人員也非常希望把自己的意見告訴運維，好讓 K8s 更加 靈活，真正滿足擴容需求。但這個訴求在目前的系統裡是無法實現的。

所以，“研發和運維解耦”並不是要把兩者割裂，而是要給研發提供一個標準、高效的，同運維進行溝通的方式，這也是 OAM 應用管理模型要解決的問題。孫健波表示，OAM 的主要作用之一就是提供一套研發從自己的角度表達訴求的標準和規範，然後這套標準“你知，我知，系統知”，那麼上面這些問題也就迎刃而解了。

具體來說，OAM 是一個專注於描述應用的標準規範。有了這個規範，應用描述就可以徹底與基礎設施部署和管理應用的細節分開。這種關注點分離（Seperation of Conerns）的設計好處是非常明顯的。舉個例子，在實際生產環境中，無論是 Ingress、CNI 還是 Service Mesh，這些表面看起來一致的運維概念，在不同的 Kubernetes 叢集中可謂千差萬別。通過將應用定義與叢集的運維能力分離，我們就可以讓應用開發者更專注應用本身的價值點，而不是”應用部署在哪“這樣的運維細節。

此外，關注點分離讓平臺架構師可以輕鬆地把平臺運維能力封裝成可被複用的元件，從而讓應用開發者專注於將這些運維元件與程式碼進行整合，從而快速、輕鬆地構建可信賴的應用。OAM 的目標是讓簡單的應用管理變得更加輕鬆，讓複雜的應用交付變得更加可控。孫健波表示，未來，團隊將專注於將這套體系逐步向雲端 ISV 和軟體分發商側推進，讓基於 K8s 的應用管理體系真正成為雲時代的主流。

嘉賓介紹：孫健波，阿里巴巴技術專家。Kubernetes 專案社群成員。目前在阿里巴巴參與大規模雲原生應用交付與管理相關工作，2015 年參與編寫《Docker 容器與容器雲》技術書籍。曾任職七牛，參與過時序資料庫、流式計算、日誌平臺等專案相關應用上雲過程。

今年 12 月 6-7 日北京 ArchSummit 全球架構師峰會上，孫健波老師會繼續分享《阿里巴巴 Kubernetes 應用管理實踐中的經驗與教訓》，會介紹阿里對解耦研發和運維過程中的現有實踐，以及實踐本身存在的問題；以及實施的標準化、統一化解決的思路，以及對社群的進一步思考。

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

更多詳細資訊可關注“阿里巴巴雲原生”