作者 |?李響、張磊

從 2019 年初開始，阿里巴巴云原生應用平臺團隊開始逐步在整個阿里經濟體內，基于標準應用定義與交付模型進行應用管理產品與項目統一架構升級的技術工作。

事實上，早在 2018 年末，當 Kubernetes 項目正式成為阿里巴巴的應用基礎設施底盤之后，阿里內部以及阿里云產品線在應用管理領域的碎片化問題就開始日漸凸顯出來。

尤其是在云原生生態日新月異的今天，阿里巴巴與阿里云的應用管理產品架構（包括阿里內部 PaaS 和云上 PaaS 產品），如何以最佳姿態擁抱云原生生態、如何以最高效的技術手段借助生態日新月異的能力構建出更強大的 PaaS 服務，而不是重復造輪子甚至和生態“背道而馳”，很快就成為了阿里團隊亟待解決的重要技術難題。

但棘手的是，這個問題并不是簡單把 PaaS 遷移或者集成到 Kubernetes 上來就能夠解決的：PaaS 與 Kubernetes 之間，從來就沒有存在這樣一條清晰的分界線，可是 Kubernetes 本身又并不是面向最終用戶設計的。

如何既讓全公司的研發和運維充分享受云原生技術體系革新帶來的專注力與生產力提升，又能夠讓現有 PaaS 體系無縫遷移、接入到 Kubernetes 大底盤當中，還要讓新的 PaaS 體系把 Kubernetes 技術與生態的能力和價值最大程度的發揮出來，而不是互相“屏蔽”甚至“打架”？這個“既要、又要、還要”的高標準要求，才是解決上述 “Kubernetes vs PaaS” 難題的關鍵所在。

什么是“應用模型”？

在 2019 年 10 月，阿里巴巴宣布聯合微軟共同推出開放應用模型項目（Open Application Model - OAM），正是阿里進行自身應用管理體系標準化與統一架構升級過程中，逐步演進出來的一項關鍵技術。

所謂“應用模型”，其實是一個專門用來對云原生應用本身和它所需運維能力進行定義與描述的標準開源規范。所以對于 Kubernetes 來說，OAM 即是一個標準的“應用定義”項目（類比已經不再活躍的 Kubernetes Application CRD 項目），同時也是一個專注于封裝、組織和管理 Kubernetes 中各種“運維能力”、以及連接“運維能力”與“應用”的平臺層項目。而通過同時提供“定義應用”和“組織管理應用的運維能力”這兩大核心功能，OAM 項目自然成為了阿里巴巴進行統一應用架構升級和構建下一代 PaaS/Serverless 過程中“當仁不讓”的關鍵路徑。

此外，OAM 模型并不負責應用和能力的具體實現，從而確保了它們都是由 Kubernetes 本身直接提供的 API 原語和控制器實現。所以， OAM 也成為了當前阿里構建 Kubernetes 原生 PaaS 的一項主要手段。

在 OAM 中，一個應用程序包含三個核心理念：

• 第一個核心理念是組成應用程序的組件（Component），它可能包含微服務集合、數據庫和云負載均衡器；
• 第二個核心理念是描述應用程序運維特征（Trait）的集合，例如，彈性伸縮和 Ingress 等功能。它們對應用程序的運行至關重要，但在不同環境中其實現方式各不相同；
• 最后，為了將這些描述轉化為具體的應用程序，運維人員使用應用配置（Application Configuration）來組合組件和相應的特征，以構建應部署的應用程序的具體實例。

阿里巴巴在 OAM 這個項目中融入了大量互聯網規模場景中管理 Kubernetes 集群和公共云產品方面的實際經驗，特別是阿里從原先不計其數的內部應用 CRD 轉向基于 OAM 的標準應用定義過程中的諸多收獲。作為工程師，我們從過去的失敗和錯誤中吸取教訓，不斷開拓創新、發展壯大。

在本文中，我們將會詳細分享 OAM 項目背后的動機和推動力，希望能夠幫助更多人更好地了解這個項目。

背景

1. 關于我們

我們是阿里巴巴的“基礎設施運維人員”，或者說 Kubernetes 團隊。具體來說，我們負責開發、安裝和維護各種 Kubernetes 級別的功能。具體工作包括但不限于維護大規模的 K8s 集群、實現控制器/Operator，以及開發各種 K8s 插件。在公司內部，我們通常被稱為“平臺團隊（Platform Builder）”。

不過，為了與兄弟團隊區分，即那些在我們之上基于 K8s 構建的 PaaS 工程人員區分，我們在本文中將自稱為“基礎設施運維人員（Infra Operator）”。過去幾年里，我們已通過 Kubernetes 取得了巨大成功，并在使用過程中通過出現的問題獲取了寶貴的經驗教訓。

2. 我們管理各種 Kubernetes 集群

毫無疑問，我們為阿里巴巴電商業務維護著世界上最大、最復雜的 Kubernetes 集群，這些集群：

• 可縱向擴展至 1 萬個節點；
• 運行 1 萬多種應用程序；
• 在高峰期每天處理 10 萬次應用部署。

同時，我們還協助支持著阿里云的 Kubernetes 服務（ACK），該服務類似于面向外部客戶的其他公有云 Kubernetes 產品，其中包含大量集群（約 1 萬個），不過通常均為小型或中型的集群。我們的內部和外部客戶在工作負載管理方面的需求和用例非常多樣化。

3. 我們服務的對象是“運維”；而運維的服務對象是“研發”

與其他互聯網公司類似，阿里巴巴的技術棧由基礎設施運維人員、應用運維人員和業務研發人員合作完成。業務研發和應用運維人員的角色可以概括如下：

業務研發人員

以代碼形式傳遞業務價值。大多數業務研發都對基礎設施或 K8s 不甚了解，他們與 PaaS 和 CI 流水線交互以管理其應用程序。業務研發人員的生產效率對公司而言價值巨大。

應用運維人員

為業務研發人員提供有關集群容量、穩定性和性能的專業知識，幫助業務研發人員大規模配置、部署和運行應用程序（例如，更新、擴展、恢復）。請注意，盡管應用運維人員對 K8s 的 API 和功能具有一定了解，但他們并不直接在 K8s 上工作。在大多數情況下，他們利用 PaaS 系統為業務研發人員提供基礎 K8s 功能。在這種情況下，許多應用運維人員實際上也是 PaaS 工程人員。

總之，像我們這樣的基礎設施運維人員為應用運維人員提供服務，他們隨之為業務研發人員提供服務。

合作問題

綜上所述，這三方顯然擁有不同的專業知識，但他們卻需要協調一致以確保順利工作。這在 Kubernetes 的世界里可能很難實現！

我們將在下面的章節中介紹不同參與方的痛點，但簡而言之，我們面臨的根本問題是不同參與方之間缺乏一種標準化的方法來進行高效而準確的交互。這會導致低效的應用程序管理流程，甚至導致運行失敗。

而標準應用模型正是我們解決此問題的關鍵方法。

基礎設施運維人員和應用運維人員之間的交互

Kubernetes 具有高度的可擴展性，使得基礎設施運維人員能夠隨心所欲地構建自己的運維功能。但 Kubernetes 巨大的靈活性也是一把雙刃劍：這些功能的用戶（即應用運維人員）會遇到一些棘手的問題。

舉例來說，在阿里巴巴，我們開發了 CronHPA CRD 以根據 CRON 表達式擴展應用程序。當應用程序的水平擴展策略希望在白天和晚上有所不同時，這非常有用。CronHPA 是一種可選功能，僅在集群中按需部署。

CronHPA 的 yaml 示例如下所示：

apiVersion: “app.alibaba.com/v1” kind: CronHPA metadata:name: cron-scaler spec:timezone: America/Los_Angelesschedule:- cron: ‘0 0 6 * * ?’minReplicas: 20maxReplicas: 25- cron: ‘0 0 19 * * ?’minReplicas: 1maxReplicas: 9template:spec:scaleTargetRef:apiVersion: apps/v1name: php-apachemetrics:- type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 50

這是一個典型的 Kubernetes 自定義資源（CRD），可以直接安裝使用。

但是，當我們把這些功能交付出去，應用運維人員開始使用諸如 CronHPA 等自定義插件時，他們很快就遇到麻煩了：

1. 這些 K8s 自定義功能的使用方法不明確。

應用運維人員經常抱怨這些插件功能的使用方法（也就是 spec） 分布的非常隨意。它有時位于 CRD 中，有時位于 ConfigMap 中，有時又位于某個隨機位置的配置文件中。此外，他們還感到非常困惑：為什么 K8s 中很多插件（例如，CNI 和 CSI 插件）的 CRD 并不是對應的能力（例如：網絡功能和存儲功能）描述，而只是那些插件本身的安裝說明？

2. 很難確認 K8s 集群中是否存在某項具體能力。

應用運維人員對某項運維能力是否已在集群中準備就緒毫無把握，尤其是當該能力是新開發的插件提供時更是如此?；A設施運維人員和應用運維人員之間需要進行多輪溝通，才能澄清這些問題。

除上述可發現性問題外，還有一個與可管理性相關的額外難題。

3. 運維能力之間的沖突可能會相當麻煩。

K8s 集群中的運維能力之間的關系可以概括為以下三類：

• 正交 —— 能力彼此獨立。例如，Ingress 用于流量管理，持久性存儲用于存儲管理；
• 可組合 —— 多個能力可以協同應用于同一應用程序。例如，Ingress 和 Rollout：Rollout 升級應用程序并控制 Ingress 以便實現漸進式流量切換；
• 沖突 —— 多個能力不能應用于同一應用程序。例如，如果將 HPA 和 CronHPA 應用于同一應用程序，則會彼此沖突。

正交和可組合能力相對安全。然而，互相沖突的功能可能導致意外/不可預測的行為。

這里的問題在于， Kubernetes 很難事先向應用運維人員發送沖突警告。因此，他們可能會對同一應用程序使用彼此沖突的兩個運維能力。而當實際發生沖突時，解決沖突會產生高昂的成本，在極端情況下，這些沖突會導致災難性的故障。當然，在管理平臺能力時，應用運維人員顯然不希望面臨“頭頂懸著達摩克里斯之劍”的情況，因此希望找到一種更好的方法來提前避免沖突情況。

應用運維人員如何發現和管理可能相互沖突的運維能力？換而言之，作為基礎設施運維人員，我們能否為應用運維人員構建可發現且易管理的運維能力呢？

OAM 中的運維特征（Trait）

在 OAM 中，我們通過“運維特征（Trait）”來描述和構建具備可發現性和可管理性的平臺層能力。

這些平臺層能力實質上是應用程序的運維特征，而這正是 OAM 中“Trait”這個名稱的來歷。

1. 打造可發現的運維能力

在阿里的 K8s 集群中，大多數 Trait 都由基礎設施運維人員定義，并使用 Kubernetes 中的自定義控制器實現，例如：

• Ingress
• Auto-scaler
• Volume-mounter
• Traffic-shifting、Security-policy 等

請注意， Trait 并不等同于 K8s 插件。比如：一個集群可具有多個網絡相關 Trait ，如“動態 QoS ?Trait ”、“帶寬控制 Trait ”和“流量鏡像 Trait ”，這些 Trait 均由一個 CNI 插件提供。

實際上， Trait 安裝在 K8s 集群中，并供應用運維人員使用。將能力作為 Trait 呈現時，應用運維人員使用簡單的 kubectl get 命令即可發現當前集群支持的運維能力：

$ kubectl get traitDefinition NAME AGE cron-scaler 19m auto-scaler 19m

上面的示例顯示此集群支持兩種 “scaler” 能力。用戶可以將需要基于 CRON 的擴展策略的應用程序部署到該集群。

Trait 提供給定運維能力的結構化描述。

這使應用運維人員通過簡單的 kubectl describe 命令即可輕松準確地理解特定能力，而不必深入研究其 CRD 或文檔。能力描述包括“此 Trait 適用于何種工作負載”和“它的使用方式”等。

例如，kubectl describe traitDefinition cron-scaler：

apiVersion: core.oam.dev/v1alpha2 kind: TraitDefinition metadata:name: cron-scaler spec:appliesTo:- core.oam.dev/v1alpha1.ContainerizedWorkloaddefinitionRef:name: cronhpas.app.alibaba.com

請注意，在 OAM 中， Trait 通過 definitionRef 引用 CRD 來描述其用法，同時也與 K8s 的 CRD 解耦。

Trait 采用了規范與實現分離的設計，同樣一個 Trait 的 spec，可以被不同平臺不同環境完全基于不同的技術來實現。通過引用的方式，實現層既可以對接到一個已有實現的 CRD，也可以對接到一個統一描述的中間層，底下可插拔的對接不同的具體實現?？紤]到 K8s 中的一個特定的能力比如 Ingress 可能有多達幾十種實現，這種規范與實現分離的思想會非常有用。Trait 提供了統一的描述，可幫助應用運維人員準確理解和使用能力。

2. 打造可管理的運維能力

應用運維人員通過使用 ApplicationConfiguration（將在下一部分中詳細介紹），對應用程序配置一個或多個已安裝的 Trait 。ApplicationConfiguration 控制器將處理 Trait 沖突（如果有）。

我們以此示例 ApplicationConfiguration 為例：

apiVersion: core.oam.dev/v1alpha2 kind: ApplicationConfiguration metadata:name: failed-example spec:components:- name: nginx-replicated-v1traits:- trait:apiVersion: core.oam.dev/v1alpha2kind: AutoScalerspec: minimum: 1maximum: 9- trait:apiVersion: app.alibabacloud.com/v1kind: CronHPAspec: timezone: "America/Los_Angeles"schedule: "0 0 6 * * ?"cpu: 50...

在 OAM 中，ApplicationConfiguration 控制器必須保證這些 Trait 之間的兼容性，如果不能滿足要求，應用的部署就會立刻失敗。所以，當運維人員將上述 YAML 提交給 Kubernetes 時，由于“Trait 沖突”，OAM 控制器將會報告部署失敗。這就使得應用運維人員能夠提前知道有運維能力沖突，而不是在部署失敗后大驚失色。

總的來說，我們團隊不提倡提供冗長的維護規范和運維指南（它們根本無法防止應用運維人員出錯），我們傾向于是使用 OAM ?Trait 來對外暴露基于 Kubernetes 的可發現和可管理的運維能力。這使我們的應用運維人員能夠“快速失敗”，并滿懷信心地組合運維能力來構建無沖突的應用運維解決方案，這就像玩“樂高積木”一樣簡單。

應用運維人員和業務研發之間的交互

Kubernetes 的 API 對象并不關心自己的使用者到底是運維還是研發。這意味著任何人都可能對一個 Kubernetes API 對象中的任何字段負責。這也稱為“all-in-one”的 API，它使得新手很容易上手。

但是，當具有不同關注點的多個團隊必須在同一個 Kubernetes 集群上展開協作時，特別是當應用運維人員和業務研發人員需要在相同 API 對象上展開協作時，all-in-one API 缺點就會凸顯出來。

讓我們先來看一個簡單的 Deployment YAML 文件：

kind: Deployment apiVersion: extensions/v1beta1 metadata:name: nginx-deployment spec:replicas: 3selector:matchLabels:deploy: exampletemplate:metadata:labels:deploy: examplespec:containers:- name: nginximage: nginx:1.7.9securityContext:allowPrivilegeEscalation: false

在我們的集群中，應用運維人員與業務研發人員需要面對面開會來填寫這個 yaml 文件。這種合作既耗時又復雜，但我們別無選擇。原因何在？

“抱歉，這個字段與我無關”

顯而易見，這里最直接的方法是讓業務研發人員自己填寫 Deployment yaml。但是，業務研發人員可能會發現 Deployment 里的某些字段與他們的關注點沒有絲毫關聯。例如：

有多少業務研發人員知道 allowPrivilegeEscalation 是什么意思？

事實上，很少有業務研發人員知道，在生產環境里，這個字段務必要設置為 false （默認是 true），才能確保應用程序在宿主機中具有合理的權限。在實踐中，這個字段只能應用運維人員配置。而現實是，一旦把整個 Deployment 暴露給業務研發填寫，這些字段最終就會淪為“猜謎游戲”，甚至完全被業務研發人員忽視。

這個字段到底是研發還是運維負責？

如果你了解 K8s 的話，就一定會發現 K8s 中有大量的 API 字段很難說清楚到底是應該由研發還是運維來填寫。

例如，當業務研發人員設置 Deployment 的 replicas:3 時，他會假設該數字在應用程序生命周期中固定不變。

但是，大多數業務研發人員并不知道 Kubernetes 的 HPA 控制器可以接管該字段，并可能會根據 Pod 負載改變 replicas 的值。這種由系統自動化流程帶來的變更很容易導致問題：這意味著當業務研發人員想要更改副本數時，他對 replicas 的修改可能根本不會生效。

在此種情況下，一個 Kubernetes 的 YAML 文件就不能表示工作負載的最終狀態，從業務研發人員角度而言，這非常令人困惑。我們曾嘗試使用 fieldManager 來處理此問題，但 fieldManager 進行沖突解決的過程仍頗具挑戰性，因為我們很難弄清這些沖突方的修改目的。

“割裂研發與運維”能否解決上述問題？

如上所示，當使用 K8s API 時，業務研發人員和運維人員的關注點會不可避免地被混在一起。這使得多個參與方可能很難基于同一個 API 對象展開協作。

此外，我們也發現，阿里內部的很多應用程序管理系統（如 PaaS）并不愿意暴露 K8s 的全部能力，顯然他們并不希望向業務研發人員暴露更多的 Kubernetes 概念。

對于上述問題，最簡單的解決方案是在業務研發人員和運維人員之間劃一條“明確的界限”。例如，我們可以僅允許業務研發人員設置 Deployment yaml 的一部分字段（這正是阿里很多 PaaS 曾經采用的辦法）。但是，這種“割裂研發與運維”的解決方案可能并不奏效。

運維需要聽取業務研發人員的意見

在很多情況下，業務研發人員都希望運維人員聽取他們的一些關于運維的“意見”。

例如，假定業務研發人員為應用程序定義了 10 個參數，然后他們發現應用運維人員可能會覆蓋這些參數以適配不同的運行環境的差異。那么問題來了：業務研發如何才能做到僅允許運維人員修改其中特定的 5 個參數？

實際上，如果采用“割裂研發與運維”應用管理流程，要傳達業務研發人員的運維意見將變得難上加難。這樣類似的例子有許多，業務研發人員可能希望表述很多關于他們的應用程序的信息：

• 無法水平擴展（即單一實例）；
• 是一個批處理作業，而不是長運行的服務；
• 需要最高級別的安全性等等。

上述所有這些請求都是合理的，因為只有業務研發人員才是最了解應用程序的那個人。這就提出了一個我們亟待解決的重要問題：我們的 Kubernetes 能否既為業務研發和運維人員提供單獨的 API，同時又允許業務研發人員有效傳達自己對運維的訴求？

OAM 中的 Component?和 ApplicationConfiguration

在 OAM 中，我們從邏輯上對 K8s 的 API 對象進行了拆分，并且做到了既使得業務研發人員能夠填寫屬于自己的那些字段，同時又能有條理地向運維人員傳達訴求。

定義你的應用程序，而不是僅僅描述它。

1. Component

在 OAM 中，Component（組件） 就是一個完全面向業務研發人員設計的、用于定義應用程序而不必考慮其運維詳細信息的載體。一個應用程序包含一個或多個 Component 。例如，一個網站應用可以由一個 Java web 組件和一個數據庫組件組成。

以下是業務研發人員為 Nginx 部署定義的 Component 示例：

OAM 中的 Component 包含兩個部分：

• 工作負載描述 —— 如何運行此 Component，以及它的運行內容，實際上就是一個完整的 K8s CR；
• 可重寫參數列表 —— 研發通過這個字段表示該 Component 的哪些字段后續可以被運維或者系統覆蓋。

在 Component 中，workload 字段可以直接向運維人員傳達業務研發人員關于如何運行其應用程序的說明。同時，OAM 圍繞容器應用定義了一種核心工作負載 ContainerizedWorkload，涵蓋了云原生應用程序的典型模式。

與此同時，OAM 可以通過定義擴展工作負載來自由聲明用戶自己的工作負載類型。在阿里巴巴，我們在很大程度上依賴于擴展工作負載來使業務研發人員定義阿里云服務 Component ，例如，阿里云函數計算 Component 等。

請注意，在上面的示例中，業務研發人員不再需要設置副本數；因為這并不是他所關注的字段：他選擇讓 HPA 或應用運維人員完全控制副本數的值。

總體來說，Component 允許業務研發人員使用自己的方式定義應用程序的聲明式描述，但同時也為他/她提供了隨時向運維人員準確傳達意見或信息的能力。這些信息包括對運維的訴求，例如，“如何運行此應用程序”和“可重寫參數”。

2. ApplicationConfiguration

最終，通過引用 Component 名稱并對它綁定 Trait ，運維人員就可以使用 ApplicationConfiguration 來實例化應用程序。

使用 Component 和 ApplicationConfiguration 的示例協作工作流：

• Kubernetes 里安裝了各種工作負載類型（workloadType）；
• 業務研發人員使用所選工作負載類型定義一個 component.yaml；
• 然后，應用運維人員（或 CI / CD 系統）運行 kubectl apply -f component.yaml 來安裝此 Component；
• 應用運維人員接下來使用 app-config.yaml 來定義 ApplicationConfiguration 以實例化應用程序；
• 最后，應用運維人員運行 kubectl apply -f app-config.yaml 以觸發整個應用程序的部署。

這個 app-config.yaml 文件的內容如下所示：

apiVersion: core.oam.dev/v1alpha1 kind: ApplicationConfiguration metadata:name: my-awesome-app spec:components:- componentName: nginxparameterValues:- name: connectionsvalue: 4096traits:- trait:apiVersion: core.oam.dev/v1alpha2kind: AutoScalerspec: minimum: 1maximum: 9- trait:apiVersion: app.aliaba.com/v1kind: SecurityPolicyspec: allowPrivilegeEscalation: false

我們來重點說明以上 ApplicationConfiguration YAML 中的一些詳細信息：

• parameterValues —— 供運維人員使用，用于將 connections 值重寫為 4096，在該組件中，該值最初為 1024。請注意，運維人員必須填寫整數 4096，而不是字符串 “4096”，因為此字段的 schema 已在 Component 中明確定義；

• Trait ?AutoScaler —— 供運維人員使用，用于將 autoscaler ?Trait （如 HPA）綁定給 Component 。因此，其副本數將完全由 autoscaler 控制；

• Trait SecurityPolicy —— 供運維人員使用，用于將安全策略規則應用于 Component。請注意，運維人員還可以修改 Trait 列表以綁定更多 Trait。例如，“Canary Deployment Trait ”意味著這個應用程序在后期升級過程中遵循金絲雀發布策略。

實質上，ApplicationConfiguration 的主要功能，就是讓應用運維人員（或系統）了解和使用業務研發人員傳達的信息，然后自由的為 Component 組合綁定不同的運維能力以相應實現其最終的運維目的。

并不止是應用管理

綜上所述，我們使用 OAM 的主要目標是解決應用程序管理中的以下問題：

• 如何在 Kubernetes 中構建可發現、可組合和可管理的運維能力；
• 如何使 Kubernetes 中的多個參與方圍繞同一個 API 對象準確有效地協作。

所以說，對于阿里巴巴來說，OAM 其實是阿里巴巴 Kubernetes 團隊提出的一種 Application CRD 規范，從而使得所有參與者可以采用結構化的標準方法來定義應用程序及其運維能力。

阿里巴巴開發 OAM 的另一個強大動力，則是在混合云和多環境中進行軟件分發與交付。隨著 Google Anthos 和 Microsoft Arc 的出現，我們已然看到 Kubernetes 正成為新的 Android，并且云原生生態系統的價值正迅速轉移到應用層的趨勢。我們將在以后討論這一主題。

本文中的實際使用案例由阿里云原生團隊和螞蟻金服共同提供。

OAM 的未來

目前，OAM 規范和模型實際已解決許多現有問題，但它的路程才剛剛開始。例如，我們正在研究使用 OAM 處理組件依賴關系、在 OAM 中集成 Dapr 工作負載等。

我們期待在 OAM 規范及其 K8s 實現方面與社區展開協作。OAM 是一個中立的開源項目，其所有貢獻者都應遵循非營利性基金會的 CLA。

目前，阿里巴巴團隊正在上游貢獻和維護這套技術，如果大家有什么問題或者反饋，也非常歡迎與我們在上游或者釘釘聯系。

參與方式：

• 釘釘掃碼進入 OAM 項目中文討論群

• 通過 Gitter 直接參與討論
• OAM 開源實現地址
• 點擊 star 一下

作者簡介
**李響，阿里云資深技術專家。**他在阿里巴巴從事集群管理系統工作，并協助推動阿里巴巴集團內的 Kubernetes 采用。在效力于阿里巴巴之前，李響曾是 CoreOS Kubernetes 上游團隊的負責人。他還是 etcd 和 Kubernetes Operator 的創建者。

**張磊，阿里云高級技術專家。**他是 Kubernetes 項目的維護者之一。張磊目前在阿里的 Kubernetes 團隊工作，其工作領域包括 Kubernetes 和云原生應用管理系統。

有一個阿里團隊需要你！

云原生應用平臺誠邀?Kubernetes / Serverless / PaaS / 應用交付領域專家（ P6-P8 ）加盟：

• 工作年限：建議 P6-7 三年起，P8 五年起，具體看實際能力；
• 工作地點：國內（北京 / 杭州 / 深圳）；海外（舊金山灣區 / 西雅圖）；
• 崗位包含：架構師、技術專家、全棧工程師等。

簡歷立刻回復，2~3 周出結果，簡歷投遞：jianbo.sjb AT alibaba-inc.com。

“阿里巴巴云原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦云原生流行技術趨勢、云原生大規模的落地實踐，做最懂云原生開發者的技術圈?！?/p>

總結

以上是生活随笔為你收集整理的深度解读！阿里统一应用管理架构升级的教训与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。