阿里巴巴 Kubernetes 應用管理實踐中的經驗與教訓

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

導讀：雲原生時代，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 在阿里經濟體的應用場景涵蓋了阿里方方面面的業務，包括電商、物流、離在線計算等，這也是目前支撐阿里 61八、雙 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等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術公衆號。」

更多詳細信息可關注「阿里巴巴雲原生」。