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

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

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

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

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

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

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

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

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

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

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

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

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

這個方法門檻比較高，因為每個人對于這個系統(tǒng)本身感興趣程度不太一樣，學(xué)習(xí)能力也不太一樣。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

《云原生實踐公開課》

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

點擊鏈接即可免費觀看課程：https://developer.aliyun.com/learning/roadmap/cloudnative2020

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

總結(jié)

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

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