阿里巴巴 Kubernetes 應(yīng)用管理實(shí)踐中的經(jīng)驗(yàn)與教訓(xùn)

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

導(dǎo)讀：云原生時(shí)代，Kubernetes 的重要性日益凸顯。然而，大多數(shù)互聯(lián)網(wǎng)公司在 Kubernetes 上的探索并非想象中順利，Kubernetes 自帶的復(fù)雜性足以讓一批開(kāi)發(fā)者望而卻步。本文中，阿里巴巴技術(shù)專家孫健波在接受采訪時(shí)基于阿里巴巴 Kubernetes 應(yīng)用管理實(shí)踐過(guò)程提供了一些經(jīng)驗(yàn)與建議，以期對(duì)開(kāi)發(fā)者有所幫助。

在互聯(lián)網(wǎng)時(shí)代中，開(kāi)發(fā)者更多是通過(guò)頂層架構(gòu)設(shè)計(jì)，比如多集群部署和分布式架構(gòu)的方式來(lái)實(shí)現(xiàn)出現(xiàn)資源相關(guān)問(wèn)題時(shí)的快速切換，做了很多事情來(lái)讓彈性變得更加簡(jiǎn)單，并通過(guò)混部計(jì)算任務(wù)來(lái)提高資源利用率，云計(jì)算的出現(xiàn)則解決了從 CAPEX 到 OPEX 的轉(zhuǎn)變問(wèn)題。

云計(jì)算時(shí)代讓開(kāi)發(fā)可以聚焦在應(yīng)用價(jià)值本身，相較于以前開(kāi)發(fā)者除了業(yè)務(wù)模塊還要投入大量精力在存儲(chǔ)、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施，如今這些基礎(chǔ)設(shè)施都已經(jīng)像水電煤一樣便捷易用。云計(jì)算的基礎(chǔ)設(shè)施具有穩(wěn)定、高可用、彈性伸縮等一系列能力，除此之外還配套解決了一系列應(yīng)用開(kāi)發(fā)“最佳實(shí)踐”的問(wèn)題，比如監(jiān)控、審計(jì)、日志分析、灰度發(fā)布等。原來(lái)，一個(gè)工程師需要非常全面才能做好一個(gè)高可靠的應(yīng)用，現(xiàn)在只要了解足夠多的基礎(chǔ)設(shè)施產(chǎn)品，這些最佳實(shí)踐就可以信手拈來(lái)了。但是，在面對(duì)天然復(fù)雜的 Kubernetes 時(shí)，很多開(kāi)發(fā)者都無(wú)能為力。

作為 Jira 和代碼庫(kù) Bitbucket 背后的公司，Atlassian 的 Kubernetes 團(tuán)隊(duì)首席工程師 Nick Young 在采訪中表示：

雖然當(dāng)初選擇 Kubernetes 的戰(zhàn)略是正確的（至少到現(xiàn)在也沒(méi)有發(fā)現(xiàn)其他可能的選擇），解決了現(xiàn)階段遇到的許多問(wèn)題，但部署過(guò)程異常艱辛。

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

太過(guò)復(fù)雜的 Kubernetes

“如果讓我說(shuō) Kubernetes 存在的問(wèn)題，當(dāng)然是‘太復(fù)雜了’”，孫健波在采訪中說(shuō)道，“不過(guò)，這其實(shí)是由于 Kubernetes 本身的定位導(dǎo)致的?！?/p>

孫健波補(bǔ)充道，Kubernetes 的定位是“platform for platform”。它的直接用戶，既不是應(yīng)用開(kāi)發(fā)者，也不是應(yīng)用運(yùn)維，而是“platform builder”，也就是基礎(chǔ)設(shè)施或者平臺(tái)級(jí)工程師。但是，長(zhǎng)期以來(lái)，我們對(duì) Kubernetes 項(xiàng)目很多時(shí)候都在錯(cuò)位使用，大量的應(yīng)用運(yùn)維人員、甚至應(yīng)用研發(fā)都在直接圍繞 Kubernetes 很底層的 API 進(jìn)行協(xié)作，這是導(dǎo)致很多人抱怨 “Kubernetes 實(shí)在是太復(fù)雜了”的根本原因之一。

這就好比一名 Java Web 工程師必須直接使用 Linux Kernel 系統(tǒng)調(diào)用來(lái)部署和管理業(yè)務(wù)代碼，自然會(huì)覺(jué)得 Linux 太復(fù)雜了。所以，目前 Kubernetes 項(xiàng)目實(shí)際上欠缺一層更高層次的封裝，來(lái)使得這個(gè)項(xiàng)目能夠?qū)ι蠈拥能浖邪l(fā)和運(yùn)維人員更加友好。

如果可以理解上述的定位，那么 Kubernetes 將 API 對(duì)象設(shè)計(jì)成 all-in-one 是合理的，這就好比 Linux Kernel 的 API，也不需要區(qū)分使用者是誰(shuí)。但是，當(dāng)開(kāi)發(fā)者真正要基于 K8s 管理應(yīng)用、并對(duì)接研發(fā)、運(yùn)維工程師時(shí)，就必然要考慮這個(gè)問(wèn)題，也必然要考慮如何做到像另一層 Linux Kernel API 那樣以標(biāo)準(zhǔn)、統(tǒng)一的方式解決這個(gè)問(wèn)題，這也是阿里云和微軟聯(lián)合開(kāi)放云原生應(yīng)用模型 Open Application Model （OAM）的原因。

有狀態(tài)應(yīng)用支持

除了天然的復(fù)雜性問(wèn)題，Kubernetes 對(duì)于有狀態(tài)應(yīng)用的支持也一直是眾多開(kāi)發(fā)者花費(fèi)大量時(shí)間研究和解決的問(wèn)題，并不是不可以支持，只是沒(méi)有相對(duì)較優(yōu)的解決方案。目前，業(yè)內(nèi)主流的針對(duì)有狀態(tài)應(yīng)用的解法是 Operator，但是編寫(xiě) Operator 其實(shí)是很困難的。

在采訪中，孫健波表示，這是因?yàn)?Operator 本質(zhì)上是一個(gè)“高級(jí)版”的 K8s 客戶端，但是 K8s API Server 的設(shè)計(jì)，是“重客戶端”的模型，這當(dāng)然是為了簡(jiǎn)化 API Server 本身的復(fù)雜度，但也導(dǎo)致了無(wú)論是 K8s client 庫(kù)，還是以此為基礎(chǔ)的 Operator，都變的異常復(fù)雜和難以理解：它們都夾雜了大量 K8s 本身的實(shí)現(xiàn)細(xì)節(jié)，比如 reflector、cache store、informer 等。這些，并不應(yīng)該是 Operator 編寫(xiě)者需要關(guān)心的，Operator 編寫(xiě)者應(yīng)該是有狀態(tài)應(yīng)用本身的領(lǐng)域?qū)＜遥ū热?TiDB 的工程師），而不應(yīng)該是 K8s 專家。這是現(xiàn)在 K8s 有狀態(tài)應(yīng)用管理最大的痛點(diǎn)，而這可能需要一個(gè)新的 Operator 框架來(lái)解決這個(gè)問(wèn)題。

另一方面，復(fù)雜應(yīng)用的支持不止編寫(xiě) Operator 這么簡(jiǎn)單，這里還需要有狀態(tài)應(yīng)用交付的技術(shù)支撐，這是目前社區(qū)上各種持續(xù)交付項(xiàng)目都有意或者無(wú)意間忽略掉的事情。事實(shí)上，持續(xù)交付一個(gè)基于 Operator 的有狀態(tài)應(yīng)用，跟交付一個(gè)無(wú)狀態(tài)的 K8s Deployment 的技術(shù)挑戰(zhàn)完全不是一個(gè)量級(jí)的。這也是孫健波所在團(tuán)隊(duì)在 CNCF 應(yīng)用交付領(lǐng)域小組（CNCF SIG App Deliver）倡導(dǎo)“應(yīng)用交付分層模型”的重要原因：如下圖所示，四層模型分別為“應(yīng)用定義”、“應(yīng)用交付”、“應(yīng)用運(yùn)維與自動(dòng)化”、“平臺(tái)層”，只有通過(guò)這四個(gè)層不同能力的合力協(xié)作，才能真正做到高質(zhì)量和高效率的交付有狀態(tài)應(yīng)用。

cdn.com/118448334b24ceab7fbd2bb01baee10398412c2a.png">

舉個(gè)例子，Kubernetes API 對(duì)象的設(shè)計(jì)是“all-in-one”的， 即：應(yīng)用管理過(guò)程中的所有參與者，都必須在同一個(gè) API 對(duì)象上進(jìn)行協(xié)作。這就導(dǎo)致開(kāi)發(fā)者會(huì)看到，像 K8s Deployment 這樣的 API 對(duì)象描述里， 既有應(yīng)用開(kāi)×××可以看到運(yùn)×××有一些字段可能還是被多×××際上，無(wú)論是應(yīng)用開(kāi)發(fā)、應(yīng)用運(yùn)維，還是 HPA 這樣的 K8s 自動(dòng)化能力，它們都有可能需要控制一個(gè) API 對(duì)象里的同一個(gè)字段。最典型的情況就是副本數(shù)（replica）這種參數(shù)。但是，到底誰(shuí) own 這個(gè)字段，是一個(gè)非常棘手的問(wèn)題。

綜上，既然 K8s 的定位是云時(shí)代的 Linux Kernel，那么 Kubernetes 就必須在 Operator 支持、API 層以及各類接口定義的完善上不斷進(jìn)行突破，使得更多生態(tài)參與者可以更好的基于 K8s 構(gòu)建自己的能力和價(jià)值。

阿里巴巴大規(guī)模 Kubernetes 實(shí)踐

如今，Kubernetes 在阿里經(jīng)濟(jì)體的應(yīng)用場(chǎng)景涵蓋了阿里方方面面的業(yè)務(wù)，包括電商、物流、離在線計(jì)算等，這也是目前支撐阿里 618、雙 11 等互聯(lián)網(wǎng)級(jí)大促的主力軍之一。阿里集團(tuán)和螞蟻金服內(nèi)部運(yùn)行了數(shù)十個(gè)超大規(guī)模的 K8s 集群，其中最大的集群約 1 萬(wàn)個(gè)機(jī)器節(jié)點(diǎn)，而且這其實(shí)還不是能力上限。每個(gè)集群都會(huì)服務(wù)上萬(wàn)個(gè)應(yīng)用。在阿里云 Kubernetes 服務(wù)（ACK）上，我們還維護(hù)了上萬(wàn)個(gè)用戶的 K8s 集群，這個(gè)規(guī)模和其中的技術(shù)挑戰(zhàn)在全世界也是首屈一指的。

孫健波透露，阿里內(nèi)部早在 2011 年便開(kāi)始了應(yīng)用容器化，當(dāng)時(shí)最開(kāi)始是基于 LXC 技術(shù)構(gòu)建容器，隨后開(kāi)始用自研的容器技術(shù)和編排調(diào)度系統(tǒng)。整套系統(tǒng)本身沒(méi)有什么問(wèn)題，但是作為基礎(chǔ)設(shè)施技術(shù)團(tuán)隊(duì)，目標(biāo)一定是希望阿里的基礎(chǔ)技術(shù)棧能夠支撐更廣泛的上層生態(tài)，能夠不斷演進(jìn)和升級(jí)，因此，整個(gè)團(tuán)隊(duì)又花了一年多時(shí)間逐漸補(bǔ)齊了 K8s 的規(guī)模和性能短板。總體來(lái)看，升級(jí)為 K8s 是一個(gè)非常自然的過(guò)程，整個(gè)實(shí)踐過(guò)程其實(shí)也很簡(jiǎn)單：

• 第一：解決應(yīng)用容器化的問(wèn)題，這里需要合理利用 K8s 的容器設(shè)計(jì)模式；
• 第二：解決應(yīng)用定義與描述的問(wèn)題，這里需要合理的利用 OAM，Helm 等應(yīng)用定義工具和模型來(lái)實(shí)現(xiàn)，并且要能夠?qū)蝇F(xiàn)有的應(yīng)用管理能力；
• 第三：構(gòu)建完整的應(yīng)用交付鏈，這里可以考慮使用和集成各種持續(xù)交付能力。

如上的三步完成，就具備了對(duì)接研發(fā)、運(yùn)維、上層 PaaS 的能力，能夠講清楚自己的平臺(tái)價(jià)值。接下來(lái)就可以試點(diǎn)開(kāi)始，在不影響現(xiàn)有應(yīng)用管理體系的前提下，一步步換掉下面的基礎(chǔ)設(shè)施。

Kubernetes 本身并不提供完整的應(yīng)用管理體系，這個(gè)體系是整個(gè)云原生的生態(tài)基于 K8s 構(gòu)建出來(lái)的，可以用下圖表示：

Helm 就是其中最成功的一個(gè)例子，它位于整個(gè)應(yīng)用管理體系的最上面，也就是第 1 層，還有 Kustomize 等各種 YAML 管理工具，CNAB 等打包工具，它們都對(duì)應(yīng)在第 1.5 層。然后有 Tekton、Flagger 、Kepton 等應(yīng)用交付項(xiàng)目，對(duì)應(yīng)在第 2 層。Operator ，以及 K8s 的各種工作負(fù)載組件，比如 Deployment、StatefulSet，對(duì)應(yīng)在第 3 層。最后才是 K8s 的核心功能，負(fù)責(zé)對(duì)工作負(fù)載的容器進(jìn)行管理，封裝基礎(chǔ)設(shè)施能力，對(duì)各種不同的工作負(fù)載對(duì)接底層基礎(chǔ)設(shè)施提供 API 等。

初期，整個(gè)團(tuán)隊(duì)最大的挑戰(zhàn)來(lái)自于規(guī)模和性能瓶頸，但這個(gè)解法也是最直接的。孫健波表示，隨著規(guī)模逐漸增大，我們看到規(guī)?；侀_(kāi) K8s 最大的挑戰(zhàn)實(shí)際上是如何基于 K8s 進(jìn)行應(yīng)用管理和對(duì)接上層生態(tài)。比如，我們需要統(tǒng)一的管控來(lái)自數(shù)十個(gè)團(tuán)隊(duì)、數(shù)百個(gè)不同目的的 Controller；我們需要以每天近萬(wàn)次的頻率交付來(lái)自不同團(tuán)隊(duì)的生產(chǎn)級(jí)應(yīng)用，這些應(yīng)用的發(fā)布、擴(kuò)容策略可能完全不同；我們還需要對(duì)接數(shù)十個(gè)更加復(fù)雜的上層平臺(tái)，混合調(diào)度和部署不同形態(tài)的作業(yè)以追求最高的資源利用率，這些訴求才是阿里巴巴 Kubernetes 實(shí)踐要解決的問(wèn)題，規(guī)模和性能只是其中一個(gè)組成部分。

除了 Kubernetes 的原生功能外，在阿里巴巴內(nèi)部會(huì)開(kāi)發(fā)大量的基礎(chǔ)設(shè)施以 K8s 插件的形式對(duì)接到這些功能上，隨著規(guī)模的擴(kuò)大，用統(tǒng)一的方式發(fā)現(xiàn)和管理這些能力成為了一個(gè)關(guān)鍵問(wèn)題。

此外，阿里巴巴內(nèi)部也有眾多存量 PaaS，這些是為了滿足用戶不同業(yè)務(wù)場(chǎng)景上云所構(gòu)建的，比如有的用戶希望上傳一個(gè) Java 的 War 包就可以運(yùn)行，有的用戶希望上傳一個(gè)鏡像就可以運(yùn)行。在這些需求背后，阿里各團(tuán)隊(duì)幫用戶做了許多應(yīng)用管理的工作，這也是存量 PaaS 出現(xiàn)的原因，而這些存量 PaaS 與 Kubernetes 對(duì)接過(guò)程可能會(huì)產(chǎn)生各種問(wèn)題。目前，阿里正在通過(guò) OAM 這個(gè)統(tǒng)一標(biāo)準(zhǔn)的應(yīng)用管理模型，幫助這些 PaaS 向 K8s 底盤(pán)進(jìn)行對(duì)接和靠攏，實(shí)現(xiàn)標(biāo)準(zhǔn)化和云原生化。

解耦運(yùn)維和研發(fā)

通過(guò)解耦，Kubernetes 項(xiàng)目以及對(duì)應(yīng)的云服務(wù)商就可以為不同的角色暴露不同維度、更符合對(duì)應(yīng)用戶訴求的聲明式 API。比如，應(yīng)用開(kāi)發(fā)者只需要在 YAML 文件中聲明”應(yīng)用 A 要使用 5G 可讀寫(xiě)空間“，應(yīng)用運(yùn)維人員則只需要在對(duì)應(yīng)的 YAML 文件里聲明”P(pán)od A 要掛載 5G 的可讀寫(xiě)數(shù)據(jù)卷“。這種”讓用戶只關(guān)心自己所關(guān)心的事情“所帶來(lái)的專注力，是降低 Kubernetes 使用者學(xué)習(xí)門(mén)檻和上手難度的關(guān)鍵所在。

孫健波表示，現(xiàn)在大多數(shù)的解法實(shí)際上是“悲觀處理”。比如，阿里內(nèi)部的 PaaS 平臺(tái)，為了減輕研發(fā)使用的負(fù)擔(dān)，長(zhǎng)期以來(lái)只開(kāi)放給研發(fā)設(shè)置 5 個(gè) Deployment 的字段。這當(dāng)然是因?yàn)?K8s YAML "all-in-one"的設(shè)計(jì)，使得完整的 YAML 對(duì)研發(fā)來(lái)說(shuō)太復(fù)雜，但這也導(dǎo)致 K8s 本身的能力，絕大多數(shù)情況下對(duì)研發(fā)來(lái)說(shuō)是完全沒(méi)有體感的。而對(duì) PaaS 平臺(tái)運(yùn)維來(lái)說(shuō)，他反而覺(jué)得 K8s YAML 太簡(jiǎn)單，不夠描述平臺(tái)的運(yùn)維能力，所以要給 YAML 文件添加大量 annotation。

此外，這里的核心問(wèn)題在于，對(duì)運(yùn)維人員而言，這種“悲觀處理”的結(jié)果就是他自己太“獨(dú)裁”，包攬了大量細(xì)節(jié)工作，還費(fèi)力不討好。比如擴(kuò)容策略，目前就是完全由運(yùn)維一方說(shuō)了算?？墒?，研發(fā)作為編寫(xiě)代碼的實(shí)際人員，才是對(duì)應(yīng)用怎么擴(kuò)容最有發(fā)言權(quán)的，而且研發(fā)人員也非常希望把自己的意見(jiàn)告訴運(yùn)維，好讓 K8s 更加 靈活，真正滿足擴(kuò)容需求。但這個(gè)訴求在目前的系統(tǒng)里是無(wú)法實(shí)現(xiàn)的。

所以，“研發(fā)和運(yùn)維解耦”并不是要把兩者割裂，而是要給研發(fā)提供一個(gè)標(biāo)準(zhǔn)、高效的，同運(yùn)維進(jìn)行溝通的方式，這也是 OAM 應(yīng)用管理模型要解決的問(wèn)題。孫健波表示，OAM 的主要作用之一就是提供一套研發(fā)從自己的角度表達(dá)訴求的標(biāo)準(zhǔn)和規(guī)范，然后這套標(biāo)準(zhǔn)“你知，我知，系統(tǒng)知”，那么上面這些問(wèn)題也就迎刃而解了。

具體來(lái)說(shuō)，OAM 是一個(gè)專注于描述應(yīng)用的標(biāo)準(zhǔn)規(guī)范。有了這個(gè)規(guī)范，應(yīng)用描述就可以徹底與基礎(chǔ)設(shè)施部署和管理應(yīng)用的細(xì)節(jié)分開(kāi)。這×××eperation of Conerns）的設(shè)計(jì)好處是非常明顯的。舉個(gè)例子，在實(shí)際生產(chǎn)環(huán)境中，無(wú)論是 Ingress、CNI 還是 Service Mesh，這些表面看起來(lái)一致的運(yùn)維概念，在不同的 Kubernetes 集群中可謂千差萬(wàn)別。通過(guò)將應(yīng)用定義與集群的運(yùn)維能力分離，我們就可以讓?xiě)?yīng)用開(kāi)發(fā)者更專注應(yīng)用本身的價(jià)值點(diǎn)，而不是”應(yīng)用部署在哪“這樣的運(yùn)維細(xì)節(jié)。

此外×××臺(tái)架構(gòu)師可以輕松地把平臺(tái)運(yùn)維能力封裝成可被復(fù)用的組件，從而讓?xiě)?yīng)用開(kāi)發(fā)者專注于將這些運(yùn)維組件與代碼進(jìn)行集成，從而快速、輕松地構(gòu)建可信賴的應(yīng)用。OAM 的目標(biāo)是讓簡(jiǎn)單的應(yīng)用管理變得更加輕松，讓復(fù)雜的應(yīng)用交付變得更加可控。孫健波表示，未來(lái)，團(tuán)隊(duì)將專注于將這套體系逐步向云端 ISV 和軟件分發(fā)商側(cè)推進(jìn)，讓基于 K8s 的應(yīng)用管理體系真正成為云時(shí)代的主流。

嘉賓介紹：孫健波，阿里巴巴技術(shù)專家。Kubernetes 項(xiàng)目社區(qū)成員。目前在阿里巴巴參與大規(guī)模云原生應(yīng)用交付與管理相關(guān)工作，2015 年參與編寫(xiě)《Docker 容器與容器云》技術(shù)書(shū)籍。曾任職七牛，參與過(guò)時(shí)序數(shù)據(jù)庫(kù)、流式計(jì)算、日志平臺(tái)等項(xiàng)目相關(guān)應(yīng)用上云過(guò)程。

今年 12 月 6-7 日北京 ArchSummit 全球架構(gòu)師峰會(huì)上，孫健波老師會(huì)繼續(xù)分享《阿里巴巴 Kubernetes 應(yīng)用管理實(shí)踐中的經(jīng)驗(yàn)與教訓(xùn)》，會(huì)介紹阿里對(duì)解耦研發(fā)和運(yùn)維過(guò)程中的現(xiàn)有實(shí)踐，以及實(shí)踐本身存在的問(wèn)題；以及實(shí)施的標(biāo)準(zhǔn)化、統(tǒng)一化解決的思路，以及對(duì)社區(qū)的進(jìn)一步思考。

“ 阿里巴巴云×××icloudnative×××erverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開(kāi)發(fā)×××詳細(xì)信息×××巴云原生”](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487322&idx=1&sn=a179a68918f599cba0f0ce579f17028e&chksm=fae50495cd928d83da512177b7ee591cec05f51f1a6151c8ac5650eb5a996ccd757c15466cda&token=4897735&lang=zh_CN#rd)。