本文整理自 2020 年 7 月 22 日《基于 Kubernetes 與 OAM 構(gòu)建統(tǒng)一、標(biāo)準(zhǔn)化的應(yīng)用管理平臺(tái)》主題線上網(wǎng)絡(luò)研討會(huì)。文章共分為上下兩篇，本文為上篇，主要和大家介紹上 Kubernetes 有什么業(yè)務(wù)價(jià)值，以及什么是“以應(yīng)用為中心”的 Kubernetes。下篇將跟大家具體分享如何構(gòu)建“以應(yīng)用為中心”的 Kubernetes。

視頻回顧鏈接：https://www.bilibili.com/video/BV1Dv411v7P4/

關(guān)注阿里巴巴云原生公眾號(hào)，回復(fù) “0722” 即可下載 PPT

非常感謝大家來(lái)到 CNCF 的直播，我是張磊，阿里云的高級(jí)技術(shù)專家，Kubernetes 項(xiàng)目資深維護(hù)者。同時(shí)也是 CNCF 應(yīng)用交付領(lǐng)域 co-chair。我今天給大家?guī)?lái)的分享主題是《基于 Kubernetes 與 OAM 構(gòu)建統(tǒng)一、標(biāo)準(zhǔn)化的應(yīng)用管理平臺(tái)》。在封面上有個(gè)釘釘群組二維碼。大家可以通過(guò)這個(gè)二維碼進(jìn)入線上交流群。

上 Kubernetes 有什么業(yè)務(wù)價(jià)值？

今天要演講的主題是跟應(yīng)用管理或者說(shuō)是云原生應(yīng)用交付是相關(guān)的。首先我們想要先回答這么一個(gè)問(wèn)題：為什么我們要基于 Kubernetes 去構(gòu)建一個(gè)應(yīng)用管理平臺(tái)？

上圖是一個(gè)本質(zhì)的問(wèn)題，我們?cè)诼涞?K8s 經(jīng)常遇到的一個(gè)問(wèn)題。尤其是我們的業(yè)務(wù)方會(huì)問(wèn)到這么一個(gè)問(wèn)題，我們上 Kubernetes 有什么業(yè)務(wù)價(jià)值？這時(shí)候作為我們 K8s 工程師往往是很難回答的。原因在哪里呢？實(shí)際上這跟 K8s 的定位是相關(guān)的。K8s 這個(gè)項(xiàng)目呢，如果去做一個(gè)分析的話，我們會(huì)發(fā)現(xiàn) K8s 不是一個(gè) PaaS 或者應(yīng)用管理的平臺(tái)。實(shí)際上它是一個(gè)標(biāo)準(zhǔn)化的能力接入層。什么是能力接入層呢？大家可以看一下下圖。

實(shí)際上通過(guò) Kubernetes 對(duì)用戶暴露出來(lái)的是一組聲明式 API，這些聲明式 API 無(wú)論是 Pod 還是 Service 都是對(duì)底層基礎(chǔ)設(shè)施的一個(gè)抽象。比如 Pod 是對(duì)一組容器的抽象，而 Deployment 是對(duì)一組 pod 的抽象。而 Service 作為 Pod 的訪問(wèn)入口，實(shí)際上是對(duì)集群基礎(chǔ)設(shè)施：網(wǎng)絡(luò)、網(wǎng)關(guān)、iptables 的一個(gè)抽象。Node 是對(duì)宿主機(jī)的抽象。Kubernetes 還提供了我們叫做 CRD（也就是 Custom Resource）的自定義對(duì)象。讓你自己能夠自定義底層基礎(chǔ)設(shè)施的一個(gè)抽象。

而這些抽象本身或者是 API 本身，是通過(guò)另外一個(gè)模式叫做控制器(Controller)去實(shí)現(xiàn)的。通過(guò)控制器去驅(qū)動(dòng)我們的底層基礎(chǔ)設(shè)施向我的抽象逼近，或者是滿足我抽象定義的一個(gè)終態(tài)。

所以本質(zhì)來(lái)講，Kubernetes 他的專注點(diǎn)是“如何標(biāo)準(zhǔn)化的接入來(lái)自于底層，無(wú)論是容器、虛機(jī)、負(fù)載均衡各種各樣的一個(gè)能力，然后通過(guò)聲明式 API 的方式去暴露給用戶”。這就意味著 Kubernetes 實(shí)際用戶不是業(yè)務(wù)研發(fā)，也不是業(yè)務(wù)運(yùn)維。那是誰(shuí)呢？是我們的平臺(tái)開發(fā)者。希望平臺(tái)開發(fā)者能夠基于 Kubernetes 再去做上層的框架或者是平臺(tái)。那就導(dǎo)致了今天我們的業(yè)務(wù)研發(fā)和業(yè)務(wù)運(yùn)維對(duì) Kubernetes 直接暴露出來(lái)的這一層抽象，感覺(jué)并不是很友好。

這里的關(guān)鍵點(diǎn)在于，Kubernetes 對(duì)這些基礎(chǔ)設(shè)施的抽象，跟業(yè)務(wù)研發(fā)和業(yè)務(wù)運(yùn)維看待系統(tǒng)的角度是完全不同的。這個(gè)抽象程度跟業(yè)務(wù)研發(fā)和業(yè)務(wù)運(yùn)維希望的抽象程度也是不一樣的。語(yǔ)義完全對(duì)不上，使用習(xí)慣也是有很大的鴻溝。所以說(shuō)為了解決這樣一個(gè)問(wèn)題，都在思考一些解決方法。怎么能讓我 Kubernetes 提供的基礎(chǔ)設(shè)施的抽象能夠滿足我業(yè)務(wù)研發(fā)和業(yè)務(wù)運(yùn)維的一個(gè)訴求呢？怎么能讓 Kubernetes 能夠成為業(yè)務(wù)研發(fā)和業(yè)務(wù)運(yùn)維喜歡的一個(gè)平臺(tái)呢？

方法一：把所有人都變成 Kubernetes 專家

假如我們所有人都是 Kubernetes 專家，那當(dāng)然會(huì)喜歡 Kubernetes 對(duì)我提供的服務(wù)，這里給他發(fā)個(gè) Kubernetes 的 PhD 博士。這里我強(qiáng)烈推薦阿里云和 CNCF 主辦的云原生技術(shù)公開課。大家試試學(xué)完這門課程后，能不能變成 Kubernetes 專家。

這個(gè)方法門檻比較高，因?yàn)槊總€(gè)人對(duì)于這個(gè)系統(tǒng)本身感興趣程度不太一樣，學(xué)習(xí)能力也不太一樣。

方法二：構(gòu)建一個(gè)面向用戶的應(yīng)用管理平臺(tái)

業(yè)界常見的方法，大家會(huì)基于 Kubernetes 構(gòu)建一個(gè)面向用戶的應(yīng)用管理平臺(tái)，或者說(shuō)是一個(gè) PaaS，有人直接做成一個(gè) Serverless。

那這個(gè)具體是怎么做呢？還是在 Kubernetes 之上，會(huì)搭建一個(gè)東西叫做上層應(yīng)用管理平臺(tái)，這個(gè)上層應(yīng)用平臺(tái)對(duì)業(yè)務(wù)研發(fā)和業(yè)務(wù)運(yùn)維暴露出來(lái)一個(gè)上層的 API。比如說(shuō)業(yè)務(wù)研發(fā)這一側(cè)，他不太會(huì)暴露 Pod，Deployment 這樣的抽象。只會(huì)暴露出來(lái) CI/CD 流水線。或者說(shuō)一個(gè)應(yīng)用，WordPress，一個(gè)外部網(wǎng)站，暴露出這樣一個(gè)上層的概念，這是第一個(gè)部分。

第二部分，它也會(huì)給業(yè)務(wù)運(yùn)維暴露出一組運(yùn)維的 API。比如說(shuō)：水平擴(kuò)容，發(fā)布策略，分批策略，訪問(wèn)控制，流量配置。這樣的話有一個(gè)好處，業(yè)務(wù)研發(fā)和業(yè)務(wù)運(yùn)維面對(duì)的 API 不是 Kubernetes 底層的 API，不是 Node，不是 Service，不是 Deployment，不是我們的 CRD。是這樣一組經(jīng)過(guò)抽象經(jīng)過(guò)封裝后的 API。這樣的業(yè)務(wù)研發(fā)和業(yè)務(wù)運(yùn)維用起來(lái)會(huì)跟他所期望的 Ops 流水線，它所熟悉的使用體檢有個(gè)天然的結(jié)合點(diǎn)。

所以說(shuō)只有這么做了之后，我們才能夠跟我們的業(yè)務(wù)老大說(shuō)，Kubernetes 的業(yè)務(wù)價(jià)值來(lái)了。實(shí)際上業(yè)務(wù)價(jià)值不是在 Kubernetes 這一層，而是在 Kubernetes 往上的這一層–“你的解決方案”。所以說(shuō)這樣的一個(gè)系統(tǒng)構(gòu)建出來(lái)之后呢，實(shí)際上是對(duì) Kubernetes 又做了一層封裝。變成了很多公司都有的，比如說(shuō) Kubernetes 應(yīng)用平臺(tái)。這是一個(gè)非常常見的做法。相比于我們讓研發(fā)運(yùn)維變成 Kubernetes 專家來(lái)說(shuō)會(huì)更加實(shí)際一點(diǎn)。

但是我們?cè)诎⒗镆埠?#xff0c;在很多社區(qū)的實(shí)際場(chǎng)景也好，它往往會(huì)伴隨著這么一個(gè)問(wèn)題。這個(gè)問(wèn)題是：今天 Kubernetes 的生態(tài)是非常非常繁榮的，下圖是我在 CNCF 截的圖，好幾百個(gè)項(xiàng)目，幾千個(gè)可以讓我們 Kubernetes 即插即用的能力。比如 istio，KEDA，Promethues 等等都是 Kubernetes 的插件。正是基于這么一個(gè)擴(kuò)展性非常高的聲明式 API 體系才會(huì)有了這么繁榮的 Kubernetes 生態(tài)。所以可以認(rèn)為 Kubernetes 能力是無(wú)限的，非常強(qiáng)大。

可是這么一個(gè)無(wú)限能力，如果對(duì)接到一個(gè)非常傳統(tǒng)的，非常經(jīng)典的一個(gè)應(yīng)用管理平臺(tái)。比如說(shuō)我們的 PaaS 上，如 Cloud Foundry。立刻就會(huì)發(fā)現(xiàn)一個(gè)問(wèn)題，PaaS 雖然對(duì)用戶提供的是很友好的 API，但是這個(gè) API 本身是有限的，是難以擴(kuò)展的。比如說(shuō) Cloud Foundry 要給用戶使用，就有 Buildpack 這么一個(gè)概念，而不是 Kubernetes 所有的能力都能給用戶去使用。其實(shí)幾乎所有的 PaaS 都會(huì)存在這么一個(gè)問(wèn)題。它往上暴露的是一個(gè)用戶的API，是不可擴(kuò)展的，是個(gè)有限集。

下面一個(gè)非常龐大繁榮的 Kubernetes 生態(tài)，沒(méi)辦法直接給用戶暴露出去。可能每使用一個(gè)插件就要重新迭代開發(fā)你的 PaaS，重新交付你的 PaaS。這個(gè)是很難接受的。

傳統(tǒng) PaaS 的“能力困境”

這問(wèn)題是一個(gè)普遍存在的問(wèn)題，我們叫做傳統(tǒng) PaaS 的“能力困境”。

本質(zhì)上來(lái)說(shuō)這個(gè)困境是什么意思呢？K8s 生態(tài)繁榮多樣的應(yīng)用基礎(chǔ)設(shè)施能力，與業(yè)務(wù)開發(fā)人員日益增長(zhǎng)的應(yīng)用管理訴求，中間存在一個(gè)傳統(tǒng)的 PaaS，他就會(huì)變成一個(gè)瓶頸。K8s 無(wú)限的能力無(wú)法讓你的研發(fā)與運(yùn)維立刻用到。所以傳統(tǒng) PaaS 就會(huì)成為一個(gè)顯而易見的瓶頸。

這樣給我?guī)?lái)一個(gè)思考：我們能不能拋棄傳統(tǒng) PaaS 的一個(gè)做法，基于 K8s 打造高可擴(kuò)展的應(yīng)用管理平臺(tái)。我們想辦法能把 K8s 能力無(wú)縫的透給用戶，同時(shí)又能提供傳統(tǒng) PaaS 比較友好的面向研發(fā)運(yùn)維的使用體驗(yàn)?zāi)?#xff1f;

其實(shí)可以從另外一個(gè)角度思考這個(gè)問(wèn)題：如何基于 K8s 打造高可擴(kuò)展的應(yīng)用管理平臺(tái)，實(shí)際上等同于 如何打造一個(gè)“以應(yīng)用為中心的”的 Kubernetes。或者說(shuō)能不能基于 Kubernetes 去封裝下，讓它能夠像 PaaS 一樣，去面向我的實(shí)際用戶去使用呢？這個(gè)就是我們要聊的關(guān)鍵點(diǎn)。

什么是“以應(yīng)用為中心”的 Kubernetes

特征一：通過(guò)原生的聲明式 API 和插件體系，暴露面向最終用戶的上層語(yǔ)義和抽象

我們不是說(shuō)要在 Kubernetes 上蓋一個(gè) PaaS，或者說(shuō)是蓋一個(gè)大帽子，不干這件事情。因?yàn)?K8s 本身可以擴(kuò)展，可以寫一組 CRD，把我們要的 API 給裝上去。比如 CI/CD 流水線，就可以像 Tektong 系統(tǒng)直接使用 pipeline。應(yīng)用也可以通過(guò)某些項(xiàng)目直接暴露出來(lái)。運(yùn)維這一側(cè)的發(fā)布擴(kuò)容等，都可以通過(guò)安裝一個(gè) Operator 去解決問(wèn)題。當(dāng)然也需要一些技術(shù)將這些運(yùn)維策略綁定到應(yīng)用或者流水線中。

這就是我們第一個(gè)點(diǎn)，以應(yīng)用為中心的 K8s 首先是暴露給用戶的語(yǔ)義和 API，而不是非常底層的，比如 Service、Node 或者是 Ingress。可能用戶都不知道什么意思，也不知道怎么寫的。

特征二：上層語(yǔ)義和抽象可插拔，可擴(kuò)展，沒(méi)有抽象程度鎖定和任何能力限制

第二個(gè)點(diǎn)很重要，上層語(yǔ)義和抽象必須是可插拔的，必須是可擴(kuò)展的，是無(wú)縫兼容利用 K8s 的可擴(kuò)展能力的。并且也不應(yīng)該有對(duì)抽象程度的鎖定。

舉個(gè)例子：比如一個(gè)應(yīng)用本身既可以是 Deployment，這是一個(gè)比較低程度的抽象。也可以是 Knative Service，這是一個(gè)相對(duì)來(lái)說(shuō)高程度的抽象，相對(duì)于 deployment 來(lái)說(shuō)比較簡(jiǎn)單，只有一個(gè) PodTemplate。甚至可以更簡(jiǎn)單，可以是一個(gè) Service，或者是個(gè) Function。這個(gè)時(shí)候抽象程度就很高。如果基于 K8s 做一個(gè)以應(yīng)用為中心的框架的話，它應(yīng)該是能夠暴露工作負(fù)載的多種抽象程度的。而不是說(shuō)單獨(dú)去使用 Knative，只能暴露出 Knative Service。假如我想使用 Knative 部署一個(gè) Statefulset，這當(dāng)然是不可以的。抽象程度是完全不一致的。所以我希望這個(gè)以應(yīng)用為中心的 K8s 是沒(méi)有抽象程度的鎖定的。

同時(shí)也不應(yīng)該有能力的限制，什么叫沒(méi)有能力的限制呢？比如從運(yùn)維側(cè)舉個(gè)例子，運(yùn)維側(cè)有很多很多擴(kuò)容策略、發(fā)布策略等等。如果我想新加一個(gè)策略能力，它應(yīng)該是非常簡(jiǎn)單的，就像在 K8s 安裝一個(gè) Operator 一樣非常簡(jiǎn)單，能 helm insatll 就能搞定，答案是必須的。假如需要添加一個(gè)水平擴(kuò)容，直接 helm install vpa 就能解決。通過(guò)這種方式才能做一個(gè)以應(yīng)用為中心的 Kubernetes。

可以看到它跟我們的傳統(tǒng) PaaS 還是有很大區(qū)別的，它的可擴(kuò)展能力非常非常強(qiáng)。它本質(zhì)上就是一個(gè) K8s，但是它跟專有的 Service，Knative，OpenFaaS 也不一樣。它不會(huì)把抽象程度鎖定到某一種 Workload 上，你的 Workload 是可以隨意去定義。運(yùn)維側(cè)的能力也可以隨意可插拔的去定義。這才是我們叫做一個(gè)以應(yīng)用為中心的 Kubernetes。那么這么一個(gè) Kubernetes 怎么做呢？

后續(xù)我們將會(huì)在下篇文章中詳細(xì)為大家解讀如何構(gòu)建“以應(yīng)用為中心”的 Kubernetes？以及構(gòu)建這么一個(gè)以用戶為中心的 Kubernetes，需要做幾個(gè)層級(jí)的事情。

《云原生實(shí)踐公開課》

去年，CNCF 與 阿里云聯(lián)合發(fā)布了《云原生技術(shù)公開課》已經(jīng)成為了 Kubernetes 開發(fā)者的一門“必修課”。今天，阿里云再次集結(jié)多位具有豐富云原生實(shí)踐經(jīng)驗(yàn)的技術(shù)專家，正式推出《云原生實(shí)踐公開課》。課程內(nèi)容由淺入深，專注講解“ 落地實(shí)踐”。還為學(xué)習(xí)者打造了真實(shí)、可操作的實(shí)驗(yàn)場(chǎng)景，方便驗(yàn)證學(xué)習(xí)成果，也為之后的實(shí)踐應(yīng)用打下堅(jiān)實(shí)基礎(chǔ)。課程已經(jīng)正式上線，歡迎大家觀看。

點(diǎn)擊鏈接即可免費(fèi)觀看課程：https://developer.aliyun.com/learning/roadmap/cloudnative2020

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

總結(jié)

以上是生活随笔為你收集整理的灵魂拷问，上 Kubernetes 有什么业务价值？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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