本文整理自 2020 年 7 月 22 日《基于 Kubernetes 與 OAM 構建統一、標準化的應用管理平臺》主題線上網絡研討會。文章共分為上下兩篇，本文為上篇，主要和大家介紹上 Kubernetes 有什么業務價值，以及什么是“以應用為中心”的 Kubernetes。下篇將跟大家具體分享如何構建“以應用為中心”的 Kubernetes。

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

關注阿里巴巴云原生公眾號，回復 “0722” 即可下載 PPT

非常感謝大家來到 CNCF 的直播，我是張磊，阿里云的高級技術專家，Kubernetes 項目資深維護者。同時也是 CNCF 應用交付領域 co-chair。我今天給大家帶來的分享主題是《基于 Kubernetes 與 OAM 構建統一、標準化的應用管理平臺》。在封面上有個釘釘群組二維碼。大家可以通過這個二維碼進入線上交流群。

上 Kubernetes 有什么業務價值？

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

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

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

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

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

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

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

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

這個方法門檻比較高，因為每個人對于這個系統本身感興趣程度不太一樣，學習能力也不太一樣。

方法二：構建一個面向用戶的應用管理平臺

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

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

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

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

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

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

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

傳統 PaaS 的“能力困境”

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

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

這樣給我帶來一個思考：我們能不能拋棄傳統 PaaS 的一個做法，基于 K8s 打造高可擴展的應用管理平臺。我們想辦法能把 K8s 能力無縫的透給用戶，同時又能提供傳統 PaaS 比較友好的面向研發運維的使用體驗呢？

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

什么是“以應用為中心”的 Kubernetes

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

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

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

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

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

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

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

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

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

《云原生實踐公開課》

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

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

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

總結

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

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