作者 | 孫健波（天元）? 阿里巴巴技術(shù)專家

導(dǎo)讀：本文整理自孫健波在 ArchSummit 大會(huì) 2019 北京站演講稿記錄。首先介紹了阿里巴巴基于 Kubernetes 項(xiàng)目進(jìn)行大規(guī)模應(yīng)用實(shí)踐過程中遇到的問題；隨后會(huì)逐一介紹解決這些問題的現(xiàn)有實(shí)踐及其本身存在的局限性；最后會(huì)介紹阿里巴巴目前正在進(jìn)行的嘗試和社區(qū)在這一領(lǐng)域的發(fā)展方向。

如今，阿里巴巴內(nèi)部維護(hù)了數(shù)十個(gè)大規(guī)模的 K8s 集群，其中最大的集群約 1 萬個(gè)節(jié)點(diǎn)，每個(gè)集群會(huì)服務(wù)上萬個(gè)應(yīng)用；在阿里云的 Kubernetes 服務(wù) ACK 上，我們還維護(hù)了上萬個(gè)用戶的 K8s 集群。我們?cè)谝欢ǔ潭壬辖鉀Q了規(guī)模和穩(wěn)定性問題之后，發(fā)現(xiàn)其實(shí)在 K8s 上管理應(yīng)用還有很大的挑戰(zhàn)等著我們。

應(yīng)用管理的兩大難題

今天我們主要討論這兩個(gè)方面的挑戰(zhàn)：

• 對(duì)應(yīng)用研發(fā)而言，K8s API 針對(duì)簡(jiǎn)單應(yīng)用過于復(fù)雜，針對(duì)復(fù)雜應(yīng)用難以上手；
• 對(duì)應(yīng)用運(yùn)維而言，K8s 的擴(kuò)展能力難以管理；K8s 原生的 API 沒有對(duì)云資源全部涵蓋。

總體而言，我們面臨的挑戰(zhàn)就是：如何基于 K8s 提供真正意義上的應(yīng)用管理平臺(tái)，讓研發(fā)和運(yùn)維只需關(guān)注到應(yīng)用本身。

研發(fā)對(duì)應(yīng)用管理的訴求

K8s all in one 的 YAML 文件

讓我們來看一下這樣一個(gè) K8s 的 yaml 文件，這個(gè) yaml 文件已經(jīng)是被簡(jiǎn)化過的，但是我們可以看到它仍然還是比較長(zhǎng)。

面對(duì)這樣一個(gè)廣受“復(fù)雜”詬病的 YAML 文件，我相信大家都會(huì)忍不住想該怎么簡(jiǎn)化。

自上而下，我們大致把它們分為三塊：

• 一塊是擴(kuò)縮容、滾動(dòng)升級(jí)相關(guān)的參數(shù)，這一塊應(yīng)該是應(yīng)用運(yùn)維的同學(xué)比較關(guān)心的；
• 然后中間一塊是鏡像、端口、啟動(dòng)參數(shù)相關(guān)的，這一塊應(yīng)該是開發(fā)的同學(xué)比較關(guān)心的；
• 最后一塊大家可能根本看不懂，通常情況下也不太需要明白，可以把它們理解為 K8s 平臺(tái)層的同學(xué)需要關(guān)心的。

看到這樣一個(gè) yaml 文件，我們很容易想到，只要把里面的字段封裝一下，把該暴露的暴露出來就好了。確實(shí)，我們內(nèi)部就有 PaaS 平臺(tái)這么做。

只透出部分字段：簡(jiǎn)單卻能力不足

內(nèi)部的某個(gè) PaaS 平臺(tái)精心挑選了部分字段，并做了一個(gè)漂亮的前端界面給用戶，只透出給用戶 5 個(gè)左右的字段，大大降低了用戶理解 K8s 的心智負(fù)擔(dān)。然后底層實(shí)現(xiàn)用類似模板的方式把用戶這五個(gè)字段渲染出來一個(gè)完整的 yaml 文件。突出的字段大概如下圖所示：

不得不說這種方式是非常有效的，針對(duì)簡(jiǎn)單無狀態(tài)的應(yīng)用，精簡(jiǎn) API 可以大大降低 K8s 的門檻，快速并且高效的對(duì)接用戶，PaaS 平臺(tái)也順利讓大家使用了起來。同時(shí)，我也從一些技術(shù)分享中了解到許多其他公司也是用這種類似的方式簡(jiǎn)化的 K8s API。

但是當(dāng)用戶的業(yè)務(wù)開始大規(guī)模對(duì)接以后，我們就會(huì)自然而然遇到有狀態(tài)的復(fù)雜應(yīng)用，用戶就會(huì)開始抱怨 PaaS 平臺(tái)能力不夠了。比如我們的 Zookeeper 多實(shí)例選主、主從切換這些邏輯，在這五個(gè)字段里就很難展開了。

歸根結(jié)底就是屏蔽大量字段的方式會(huì)限制基礎(chǔ)設(shè)施本身的能力演進(jìn)，但是 K8s 的能力是非常強(qiáng)大而靈活的。我們不可能為了簡(jiǎn)化而放棄掉 K8s 強(qiáng)大的能力。

就比如當(dāng)前這個(gè)例子，我們很容易想到，針對(duì)復(fù)雜有狀態(tài)的應(yīng)用，應(yīng)該通過 K8s 里面的 CRD 和 Operator 來解決。
、

CRD Operator: K8s 擴(kuò)展能力強(qiáng)大卻難以上手

確實(shí)，我們內(nèi)部對(duì)接復(fù)雜應(yīng)用云原生化的時(shí)候，也推薦他們編寫 Operator，但是經(jīng)常出現(xiàn)這樣一段對(duì)話。

中間件的工程師跟我們說，我這有個(gè) Zookeeper 該用哪種 K8s 的 Workload 接入啊？ 我們想了想，K8s 設(shè)計(jì)如此精妙，自然沒有解決不了的問題，于是我們推薦他們使用 Operator。他們就懵了，說你們搞云原生的這幾年造新詞的能力絕對(duì)一流，之前都沒聽說過。

想想也是，業(yè)務(wù)方理解這些新概念不難，但是真的要自己去上手實(shí)現(xiàn)，還是非常困難的。我們自然也覺得業(yè)務(wù)方更應(yīng)該專注于他們的業(yè)務(wù)本身，于是我們不得不幫他們一起寫。

可以看到，我們亟需一個(gè)統(tǒng)一的模型去解決研發(fā)對(duì)應(yīng)用管理的訴求。

運(yùn)維對(duì)應(yīng)用管理的訴求

除了研發(fā)側(cè)的問題之外，我們?cè)谶\(yùn)維側(cè)也遇到了很大的挑戰(zhàn)。

運(yùn)維能力眾多卻難以管理

K8s 的 CRD Operator 機(jī)制非常靈活而強(qiáng)大，不光是復(fù)雜應(yīng)用可以通過編寫 CRD Operator 實(shí)現(xiàn)，我們的運(yùn)維能力也大量通過 Operator 來擴(kuò)展，比如灰度發(fā)布、流量管理、彈性擴(kuò)縮容等等。我們常常贊嘆于 K8s 的靈活性，它讓我們基礎(chǔ)平臺(tái)團(tuán)隊(duì)對(duì)外提供能力非常方便，但是對(duì)應(yīng)用運(yùn)維來說，他們要使用我們提供的這些運(yùn)維能力，卻變得有些困難。

比如我們上線了一個(gè) CronHPA，可以定時(shí)設(shè)置在每個(gè)階段會(huì)根據(jù) CPU 調(diào)整實(shí)例數(shù)的范圍。應(yīng)用運(yùn)維并不知道跟原生不帶定時(shí)功能的 HPA 會(huì)產(chǎn)生沖突，而我們也沒有一個(gè)統(tǒng)一的渠道幫助管理這么多種復(fù)雜的擴(kuò)展能力，結(jié)果自然是引起了故障。這血的教訓(xùn)提醒我們要做事前檢查，熟悉 K8s 的機(jī)制很容易讓我們想到為每個(gè) Operator 加上 admission webhook。

這個(gè) admission webhook 需要拿到這個(gè)應(yīng)用綁定的所有運(yùn)維能力以及應(yīng)用本身的運(yùn)行模式，然后做統(tǒng)一的校驗(yàn)。如果這些運(yùn)維能力都是一方提供的還好，如果存在兩方，甚至三方提供的擴(kuò)展能力，我們就沒有一個(gè)統(tǒng)一的方式去獲知了。事實(shí)上如果我們想的更遠(yuǎn)一些就會(huì)發(fā)現(xiàn)，我們需要一個(gè)統(tǒng)一的模型來協(xié)商并管理這些復(fù)雜的擴(kuò)展能力。

云資源難以描述和統(tǒng)一交付

當(dāng)我們把應(yīng)用的 Operator 以及對(duì)應(yīng)的運(yùn)維能力都寫好以后，我們很容易想到要打包交付這個(gè)應(yīng)用，這樣無論是公有云還是專有云都可以通過一個(gè)統(tǒng)一的方式去交互。社區(qū)的主流方式目前就是使用 Helm 來打包應(yīng)用，而我們也采用了這樣的方式給我們的用戶交付，但是卻發(fā)現(xiàn)我們的用戶需求遠(yuǎn)不止于此。

云原生應(yīng)用有一個(gè)很大的特點(diǎn)，那就是它往往會(huì)依賴云上的資源，包括數(shù)據(jù)庫、網(wǎng)絡(luò)、負(fù)載均衡、緩存等一系列資源。

當(dāng)我們使用 Helm 打包時(shí)，我們只能針對(duì) K8s 原生 API，而如果我們還想啟動(dòng) RDS 數(shù)據(jù)庫，就比較困難了。如果不想去數(shù)據(jù)庫的交互頁面，想通過 K8s 的 API 來管理，那就又不得不去寫一個(gè) CRD 來定義了，然后通過 Operator 去調(diào)用實(shí)際云資源的 API。

這一整套交付物實(shí)際上就是一個(gè)應(yīng)用的完整描述，即我們所說的“應(yīng)用定義”。但事實(shí)上，我們發(fā)現(xiàn)“應(yīng)用定義”這個(gè)東西，在整個(gè)云原生社區(qū)里其實(shí)是缺失的。這也是為什么阿里巴巴內(nèi)部有很多團(tuán)隊(duì)開始嘗試設(shè)計(jì)了自己的“定義應(yīng)用”。

這種定義方式最終所有的配置還是會(huì)全部堆疊到一個(gè)文件里，這跟 K8s API all-in-one 的問題其實(shí)是一樣的，甚至還更嚴(yán)重了。而且，這些應(yīng)用定義最終也都成為了黑盒，除了對(duì)應(yīng)項(xiàng)目本身可以使用，其他系統(tǒng)基本無法復(fù)用。自然就更無法使得多方協(xié)作復(fù)用了。

每個(gè)公司和團(tuán)隊(duì)都在自己定義應(yīng)用

不光是阿里巴巴內(nèi)部的團(tuán)隊(duì)需要應(yīng)用定義，事實(shí)上幾乎每個(gè)基于 K8s 管理應(yīng)用的公司和團(tuán)隊(duì)都在自己定義應(yīng)用。如下所示，我就搜到了兩家公司的應(yīng)用定義：

應(yīng)用定義實(shí)際上是應(yīng)用交付/分發(fā)不可或缺的部分。但是在具體的實(shí)踐中，我們感受到這些內(nèi)部的應(yīng)用定義都面臨著如下的問題：

定義是否足夠開放，是否可以復(fù)用？

如何與開源生態(tài)協(xié)作？

如何迭代與演進(jìn)？

這三個(gè)問題帶來的挑戰(zhàn)都是巨大的，我在上文已經(jīng)提到，一個(gè)應(yīng)用定義需要容易上手，但又不失靈活性，更不能是一個(gè)黑盒。應(yīng)用定義同樣需要跟開源生態(tài)緊密結(jié)合，沒有生態(tài)的應(yīng)用定義注定是沒有未來的，自然也很難持續(xù)的迭代和演進(jìn)。

區(qū)分使用者的分層模型與模塊化的封裝

讓我們回過頭來重新審視我們面臨的挑戰(zhàn)，歸根結(jié)底在于 K8s 的 All in One API 是為平臺(tái)提供者設(shè)計(jì)的，我們不能像下圖左側(cè)顯示的一樣，讓應(yīng)用的研發(fā)、運(yùn)維跟 K8s 團(tuán)隊(duì)一樣面對(duì)這一團(tuán) API。

一個(gè)合理的應(yīng)用模型應(yīng)該具有區(qū)分使用者角色的分層結(jié)構(gòu)，同時(shí)將運(yùn)維能力模塊化的封裝。讓不同的角色使用不同的 API，正如上圖右側(cè)部分。

OAM： 以應(yīng)用為中心的 K8s API 分層模型

OAM(Open Application Model) 正是這樣一個(gè)以應(yīng)用為中心的 K8s API 分層模型：

• 從研發(fā)的角度，他操作和關(guān)注的 API 對(duì)象叫 Component；
• 從運(yùn)維的角度，模塊化的運(yùn)維能力封裝就是 Trait，而運(yùn)維可以通過 App Config 將 Component 和 Trait 自由組合，最終實(shí)例化成一個(gè)運(yùn)行的應(yīng)用；
• K8s 團(tuán)隊(duì)本身則仍然基于 K8s 的原生 API 迭代這一層能力。

針對(duì)研發(fā)時(shí)常抱怨的 K8s API 太復(fù)雜，我們通過關(guān)注點(diǎn)分離，區(qū)分使用者面對(duì)的 API 來解決，同時(shí)提供了幾種核心的 Workload，讓研發(fā)只需要填寫少數(shù)幾個(gè)字段就可以完成組件的定義；針對(duì)復(fù)雜應(yīng)用定義，我們通過擴(kuò)展的 Workload，允許研發(fā)對(duì)接 CRD Operator 的方式對(duì)接自定義 Workload。

針對(duì)運(yùn)維需要的模塊化封裝運(yùn)維能力和全局管理的需求，OAM 模型通過 Trait 來提供。Trait 是運(yùn)維能力的體現(xiàn)，不同的 Trait 也對(duì)應(yīng)了不同類型的運(yùn)維能力，如日志收集 Trait、負(fù)載均衡 Trait、水平擴(kuò)縮容 Trait 等等；同時(shí) OAM 本身就提供了一個(gè)全局管理的標(biāo)準(zhǔn)，OAM 模型的實(shí)現(xiàn)層可以輕松針對(duì) OAM 定義里的種種 Trait 描述進(jìn)行管理和檢查。

針對(duì)云資源，OAM 向上也提供了統(tǒng)一的 API，也是通過關(guān)注點(diǎn)分為三類：

• 一類是研發(fā)關(guān)注的云資源，如數(shù)據(jù)庫 RDS、對(duì)象存儲(chǔ) OSS 等，通過擴(kuò)展 Workload 接入；
• 另一類是運(yùn)維關(guān)注的云資源，如負(fù)載均衡 SLB 等，通過 Trait 接入；
• 最后一類也是運(yùn)維關(guān)注的云資源，但是可能包含多個(gè)應(yīng)用之間的聯(lián)動(dòng)關(guān)系，如虛擬專有網(wǎng)絡(luò) VPC 等，通過應(yīng)用的 Scope 接入。Scope 則是 OAM 中管理多應(yīng)用聯(lián)動(dòng)關(guān)系的概念。

可以看到，OAM 通過統(tǒng)一的一套標(biāo)準(zhǔn)，解決了我們今天提到的所有難題。讓我們繼續(xù)深入到 OAM 中看看不同的概念具體是什么。

OAM Component：研發(fā)關(guān)注的 API

Component 就是 OAM 模型提供給研發(fā)的API對(duì)象，如下所示：

apiVersion: core.oam.dev/v1alpha1 kind: Component metadata:name: nginxannotations:version: v1.0.0description: >Sample component schematic that describes the administrative interface for our nginx deployment. spec:workloadType: ServerosType: linuxcontainers:- name: nginximage:name: nginx:1.7.9digest: <sha256:...>env:- name: initReplicasvalue: 3- name: worker_connectionsfromParam: connectionsworkloadSettings:...parameters:- name: connectionsdescription: "The setting for worker connections"type: numberdefault: 1024required: false

可以看到 Component 本身就是一個(gè) K8s 的CRD，spec 字段里面的部分就是 Component 具體的定義。其中第一個(gè)重要的字段就是 workloadType，這個(gè)決定了應(yīng)用的運(yùn)行模式。

針對(duì)簡(jiǎn)單應(yīng)用，OAM 提供了 6 種核心 Workload，如下表所示：

主要通過是否可訪問、是否可復(fù)制、是否長(zhǎng)久運(yùn)行來區(qū)分。如 Server，就代表了大家最常用的 K8s 里面 Deployment Service 的組合。

填寫了核心 workloadType 的 Component，只需要定義 Container 里的注入鏡像、啟動(dòng)參數(shù)等字段，就如我們最開始所說的屏蔽掉大量字段的 PaaS 一樣，為用戶大大降低了門檻。

而針對(duì)復(fù)雜的有狀態(tài)應(yīng)用，OAM 則允許通過擴(kuò)展 Workload 來實(shí)現(xiàn)，如下圖所示，我們可以定義一個(gè)新的叫 openfaas 的 WorkloadType，它的定義實(shí)際上完全等價(jià)于一個(gè) CRD 定義。

OAM 模型中，使用自定義的 Workload 也是通過 Component，只是 WorkloadType 改為你自定義的 WorkloadType 名稱。

OAM Trait：可發(fā)現(xiàn)、可管理的運(yùn)維能力

Trait 就是模塊化的運(yùn)維能力，我們能通過命令行工具發(fā)現(xiàn)一個(gè)系統(tǒng)里支持哪些 Traits（運(yùn)維能力）。

$ kubectl get traits NAME AGE autoscaler 19m ingress 19m manual-scaler 19m volume-mounter 19m

這時(shí)候，運(yùn)維要查看具體的運(yùn)維能力該怎么使用，是非常簡(jiǎn)單的：

$ kubectl get trait ingress -o yaml apiVersion: core.oam.dev/v1alpha1 kind: Trait metadata:name: cron-scalerannotations:version: v1.0.0description: "Allow cron scale a workloads that allow multiple replicas." spec:appliesTo:- core.oam.dev/v1alpha1.Serverproperties: |{"$schema": "http://json-schema.org/draft-07/schema#","type": "object","required": ["schedule"],"properties": {"schedule": {"type": "array","description": "CRON expression for a scaler","item": {"type": "string"}},"timezone": {"type": "string","description": "Time zone for this cron scaler."},"resource":{"type": "object""description": "Resources the cron scaler will follow","properties": {"cpu": {type: "object"...}}}}}

可以看到，他可以在 Trait 定義里清晰的看到這個(gè)運(yùn)維能力可以作用于哪種類型的 Workload，包括能填哪些參數(shù)、哪些必填/選填、參數(shù)的作用描述是什么。 你也可以發(fā)現(xiàn)，OAM 體系里面，Component 和 Trait 這些 API 都是 Schema，所以它們是整個(gè)對(duì)象的字段全集，也是了解這個(gè)對(duì)象描述的能力“到底能干嗎?”的最佳途徑。

事實(shí)上，大家可能已經(jīng)發(fā)現(xiàn)，Trait 的定義和 CRD 是對(duì)等的，而你完全也可以通過 Operator 實(shí)現(xiàn) Trait。

所以** OAM 事實(shí)上將原本散亂的 Operator 通過不同的角色有機(jī)的管理起來了**。

OAM Application Config：組裝 Component 和 Trait，應(yīng)用實(shí)例化運(yùn)行

Component 和 Trait 最終通過 Application Configuration 結(jié)合，并真實(shí)運(yùn)行起來。

更重要的是，這個(gè) OAM 應(yīng)用描述文件是完全自包含的，也就是說通過 OAM YAML，作為軟件分發(fā)商，我們就可以完整地跟蹤到一個(gè)軟件運(yùn)行需要的所有資源和依賴。這就使得現(xiàn)在對(duì)于一個(gè)應(yīng)用，大家只需要一份 OAM 的配置文件，就可以快速、在不同運(yùn)行環(huán)境上把應(yīng)用隨時(shí)運(yùn)行起來，把這種自包含的應(yīng)用描述文件完整地交付到任何一個(gè)運(yùn)行環(huán)境中。

而我們圖中的 Rudr 項(xiàng)目就是 OAM 的一個(gè)實(shí)現(xiàn)，也可以理解為 OAM 的一個(gè)解釋器，將 OAM 的統(tǒng)一描述轉(zhuǎn)換為背后眾多的 Operator。同時(shí) Rudr 也是一個(gè)統(tǒng)一管理的媒介，如果 Application Configuration 中出現(xiàn)了一個(gè) Component 綁定 2 個(gè) Trait 并且互相沖突的情況，就可以快速被檢驗(yàn)并發(fā)現(xiàn)問題，如下圖所示。

同樣，包括復(fù)雜應(yīng)用的編排、云資源的拉起、Workload 與 Trait 交互等等，都可以在這個(gè) OAM 解釋器中實(shí)現(xiàn)。

大家可以通過?Rudr 項(xiàng)目中的教程文檔體驗(yàn) OAM 的這些交互過程。

OAM 加持下的 Kubernetes PaaS

事實(shí)上，OAM 加持下的 PaaS 基于 Kubernetes，將眾多 Operator 分層的管理了起來。

對(duì)于研發(fā)，通常他關(guān)心的應(yīng)用可能是一個(gè)由 web 和數(shù)據(jù)庫組合而成的應(yīng)用，數(shù)據(jù)庫組件的背后可能是一個(gè) RDS Operator 實(shí)現(xiàn)。而 web 應(yīng)用背后，則可以是我們開源的 K8s 原生 StatefulSet的增強(qiáng)項(xiàng)目 OpenKruise，OpenKruise 中提供的包括原地升級(jí)等增強(qiáng)能力則通過 Trait 的方式去配置。而額外的一些監(jiān)控報(bào)警、日志等能力，則由一個(gè)個(gè)獨(dú)立的 Operator 去實(shí)現(xiàn)，由運(yùn)維在第二層去關(guān)注和管理。

最終 K8s 團(tuán)隊(duì)聯(lián)合各種基礎(chǔ)軟件的提供商，圍繞 K8s 原生 API，以 Operator 的形式不斷提供擴(kuò)展能力，通過 OAM 這樣統(tǒng)一的規(guī)范和標(biāo)準(zhǔn)向外標(biāo)準(zhǔn)化輸出。

更重要的是，OAM 的統(tǒng)一描述大大提高了 Operator 的復(fù)用能力，使得 Operator 的編寫主需要關(guān)注業(yè)務(wù)邏輯本身。比如原先你寫一個(gè) Zookeeper Operator，你需要寫實(shí)例的服務(wù)發(fā)現(xiàn)、需要寫升級(jí)時(shí)主備切換的編排邏輯、需要寫實(shí)例備份的邏輯，而這一切在 OAM 的標(biāo)準(zhǔn)化下，你將可以輕松在社區(qū)找到類似組成部分。

OAM 加持下的 Kubernetes PaaS，使得不同的 Operator 可以像樂高積木一樣靈活組裝，使得應(yīng)用定義成為了社區(qū)共同建設(shè)的項(xiàng)目，使得應(yīng)用管理變得統(tǒng)一，功能卻更加強(qiáng)大！

最后

最后，給大家分享一下 OAM 項(xiàng)目近期的計(jì)劃，OAM 是一個(gè)完全屬于社區(qū)的應(yīng)用定義模型，我們非常希望大家都能參與進(jìn)來。

• 釘釘掃碼進(jìn)入 OAM 項(xiàng)目中文討論群

• 通過?Gitter 直接參與討論：https://gitter.im/oam-dev/

我們會(huì)集成 OpenFaaS、Terraform、Knative，支持不同的 Workload，讓 OAM 可以對(duì)接不同的實(shí)現(xiàn)；我們會(huì)針對(duì) K8s Operator 提供一鍵接入的轉(zhuǎn)換方式，讓現(xiàn)在的 Operator 快速融入OAM。

我們也會(huì)開源一個(gè) oam-framework 項(xiàng)目，這個(gè)項(xiàng)目可以快速構(gòu)建一個(gè) OAM 的實(shí)現(xiàn)，類似 kubebuilder、Operator-sdk 快速構(gòu)建 Operator 一樣，oam-framework 會(huì)幫助你快速構(gòu)建 OAM 實(shí)現(xiàn)。

我們還會(huì)構(gòu)建一個(gè) CRD (traits/workloads) Registry 項(xiàng)目，可以讓大家注冊(cè)自己的 OAM 實(shí)現(xiàn)、自定義 Workload、Trait 等等資源，以便最大程度的實(shí)現(xiàn)社區(qū)中大家的協(xié)作與復(fù)用。

• OAM 規(guī)范地址：https://github.com/oam-dev/spec
• OAM 開源實(shí)現(xiàn)地址：https://github.com/oam-dev/rudr

期待大家的參與！

關(guān)注阿里巴巴云原生公眾號(hào)回復(fù)應(yīng)用即可下載本文 PPT！

“> 阿里巴巴云原生微信公眾號(hào)（ID：Alicloudnative）關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)公眾號(hào)。”

總結(jié)

以上是生活随笔為你收集整理的阿里巴巴的 Kubernetes 应用管理实践经验与教训的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。