作者 | 孫健波（阿里巴巴技術(shù)專家）、趙鈺瑩
導(dǎo)讀：云原生時代，Kubernetes 的重要性日益凸顯。然而，大多數(shù)互聯(lián)網(wǎng)公司在 Kubernetes 上的探索并非想象中順利，Kubernetes 自帶的復(fù)雜性足以讓一批開發(fā)者望而卻步。本文中，阿里巴巴技術(shù)專家孫健波在接受采訪時基于阿里巴巴 Kubernetes 應(yīng)用管理實踐過程提供了一些經(jīng)驗與建議，以期對開發(fā)者有所幫助。
在互聯(lián)網(wǎng)時代中，開發(fā)者更多是通過頂層架構(gòu)設(shè)計，比如多集群部署和分布式架構(gòu)的方式來實現(xiàn)出現(xiàn)資源相關(guān)問題時的快速切換，做了很多事情來讓彈性變得更加簡單，并通過混部計算任務(wù)來提高資源利用率，云計算的出現(xiàn)則解決了從 CAPEX 到 OPEX 的轉(zhuǎn)變問題。
云計算時代讓開發(fā)可以聚焦在應(yīng)用價值本身，相較于以前開發(fā)者除了業(yè)務(wù)模塊還要投入大量精力在存儲、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施，如今這些基礎(chǔ)設(shè)施都已經(jīng)像水電煤一樣便捷易用。云計算的基礎(chǔ)設(shè)施具有穩(wěn)定、高可用、彈性伸縮等一系列能力，除此之外還配套解決了一系列應(yīng)用開發(fā)“最佳實踐”的問題，比如監(jiān)控、審計、日志分析、灰度發(fā)布等。原來，一個工程師需要非常全面才能做好一個高可靠的應(yīng)用，現(xiàn)在只要了解足夠多的基礎(chǔ)設(shè)施產(chǎn)品，這些最佳實踐就可以信手拈來了。但是，在面對天然復(fù)雜的 Kubernetes 時，很多開發(fā)者都無能為力。
作為 Jira 和代碼庫 Bitbucket 背后的公司，Atlassian 的 Kubernetes 團隊首席工程師 Nick Young 在采訪中表示：
雖然當(dāng)初選擇 Kubernetes 的戰(zhàn)略是正確的（至少到現(xiàn)在也沒有發(fā)現(xiàn)其他可能的選擇），解決了現(xiàn)階段遇到的許多問題，但部署過程異常艱辛。
那么，有好的解決辦法嗎？
“如果讓我說 Kubernetes 存在的問題，當(dāng)然是‘太復(fù)雜了’”，孫健波在采訪中說道，“不過，這其實是由于 Kubernetes 本身的定位導(dǎo)致的。”
孫健波補充道，Kubernetes 的定位是“platform for platform”。它的直接用戶，既不是應(yīng)用開發(fā)者，也不是應(yīng)用運維，而是“platform builder”，也就是基礎(chǔ)設(shè)施或者平臺級工程師。但是，長期以來，我們對 Kubernetes 項目很多時候都在錯位使用，大量的應(yīng)用運維人員、甚至應(yīng)用研發(fā)都在直接圍繞 Kubernetes 很底層的 API 進行協(xié)作，這是導(dǎo)致很多人抱怨 “Kubernetes 實在是太復(fù)雜了”的根本原因之一。
這就好比一名 Java Web 工程師必須直接使用 Linux Kernel 系統(tǒng)調(diào)用來部署和管理業(yè)務(wù)代碼，自然會覺得 Linux 太復(fù)雜了。所以，目前 Kubernetes 項目實際上欠缺一層更高層次的封裝，來使得這個項目能夠?qū)ι蠈拥能浖邪l(fā)和運維人員更加友好。
如果可以理解上述的定位，那么 Kubernetes 將 API 對象設(shè)計成 all-in-one 是合理的，這就好比 Linux Kernel 的 API，也不需要區(qū)分使用者是誰。但是，當(dāng)開發(fā)者真正要基于 K8s 管理應(yīng)用、并對接研發(fā)、運維工程師時，就必然要考慮這個問題，也必然要考慮如何做到像另一層 Linux Kernel API 那樣以標(biāo)準(zhǔn)、統(tǒng)一的方式解決這個問題，這也是阿里云和微軟聯(lián)合開放云原生應(yīng)用模型 Open Application Model （OAM）的原因。
除了天然的復(fù)雜性問題，Kubernetes 對于有狀態(tài)應(yīng)用的支持也一直是眾多開發(fā)者花費大量時間研究和解決的問題，并不是不可以支持，只是沒有相對較優(yōu)的解決方案。目前，業(yè)內(nèi)主流的針對有狀態(tài)應(yīng)用的解法是 Operator，但是編寫 Operator 其實是很困難的。
在采訪中，孫健波表示，這是因為 Operator 本質(zhì)上是一個“高級版”的 K8s 客戶端，但是 K8s API Server 的設(shè)計，是“重客戶端”的模型，這當(dāng)然是為了簡化 API Server 本身的復(fù)雜度，但也導(dǎo)致了無論是 K8s client 庫，還是以此為基礎(chǔ)的 Operator，都變的異常復(fù)雜和難以理解：它們都夾雜了大量 K8s 本身的實現(xiàn)細(xì)節(jié)，比如 reflector、cache store、informer 等。這些，并不應(yīng)該是 Operator 編寫者需要關(guān)心的，Operator 編寫者應(yīng)該是有狀態(tài)應(yīng)用本身的領(lǐng)域?qū)＜遥ū热?TiDB 的工程師），而不應(yīng)該是 K8s 專家。這是現(xiàn)在 K8s 有狀態(tài)應(yīng)用管理大的痛點，而這可能需要一個新的 Operator 框架來解決這個問題。
另一方面，復(fù)雜應(yīng)用的支持不止編寫 Operator 這么簡單，這里還需要有狀態(tài)應(yīng)用交付的技術(shù)支撐，這是目前社區(qū)上各種持續(xù)交付項目都有意或者無意間忽略掉的事情。事實上，持續(xù)交付一個基于 Operator 的有狀態(tài)應(yīng)用，跟交付一個無狀態(tài)的 K8s Deployment 的技術(shù)挑戰(zhàn)完全不是一個量級的。這也是孫健波所在團隊在 CNCF 應(yīng)用交付領(lǐng)域小組（CNCF SIG App Deliver）倡導(dǎo)“應(yīng)用交付分層模型”的重要原因：如下圖所示，四層模型分別為“應(yīng)用定義”、“應(yīng)用交付”、“應(yīng)用運維與自動化”、“平臺層”，只有通過這四個層不同能力的合力協(xié)作，才能真正做到高質(zhì)量和高效率的交付有狀態(tài)應(yīng)用。
舉個例子，Kubernetes API 對象的設(shè)計是“all-in-one”的， 即：應(yīng)用管理過程中的所有參與者，都必須在同一個 API 對象上進行協(xié)作。這就導(dǎo)致開發(fā)者會看到，像 K8s Deployment 這樣的 API 對象描述里， 既有應(yīng)用開×××可以看到運×××有一些字段可能還是被多×××際上，無論是應(yīng)用開發(fā)、應(yīng)用運維，還是 HPA 這樣的 K8s 自動化能力，它們都有可能需要控制一個 API 對象里的同一個字段。最典型的情況就是副本數(shù)（replica）這種參數(shù)。但是，到底誰 own 這個字段，是一個非常棘手的問題。
綜上，既然 K8s 的定位是云時代的 Linux Kernel，那么 Kubernetes 就必須在 Operator 支持、API 層以及各類接口定義的完善上不斷進行突破，使得更多生態(tài)參與者可以更好的基于 K8s 構(gòu)建自己的能力和價值。
如今，Kubernetes 在阿里經(jīng)濟體的應(yīng)用場景涵蓋了阿里方方面面的業(yè)務(wù)，包括電商、物流、離在線計算等，這也是目前支撐阿里 618、雙 11 等互聯(lián)網(wǎng)級大促的主力軍之一。阿里集團和螞蟻金服內(nèi)部運行了數(shù)十個超大規(guī)模的 K8s 集群，其中大的集群約 1 萬個機器節(jié)點，而且這其實還不是能力上限。每個集群都會服務(wù)上萬個應(yīng)用。在阿里云 Kubernetes 服務(wù)（ACK）上，我們還維護了上萬個用戶的 K8s 集群，這個規(guī)模和其中的技術(shù)挑戰(zhàn)在全世界也是首屈一指的。
孫健波透露，阿里內(nèi)部早在 2011 年便開始了應(yīng)用容器化，當(dāng)時最開始是基于 LXC 技術(shù)構(gòu)建容器，隨后開始用自研的容器技術(shù)和編排調(diào)度系統(tǒng)。整套系統(tǒng)本身沒有什么問題，但是作為基礎(chǔ)設(shè)施技術(shù)團隊，目標(biāo)一定是希望阿里的基礎(chǔ)技術(shù)棧能夠支撐更廣泛的上層生態(tài)，能夠不斷演進和升級，因此，整個團隊又花了一年多時間逐漸補齊了 K8s 的規(guī)模和性能短板?？傮w來看，升級為 K8s 是一個非常自然的過程，整個實踐過程其實也很簡單：
如上的三步完成，就具備了對接研發(fā)、運維、上層 PaaS 的能力，能夠講清楚自己的平臺價值。接下來就可以試點開始，在不影響現(xiàn)有應(yīng)用管理體系的前提下，一步步換掉下面的基礎(chǔ)設(shè)施。
Kubernetes 本身并不提供完整的應(yīng)用管理體系，這個體系是整個云原生的生態(tài)基于 K8s 構(gòu)建出來的，可以用下圖表示：
Helm 就是其中最成功的一個例子，它位于整個應(yīng)用管理體系的最上面，也就是第 1 層，還有 Kustomize 等各種 YAML 管理工具，CNAB 等打包工具，它們都對應(yīng)在第 1.5 層。然后有 Tekton、Flagger 、Kepton 等應(yīng)用交付項目，對應(yīng)在第 2 層。Operator ，以及 K8s 的各種工作負(fù)載組件，比如 Deployment、StatefulSet，對應(yīng)在第 3 層。最后才是 K8s 的核心功能，負(fù)責(zé)對工作負(fù)載的容器進行管理，封裝基礎(chǔ)設(shè)施能力，對各種不同的工作負(fù)載對接底層基礎(chǔ)設(shè)施提供 API 等。
初期，整個團隊大的挑戰(zhàn)來自于規(guī)模和性能瓶頸，但這個解法也是最直接的。孫健波表示，隨著規(guī)模逐漸增大，我們看到規(guī)模化鋪開 K8s 大的挑戰(zhàn)實際上是如何基于 K8s 進行應(yīng)用管理和對接上層生態(tài)。比如，我們需要統(tǒng)一的管控來自數(shù)十個團隊、數(shù)百個不同目的的 Controller；我們需要以每天近萬次的頻率交付來自不同團隊的生產(chǎn)級應(yīng)用，這些應(yīng)用的發(fā)布、擴容策略可能完全不同；我們還需要對接數(shù)十個更加復(fù)雜的上層平臺，混合調(diào)度和部署不同形態(tài)的作業(yè)以追求高的資源利用率，這些訴求才是阿里巴巴 Kubernetes 實踐要解決的問題，規(guī)模和性能只是其中一個組成部分。
除了 Kubernetes 的原生功能外，在阿里巴巴內(nèi)部會開發(fā)大量的基礎(chǔ)設(shè)施以 K8s 插件的形式對接到這些功能上，隨著規(guī)模的擴大，用統(tǒng)一的方式發(fā)現(xiàn)和管理這些能力成為了一個關(guān)鍵問題。
此外，阿里巴巴內(nèi)部也有眾多存量 PaaS，這些是為了滿足用戶不同業(yè)務(wù)場景上云所構(gòu)建的，比如有的用戶希望上傳一個 Java 的 War 包就可以運行，有的用戶希望上傳一個鏡像就可以運行。在這些需求背后，阿里各團隊幫用戶做了許多應(yīng)用管理的工作，這也是存量 PaaS 出現(xiàn)的原因，而這些存量 PaaS 與 Kubernetes 對接過程可能會產(chǎn)生各種問題。目前，阿里正在通過 OAM 這個統(tǒng)一標(biāo)準(zhǔn)的應(yīng)用管理模型，幫助這些 PaaS 向 K8s 底盤進行對接和靠攏，實現(xiàn)標(biāo)準(zhǔn)化和云原生化。
通過解耦，Kubernetes 項目以及對應(yīng)的云服務(wù)商就可以為不同的角色暴露不同維度、更符合對應(yīng)用戶訴求的聲明式 API。比如，應(yīng)用開發(fā)者只需要在 YAML 文件中聲明”應(yīng)用 A 要使用 5G 可讀寫空間“，應(yīng)用運維人員則只需要在對應(yīng)的 YAML 文件里聲明”Pod A 要掛載 5G 的可讀寫數(shù)據(jù)卷“。這種”讓用戶只關(guān)心自己所關(guān)心的事情“所帶來的專注力，是降低 Kubernetes 使用者學(xué)習(xí)門檻和上手難度的關(guān)鍵所在。
孫健波表示，現(xiàn)在大多數(shù)的解法實際上是“悲觀處理”。比如，阿里內(nèi)部的 PaaS 平臺，為了減輕研發(fā)使用的負(fù)擔(dān)，長期以來只開放給研發(fā)設(shè)置 5 個 Deployment 的字段。這當(dāng)然是因為 K8s YAML "all-in-one"的設(shè)計，使得完整的 YAML 對研發(fā)來說太復(fù)雜，但這也導(dǎo)致 K8s 本身的能力，絕大多數(shù)情況下對研發(fā)來說是完全沒有體感的。而對 PaaS 平臺運維來說，他反而覺得 K8s YAML 太簡單，不夠描述平臺的運維能力，所以要給 YAML 文件添加大量 annotation。
此外，這里的核心問題在于，對運維人員而言，這種“悲觀處理”的結(jié)果就是他自己太“獨裁”，包攬了大量細(xì)節(jié)工作，還費力不討好。比如擴容策略，目前就是完全由運維一方說了算。可是，研發(fā)作為編寫代碼的實際人員，才是對應(yīng)用怎么擴容最有發(fā)言權(quán)的，而且研發(fā)人員也非常希望把自己的意見告訴運維，好讓 K8s 更加 靈活，真正滿足擴容需求。但這個訴求在目前的系統(tǒng)里是無法實現(xiàn)的。
所以，“研發(fā)和運維解耦”并不是要把兩者割裂，而是要給研發(fā)提供一個標(biāo)準(zhǔn)、高效的，同運維進行溝通的方式，這也是 OAM 應(yīng)用管理模型要解決的問題。孫健波表示，OAM 的主要作用之一就是提供一套研發(fā)從自己的角度表達(dá)訴求的標(biāo)準(zhǔn)和規(guī)范，然后這套標(biāo)準(zhǔn)“你知，我知，系統(tǒng)知”，那么上面這些問題也就迎刃而解了。
具體來說，OAM 是一個專注于描述應(yīng)用的標(biāo)準(zhǔn)規(guī)范。有了這個規(guī)范，應(yīng)用描述就可以徹底與基礎(chǔ)設(shè)施部署和管理應(yīng)用的細(xì)節(jié)分開。這×××eperation of Conerns）的設(shè)計好處是非常明顯的。舉個例子，在實際生產(chǎn)環(huán)境中，無論是 Ingress、CNI 還是 Service Mesh，這些表面看起來一致的運維概念，在不同的 Kubernetes 集群中可謂千差萬別。通過將應(yīng)用定義與集群的運維能力分離，我們就可以讓應(yīng)用開發(fā)者更專注應(yīng)用本身的價值點，而不是”應(yīng)用部署在哪“這樣的運維細(xì)節(jié)。
此外×××臺架構(gòu)師可以輕松地把平臺運維能力封裝成可被復(fù)用的組件，從而讓應(yīng)用開發(fā)者專注于將這些運維組件與代碼進行集成，從而快速、輕松地構(gòu)建可信賴的應(yīng)用。OAM 的目標(biāo)是讓簡單的應(yīng)用管理變得更加輕松，讓復(fù)雜的應(yīng)用交付變得更加可控。孫健波表示，未來，團隊將專注于將這套體系逐步向云端 ISV 和軟件分發(fā)商側(cè)推進，讓基于 K8s 的應(yīng)用管理體系真正成為云時代的主流。
嘉賓介紹：孫健波，阿里巴巴技術(shù)專家。Kubernetes 項目社區(qū)成員。目前在阿里巴巴參與大規(guī)模云原生應(yīng)用交付與管理相關(guān)工作，2015 年參與編寫《Docker 容器與容器云》技術(shù)書籍。曾任職七牛，參與過時序數(shù)據(jù)庫、流式計算、日志平臺等項目相關(guān)應(yīng)用上云過程。
今年 12 月 6-7 日北京 ArchSummit 全球架構(gòu)師峰會上，孫健波老師會繼續(xù)分享《阿里巴巴 Kubernetes 應(yīng)用管理實踐中的經(jīng)驗與教訓(xùn)》，會介紹阿里對解耦研發(fā)和運維過程中的現(xiàn)有實踐，以及實踐本身存在的問題；以及實施的標(biāo)準(zhǔn)化、統(tǒng)一化解決的思路，以及對社區(qū)的進一步思考。
“ 阿里巴巴云×××icloudnative×××erverless、容器、Service Mesh等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)×××詳細(xì)信息×××巴云原生”](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247487322&idx=1&sn=a179a68918f599cba0f0ce579f17028e&chksm=fae50495cd928d83da512177b7ee591cec05f51f1a6151c8ac5650eb5a996ccd757c15466cda&token=4897735&lang=zh_CN#rd)。
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
重慶分公司
重慶分公司
