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

**影片回顧連結：[https://www.bilibili.com/video/BV1Dv411v7P4/](https://www.bilibili.com/video/BV1Dv411v7P4/)**

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

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

![1.png](https://ucc.alicdn.com/pic/developer-ecology/2d68a9e851ef412cbd27da9c9a1c3518.png)

# 上 Kubernetes 有什麼業務價值？

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

![3.png](https://ucc.alicdn.com/pic/developer-ecology/99770cfe70984e25a3148d4794bdc368.png)

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

![4.png](https://ucc.alicdn.com/pic/developer-ecology/e0655876fc674de48c8c3d12b8d13604.png)

實際上透過 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 專家

![5.png](https://ucc.alicdn.com/pic/developer-ecology/080aa9c428714c1d925b1e2463fdd85d.png)

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

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

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

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

![6.png](https://ucc.alicdn.com/pic/developer-ecology/71a6d357b3cd4bc8984b0b9d106fd8f1.png)

那這個具體是怎麼做呢？還是在 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 能力是無限的，非常強大。

![7.png](https://ucc.alicdn.com/pic/developer-ecology/f46c517efae546a59a73db0ec12f6145.png)

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

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

## 傳統 PaaS 的“能力困境”

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

![8.png](https://ucc.alicdn.com/pic/developer-ecology/8ff498b8afef4a0aac606e05b96abeb4.png)

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

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

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

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

## 特徵一：透過原生的宣告式 API 和外掛體系，暴露面向終端使用者的上層語義和抽象

![9.png](https://ucc.alicdn.com/pic/developer-ecology/208853897fd9437fb80026914fa8011a.png)

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

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

## 特徵二：上層語義和抽象可插拔，可擴充套件，沒有抽象程度鎖定和任何能力限制

![10.png](https://ucc.alicdn.com/pic/developer-ecology/f84976aa802341e8a99baef479a39b11.png)

第二個點很重要，上層語義和抽象必須是可插拔的，必須是可擴充套件的，是無縫相容利用 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](https://developer.aliyun.com/learning/roadmap/cloudnative2020)

> “[阿里巴巴雲原生](https://mp.weixin.qq.com/s/cVGFSXJHAeGpGJVy9YPYZg)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的公眾號。”

靈魂拷問，上 Kubernetes 有什麼業務價值？

相關文章