作者 |?張磊，阿里云高級(jí)技術(shù)專(zhuān)家、CNCF 官方大使，CNCF 應(yīng)用交付領(lǐng)域 co-chair，Kubernetes 項(xiàng)目資深維護(hù)者

最近，Kubernetes 社區(qū)里有一個(gè)關(guān)于“Kubernetes is the new database”的論述，引起了很多人的關(guān)注。當(dāng)然，這個(gè)論述更確切的含義，指的是?Kubernetes 項(xiàng)目本身的工作原理類(lèi)似于數(shù)據(jù)庫(kù)，而不是說(shuō)你應(yīng)該把 Kubernetes 當(dāng)數(shù)據(jù)庫(kù)用。

粗看起來(lái)，這個(gè) “Kubernetes 是一個(gè)數(shù)據(jù)庫(kù)” 的論述還是比較匪夷所思的。畢竟我們平常所說(shuō)的 Kubernetes 的工作原理，比如控制器模式、聲明式 API 等等，好像跟“數(shù)據(jù)庫(kù)”這個(gè)東西并沒(méi)有什么直接關(guān)系。但實(shí)際上，這個(gè)論述背后卻有著其非常本質(zhì)的含義。這里的緣由，得從 Kubernetes 項(xiàng)目里一個(gè)最基礎(chǔ)的理論談起。

Kubernetes 聲明式應(yīng)用管理理論基礎(chǔ)

在我們討論 Kubernetes 的時(shí)候，往往會(huì)提到這樣一個(gè)概念，叫做“聲明式應(yīng)用管理”。實(shí)際上，這也是 Kubernetes 項(xiàng)目跟其他所有基礎(chǔ)設(shè)施項(xiàng)目都不一樣的一個(gè)設(shè)計(jì)，是 Kubernetes 所獨(dú)有的一個(gè)能力，那么，你有沒(méi)有思考過(guò)，聲明式應(yīng)用管理在 Kubernetes 中具體的表現(xiàn)到底是什么呢？

1. 聲明式應(yīng)用管理不僅僅是“聲明式風(fēng)格的 API”

如果我們回顧一下 Kubernetes 的核心工作原理，我們其實(shí)就不難發(fā)現(xiàn)這樣一個(gè)事實(shí)：Kubernetes 里面的絕大多數(shù)功能，無(wú)論是 kubelet 執(zhí)行容器、kube-proxy 執(zhí)行 iptables 規(guī)則，還是 kube-scheduler 進(jìn)行 Pod 調(diào)度，以及 Deployment 管理 ReplicaSet 的過(guò)程等等，其實(shí)從總體設(shè)計(jì)上都是在遵循著我們經(jīng)常強(qiáng)調(diào)過(guò)的“控制器”模式來(lái)進(jìn)行的。即：用戶(hù)通過(guò) YAML 文件等方式來(lái)表達(dá)他所想要的期望狀態(tài)也就是終態(tài)（無(wú)論是網(wǎng)絡(luò)、還是存儲(chǔ)），然后 Kubernetes 的各種組件就會(huì)讓整個(gè)集群的狀態(tài)跟用戶(hù)聲明的終態(tài)逼近，最終達(dá)成兩者的完全一致。這個(gè)實(shí)際狀態(tài)逐漸向期望狀態(tài)逼近的過(guò)程，就叫做 reconcile（調(diào)諧）。而同樣的原理，也正是 Operator 和自定義 Controller 的核心工作方式。

這種通過(guò)聲明式描述文件，以驅(qū)動(dòng)控制器執(zhí)行 reconcile 逼近兩個(gè)狀態(tài)的工作形態(tài)，正是聲明式應(yīng)用管理最直觀的體現(xiàn)。需要注意的是，這個(gè)過(guò)程其實(shí)包括了兩層含義：

• 聲明式描述的期望狀態(tài)。這個(gè)描述必須是嚴(yán)格意義上使用者想要的最終狀態(tài)，如果你在這個(gè)描述里面填寫(xiě)的是某個(gè)中間狀態(tài)，或者你希望動(dòng)態(tài)的調(diào)整這個(gè)期望狀態(tài)，都會(huì)破壞這個(gè)聲明式語(yǔ)義的準(zhǔn)確執(zhí)行；
• 基于 reconcile 的狀態(tài)逼近過(guò)程。Reconcile 過(guò)程的存在，確保了系統(tǒng)狀態(tài)與終態(tài)保持一致的理論正確性。 確切地說(shuō)，Reconcile 過(guò)程不停的執(zhí)行“檢查 -> Diff -> 執(zhí)行”的循環(huán)，才使得系統(tǒng)能夠始終對(duì)系統(tǒng)本身狀態(tài)與終態(tài)直接的差異并能夠采取必要的行動(dòng)。而相比之下，僅僅擁有聲明式的描述是不充分的。這個(gè)道理很容易理解，你第一次提交這個(gè)描述時(shí)系統(tǒng)達(dá)成了你想要的期望狀態(tài)，并不能代表、也不能保證一個(gè)小時(shí)后的情況也是如此。很多人會(huì)搞混“聲明式應(yīng)用管理”和“聲明式風(fēng)格的 API” ，其實(shí)就是對(duì) Reconcile 必要性沒(méi)有正確的認(rèn)識(shí)。

你也許會(huì)比較好奇，采用這種聲明式應(yīng)用管理體系，對(duì)于 Kubernetes 來(lái)說(shuō)有什么好處呢？

2. 聲明式應(yīng)用管理的本質(zhì)：Infrastructure as Data

實(shí)際上，聲明式應(yīng)用管理體系背后的理論基礎(chǔ)，是一種叫做 Infrastructure as Data （IaD）的思想。這種思想認(rèn)為，基礎(chǔ)設(shè)施的管理不應(yīng)該耦合于某種編程語(yǔ)言或者配置方式，而應(yīng)該是純粹的、格式化的、系統(tǒng)可讀的數(shù)據(jù)，并且這些數(shù)據(jù)能夠完整的表征使用者所期望的系統(tǒng)狀態(tài)。

注：Infrastructure as Data? 有時(shí)也被稱(chēng)作 Configuration as Data，背后的意思是一樣的。

而這樣做的好處就在于，任何時(shí)候我想對(duì)基礎(chǔ)設(shè)施做操作，最終都等價(jià)于對(duì)這些數(shù)據(jù)的“增、刪、改、查”。而更重要的是，我對(duì)這些數(shù)據(jù)進(jìn)行“增、刪、改、查”的方式，與這個(gè)基礎(chǔ)設(shè)施本身是沒(méi)有任何關(guān)系的。所以說(shuō)，我跟一個(gè)基礎(chǔ)設(shè)施交互的過(guò)程，不會(huì)被綁定在某種編程語(yǔ)言、某種遠(yuǎn)程調(diào)用協(xié)議、或者某種 SDK 上。只要我能夠生成對(duì)應(yīng)格式的“數(shù)據(jù)”，我就能夠“天馬行空”地使用任何我喜歡的方式來(lái)完成對(duì)基礎(chǔ)設(shè)施的操作。

這種好處具體體現(xiàn)在 Kubernetes 上，就是如果我想在 Kubernetes 上做任何操作，我只需要提交一個(gè) YAML 文件，然后對(duì)這個(gè) YAML 文件進(jìn)行增刪改查即可。而不是必須使用 Kubernetes 項(xiàng)目的 Restful API 或者 SDK 。這個(gè) YAML 文件里的內(nèi)容，其實(shí)就是 Kubernetes 這個(gè) IaD 系統(tǒng)對(duì)應(yīng)的 Data（數(shù)據(jù)）。

所以說(shuō)，Kubernetes 從誕生起就把它的所有功能都定義成了所謂的“API 對(duì)象”，其實(shí)就是定義成了一份一份的 Data。這樣，Kubernetes 使用者就可以通過(guò)對(duì)這些 Data 進(jìn)行增刪改查來(lái)達(dá)成自己想要的目標(biāo)，而不是被綁定在某種具體的語(yǔ)言或者 SDK 上。更重要的是，相比于專(zhuān)有的、命令式的 API 或者 SDK，以 YAML 為載體的聲明式數(shù)據(jù)能夠更簡(jiǎn)單的完成對(duì)底層實(shí)現(xiàn)的屏蔽，從而更容易對(duì)接和集成現(xiàn)有的基礎(chǔ)設(shè)施能力，這其實(shí)也是 Kubernetes 生態(tài)能夠以驚人的速度蓬勃發(fā)展到今天的一個(gè)秘密武器：IaD 思想帶來(lái)的聲明式 API 與控制器模式，讓整個(gè)社區(qū)更愿意為 Kubernetes 編寫(xiě)插件和對(duì)接各種能力，并且這些插件和能力的通用性和可移植性也非常高，這是其它項(xiàng)目比如 Mesos 和 OpenStack 所望塵莫及的?？梢哉f(shuō)，IaD 正是 Kubernetes 能夠達(dá)成 “The Platform for Platform” 這個(gè)目標(biāo)的核心戰(zhàn)斗力所在。

說(shuō)到這里，大家估計(jì)也就明白了：這種 IaD 設(shè)計(jì)中的 Data 具體表現(xiàn)出來(lái)，其實(shí)就是聲明式的 Kubernetes API 對(duì)象；而 Kubernetes 中的控制循環(huán)，則是確保系統(tǒng)本身能夠始終跟這些 Data 所描述的狀態(tài)永遠(yuǎn)保持一致。從這一點(diǎn)上來(lái)說(shuō)，Kubernetes 本質(zhì)上其實(shí)是一個(gè)以數(shù)據(jù)（Data）來(lái)表達(dá)系統(tǒng)的設(shè)定值、通過(guò)控制器（Controller）的動(dòng)作來(lái)讓系統(tǒng)維持在設(shè)定值的調(diào)諧系統(tǒng)。

等一下，這個(gè)“讓系統(tǒng)維持在設(shè)定值”的理論，聽(tīng)起來(lái)好像有點(diǎn)耳熟？

實(shí)際上，Kubernetes 背后的這門(mén)基礎(chǔ)課，可能絕大多數(shù)工科背景的讀者都是學(xué)過(guò)的，它叫做《控制理論》。

是不是感覺(jué)豁然開(kāi)朗了呢？

在明白了 Kubernetes 的這個(gè)本質(zhì)之后，我們回過(guò)頭來(lái)再看原本一些比較難以理解的設(shè)定，可能會(huì)更容易體會(huì)到一些本質(zhì)的東西。

比如，今天我們?cè)谑褂?Kubernetes 的時(shí)候之所以要寫(xiě)那么多 YAML 文件，其實(shí)是因?yàn)槲覀冃枰ㄟ^(guò)一種方式把 Data 提交給 Kubernetes 這個(gè)控制系統(tǒng)。而在這個(gè)過(guò)程中，YAML 只是一種為了讓人類(lèi)能夠格式化的編寫(xiě) Data 的一個(gè)載體。如果做一個(gè)類(lèi)比，那么 YAML 就像我們小時(shí)候作業(yè)本里的“田字格”，而“田字格”里寫(xiě)的那些文字，才是 Kubernetes 真正關(guān)心的 Data 和整個(gè)系統(tǒng)運(yùn)轉(zhuǎn)的核心。

細(xì)心的讀者此時(shí)應(yīng)該已經(jīng)想到了，既然 Kubernetes 需要處理這些 Data，那么 Data 本身不是也應(yīng)該有一個(gè)固定的“格式”這樣 Kubernetes 才能解析它們呢？沒(méi)錯(cuò)，這里的格式在 Kubernetes 中就叫做 API 對(duì)象的 Schema。如果你經(jīng)常編寫(xiě)自定義 Controller 的話(huà)，可能就會(huì)對(duì)這個(gè) Schema 的體感比較深刻：CRD 就是一個(gè)專(zhuān)門(mén)用來(lái)定義 Schema 的一個(gè)特殊的 API 對(duì)象。

YAML 工程師？不，你是數(shù)據(jù)庫(kù)工程師！

上述 Kubernetes 的 IaD 的本質(zhì)，決定了它的工作原理其實(shí)更類(lèi)似一個(gè)“數(shù)據(jù)庫(kù)”，而不像傳統(tǒng)意義上的分布式系統(tǒng)。這個(gè)差異，也是導(dǎo)致 Kubernetes 學(xué)習(xí)成本比較陡峭的一個(gè)根本性原因。

而從這個(gè)角度來(lái)講，Kubernetes 為你暴露出來(lái)的各種 API 對(duì)象，實(shí)際上就是一張張預(yù)先定義好 Schema 的表（Table）。而我們絞盡腦汁編寫(xiě)出的那些 YAML 文件，其實(shí)就是對(duì)這些表中的數(shù)據(jù)（Data）進(jìn)行的增刪改查（CURD）。而 YAML 這個(gè)工具本身，則好比 SQL 一樣是一個(gè)幫助你對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)進(jìn)行操作的工具和載體。而唯一跟傳統(tǒng)數(shù)據(jù)庫(kù)不太一樣的是，Kubernetes 在拿到這些數(shù)據(jù)之后，并不以把這些數(shù)據(jù)持久化起來(lái)為目的，而是希望通過(guò)這些數(shù)據(jù)來(lái)驅(qū)動(dòng) Controller 執(zhí)行某些操作，從而將整個(gè)系統(tǒng)的狀態(tài)逐步調(diào)整為跟數(shù)據(jù)中聲明的終態(tài)一致，這就回到我們前面所說(shuō)的“控制理論”部分了。

也正是由于? Kubernetes 這樣整套體系都圍繞著“數(shù)據(jù)”這個(gè)一等公民運(yùn)轉(zhuǎn)的設(shè)定，才使得“編寫(xiě)和操作 YAML文件”成為了 Kubernetes 工程師的幾乎唯一的日常工作。不過(guò)，在理解了本文今天介紹的 IaD 的思想之后，你其實(shí)大可以把自己比作一個(gè)“數(shù)據(jù)庫(kù)工程師”了，而且這個(gè) TItle 確實(shí)要比“YAML 工程師”更加貼切一些。

Kubernetes 項(xiàng)目的“視圖層”

正如前文所述，如果你從一個(gè)“數(shù)據(jù)庫(kù)”的角度重新審視 Kubernetes 設(shè)計(jì)的話(huà)，就不難發(fā)現(xiàn) Kubernetes 的很多設(shè)計(jì)背后其實(shí)有著非常精妙的思想。比如：

• 數(shù)據(jù)模型 -? Kubernetes 的各種 API 對(duì)象與 CRD 機(jī)制
• 數(shù)據(jù)攔截校驗(yàn)和修改機(jī)制 - Kubernetes Admission Hook
• 數(shù)據(jù)驅(qū)動(dòng)機(jī)制 - Kubernetes Controller/Operator
• 數(shù)據(jù)監(jiān)聽(tīng)變更與索引機(jī)制 - Kubernetes 的 Informer 機(jī)制
• ……

另外一方面，隨著 Kubernetes 基礎(chǔ)設(shè)施越來(lái)越復(fù)雜，第三方插件與能力越來(lái)越多，社區(qū)的維護(hù)者們也發(fā)現(xiàn) Kubernetes 這個(gè)“數(shù)據(jù)庫(kù)”內(nèi)置的“數(shù)據(jù)表”無(wú)論從規(guī)模還是復(fù)雜度上，都正在迎來(lái)爆炸式的增長(zhǎng)。所以? Kubernetes 社區(qū)很早就在討論如何給 Kubernetes? 設(shè)計(jì)出一個(gè)“數(shù)據(jù)視圖（View）”出來(lái)，即：

而這樣一個(gè)構(gòu)建在 Kubernetes 內(nèi)置 API 資源之上的“視圖層”給 Kubernetes 使用者帶來(lái)的好處，跟數(shù)據(jù)庫(kù)中的“視圖”是非常類(lèi)似的，比如：

簡(jiǎn)化和更改數(shù)據(jù)格式和表示

Kubernetes 的視圖層，需要能夠給研發(fā)和運(yùn)維暴露更簡(jiǎn)潔的、經(jīng)過(guò)抽象后的應(yīng)用層 API 對(duì)象，而不是原始的基礎(chǔ)設(shè)施層 API 對(duì)象。而一個(gè)視圖層對(duì)象具體如何定義，自由度應(yīng)該完全在用戶(hù)手中，不需要拘束在底層 Kubernetes 內(nèi)置對(duì)象的 Schema 上。

簡(jiǎn)化復(fù)雜的數(shù)據(jù)操作（簡(jiǎn)化 SQL ）

經(jīng)過(guò)抽象后產(chǎn)生的視圖層對(duì)象，不僅在 UI 上需要更加簡(jiǎn)單，還需要可以定義和管理非常復(fù)雜的底層 Kubernetes 資源拓?fù)?#xff0c;從而降低用戶(hù)管理 Kubernetes 應(yīng)用的復(fù)雜度和心智負(fù)擔(dān)。

保護(hù)底層數(shù)據(jù)表

研發(fā)和運(yùn)維直接操作的是視圖層對(duì)象，所以底層的 Kubernetes 原始對(duì)象是被保護(hù)起來(lái)的。這使得這些 Kubernetes 的原始對(duì)象可以在用戶(hù)無(wú)感的情況下進(jìn)行任意變更和升級(jí)。

復(fù)用數(shù)據(jù)操作（復(fù)用 SQL）

由于視圖層對(duì)象與底層基礎(chǔ)設(shè)施是完全解耦的，所以一個(gè)通過(guò)視圖層聲明的應(yīng)用或者運(yùn)維能力可以在任意 Kubernetes 集群漂移，而不必?fù)?dān)心這些集群支持的能力是不是有差異。

視圖依然是表，支持標(biāo)準(zhǔn)的表操作

Kubernetes 的視圖層對(duì)象必須依然是標(biāo)準(zhǔn)的 Kubernetes 對(duì)象，這樣 Kubernetes 對(duì) API 對(duì)象的所有操作和原語(yǔ)對(duì)，才會(huì)對(duì)視圖層對(duì)象適用。我們不能在 Kubernetes API 模型上引入額外的心智負(fù)擔(dān)。

給 Kubernetes 設(shè)置視圖層的想法雖然最終沒(méi)有在 Kubernetes 上游落地，但是卻成為了社區(qū)中大多數(shù)大規(guī)模玩家的主流做法。比如 Pinterest 就在 Kubernetes 之上設(shè)計(jì)了一個(gè) PInterestService 的 CRD 來(lái)描述和定義 Pinterest 的應(yīng)用，這個(gè) CRD 其實(shí)就是一個(gè)視圖層對(duì)象。但這個(gè)做法對(duì)于絕大多數(shù)企業(yè)來(lái)說(shuō)，還是太過(guò)簡(jiǎn)陋了。要知道，數(shù)據(jù)的“視圖”并不只是數(shù)據(jù)的簡(jiǎn)單抽象和翻譯，在真正的生產(chǎn)環(huán)境中要大規(guī)模使用視圖層，至少需要解決幾個(gè)關(guān)鍵問(wèn)題：

• 如何定義和管理視圖層對(duì)象與底層 K8s 對(duì)象之間的映射關(guān)系？注意這里絕不是簡(jiǎn)單的一對(duì)一映射，一個(gè)視圖層對(duì)象可能會(huì)對(duì)應(yīng)多個(gè) K8s 對(duì)象。
• 如何對(duì)“運(yùn)維能力”進(jìn)行建模和抽象？一個(gè)真正的應(yīng)用，絕不只是簡(jiǎn)單的 Deployment 或者 Operator，它一定是待運(yùn)行程序與相應(yīng)的運(yùn)維能力的有機(jī)組合（比如一個(gè)容器化應(yīng)用和它的水平擴(kuò)展策略）。這些運(yùn)維能力如何通過(guò)在應(yīng)用定義里體現(xiàn)出來(lái)？全定義成 annotation 可行嗎？
• 如何管理運(yùn)維能力同待運(yùn)行程序之間的綁定關(guān)系？如何將這個(gè)綁定關(guān)系映射成底層 K8s 當(dāng)中真正的執(zhí)行關(guān)系？
• 如何通過(guò)視圖層對(duì)象標(biāo)準(zhǔn)化的定義云資源，比如一個(gè)阿里云的 RDS 實(shí)例？
• ……

上述這些問(wèn)題，正是 Kubernetes 上游最終沒(méi)能將“視圖層”落地的重要原因之一，同時(shí)也是諸如??Open Application Model （OAM）這樣的 Kubernetes 應(yīng)用層開(kāi)源項(xiàng)目主要的關(guān)注點(diǎn)。需要指出的是，僅靠一個(gè) OAM 這樣一個(gè)“規(guī)范”是依然不足以解決上述所有問(wèn)題的，Kubernetes 視圖層的建立，必須借助標(biāo)準(zhǔn)的視圖層依賴(lài)庫(kù)在實(shí)現(xiàn)層予以保證，才能真正在 Kubernetes 中享受到“數(shù)據(jù)視圖”帶來(lái)的優(yōu)勢(shì)和便捷。目前社區(qū)中比較強(qiáng)大的 Kubernetes 視圖層依賴(lài)庫(kù)，是來(lái)自 Crossplane 團(tuán)隊(duì)的?oam-kubernetes-runtime：https://github.com/crossplane/oam-kubernetes-runtime。

總結(jié)

Kubernetes 這個(gè)以 IaD 為核心的、類(lèi)似“數(shù)據(jù)庫(kù)”設(shè)計(jì)，正是這個(gè)社區(qū)繁榮發(fā)展背后的重要理論基礎(chǔ)。然而，IaD 的思想本身也是一把雙刃劍，它催生出來(lái)的蓬勃發(fā)展的社區(qū)的另一面，是無(wú)數(shù)個(gè)“各自為政”的 Controller/Operator，以及一個(gè)通過(guò)這些 Controller 拼裝出來(lái)的、復(fù)雜度極高的 Kubernetes 集群。這樣的一個(gè)生產(chǎn)級(jí)別復(fù)雜度的 Kubernetes 集群，距離一個(gè)真正受研發(fā)和運(yùn)維喜愛(ài)的云原生應(yīng)用管理平臺(tái)，差距可謂十萬(wàn)八千里。

在過(guò)去的 5 年里，Kubernetes 項(xiàng)目的巨大成功，實(shí)際上是基礎(chǔ)設(shè)施能力（比如網(wǎng)絡(luò)、存儲(chǔ)、容器）在聲明式 API 下逐步標(biāo)準(zhǔn)化和統(tǒng)一化的一個(gè)過(guò)程，而隨著 OAM 等 Kubernetes 應(yīng)用層技術(shù)的逐步普及，我們已經(jīng)看見(jiàn)一個(gè)標(biāo)準(zhǔn)化應(yīng)用層生態(tài)正在付出水面。越來(lái)越多的團(tuán)隊(duì)正在嘗試通過(guò)更加用戶(hù)友好的數(shù)據(jù)視圖層，對(duì)最終用戶(hù)暴露出喜聞樂(lè)見(jiàn)的 API，同時(shí)對(duì)基礎(chǔ)設(shè)施工程師提供出更加強(qiáng)大的橫向連通與模塊化的平臺(tái)能力。

與此同時(shí)，Kubernetes 這個(gè)“數(shù)據(jù)庫(kù)”其他欠缺的部分，也一定會(huì)越來(lái)越多的在社區(qū)涌現(xiàn)出來(lái)。比如今天正在迅速成熟的 Open Policy Agent（OPA）項(xiàng)目，可以認(rèn)為是“數(shù)據(jù)攔截校驗(yàn)和修改機(jī)制”這一層的不斷進(jìn)化結(jié)果。再比如阿里巴巴內(nèi)部在“萬(wàn)節(jié)點(diǎn)”集群中推進(jìn)的管控鏈路性能調(diào)優(yōu)工作，其理論基礎(chǔ)和實(shí)踐，跟今天的數(shù)據(jù)庫(kù)性能優(yōu)化，更是有異曲同工之妙的。

如果你有任何關(guān)于 IaD 系統(tǒng)想法，非常歡迎釘釘掃碼加群同我們交流！

活動(dòng)推薦

美國(guó)時(shí)間 2020 年 5 月 27 日，知名復(fù)雜環(huán)境應(yīng)用交付與基礎(chǔ)設(shè)施管理項(xiàng)目 Crossplane 將聯(lián)合 Open Application Model （OAM）社區(qū)共同舉辦 Crossplane Community Day。

谷歌公司 Kubernetes 項(xiàng)目首席布道師?Kelsey Hightower、阿里云資深技術(shù)專(zhuān)家、CNCF TOC?李響與微軟杰出工程師、Kubernetes 聯(lián)合創(chuàng)始人?Brendan Burns?將共同出席并做關(guān)于標(biāo)準(zhǔn)化定義應(yīng)用與基礎(chǔ)設(shè)施的重要主題演講。

在本次 Crossplane Community Day 上，你將了解到 OAM 社區(qū)同 Crossplane 項(xiàng)目正在展開(kāi)的深度技術(shù)合作，以及世界各地的平臺(tái)構(gòu)建者如何通過(guò) OAM 和 Crossplane 來(lái)配置和管理面向復(fù)雜環(huán)境的應(yīng)用程序、基礎(chǔ)架構(gòu)與云服務(wù)。

在阿里巴巴云原生公眾號(hào)后臺(tái)回復(fù)復(fù)關(guān)鍵字?crossplane，或點(diǎn)擊鏈接直接獲得線(xiàn)上峰會(huì)參與方式。

招人啦！

云原生應(yīng)用平臺(tái)團(tuán)隊(duì)誠(chéng)邀 Kubernetes/Serverless/ PaaS /應(yīng)用交付 領(lǐng)域?qū)＜?#xff08; P7-P8 ）加盟，一起參與到 OAM 建設(shè)中：

• 工作年限：建議 P7 三年起，P8 五年起，具體看實(shí)際能力；
• 工作地點(diǎn)：國(guó)內(nèi)：北京，杭州，深圳；
• 崗位包含：架構(gòu)師、技術(shù)專(zhuān)家、全棧工程師等。

簡(jiǎn)歷立刻回復(fù)，2~3 周出結(jié)果，簡(jiǎn)歷投遞：jianbo.sjb AT alibaba-inc.com

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

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

總結(jié)

以上是生活随笔為你收集整理的Kubernetes 是一个“数据库”吗？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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