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

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

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

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

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

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

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

太過復雜的 Kubernetes

“如果讓我說 Kubernetes 存在的問題，當然是‘太復雜了’”，孫健波在采訪中說道，“不過，這其實是由于 Kubernetes 本身的定位導致的?！?/span>

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

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

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

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

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

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

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

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

實際上，無論是應用開發(fā)、應用運維，還是 HPA 這樣的 K8s 自動化能力，它們都有可能需要控制一個 API 對象里的同一個字段。最典型的情況就是副本數(shù)（replica）這種參數(shù)。但是，到底誰 own 這個字段，是一個非常棘手的問題。

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

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

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

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

• 第一：解決應用容器化的問題，這里需要合理利用 K8s 的容器設計模式；

• 第二：解決應用定義與描述的問題，這里需要合理的利用 OAM，Helm 等應用定義工具和模型來實現(xiàn)，并且要能夠?qū)蝇F(xiàn)有的應用管理能力；

• 第三：構(gòu)建完整的應用交付鏈，這里可以考慮使用和集成各種持續(xù)交付能力。

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

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

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

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

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

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

解耦運維和研發(fā)

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

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

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

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

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

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

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

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

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。