![](https://intranetproxy.alipay.com/skylark/lark/0/2022/jpeg/22456429/1647329247027-50561873-b0c1-4f39-962b-90adc46f75aa.jpeg#clientId=u74b0ab00-b534-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=udf1db91e&margin=%5Bobject%20Object%5D&originHeight=319&originWidth=799&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u8b169344-304b-4fdf-a482-42a3242e26c&title=)
作者 | 陳曉宇（阿里雲技術專家）
策劃 | 褚杏娟

伴隨著雲原生的發展，從早先的單機版 Docker 到 Kubernetes 的編排領域的一統江湖，再到雲上託管 Kubernetes，技術風雨變化。今天我們就沿著歷史的脈絡，一起看一下 Serverless Kubernetes 的發展史。
# 故事，從 Docker 講起

故事雖然從 Docker 講起，但我們不能忽視了 IaaS（Infrastructure as a Service）先輩們在前面的披荊斬棘，以及雲端計算大佬們很早就確定的雲端計算髮展規劃。

在十幾年前，先輩們從按照使用者使用（雲平臺提供能力）維度，將雲分為三層：

- IaaS：Infrastructure as a Service，基礎設施即服務，提供虛擬機器或者其他基礎資源作為服務提供給使用者；

- PaaS：Platform as a Service，平臺即服務，將平臺作為服務提供給使用者，譬如在平臺中可以隨用隨取各種中介軟體服務；

- SaaS：Software as a Service，軟體即服務，將應用作為服務提供給使用者，譬如郵件服務。

如下圖所示，從 IaaS 到 PaaS，使用者 （開發和運維） 越來越少地感知基礎資源，更加關注到業務當中。

![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/22456429/1647329247134-868ce8b2-8342-4016-a073-3f9c1baf5e0d.png#clientId=u74b0ab00-b534-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=ua573b1a6&margin=%5Bobject%20Object%5D&originHeight=680&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ue2fd6703-2158-49fe-a91a-c6a7e75a044&title=)

讓專業的人做專業的事情，從而發揮整體的最大效率。譬如一個初創的網際網路買菜公司，沒有必要自己去建機房、採購硬體、配置網路儲存以及安裝作業系統等與業務無關的事情，而是更應該把精力放到業務的開發和運營上面。

經過十幾年的發展，IaaS 已經比較成熟，各種基礎資源，如 ECS、VPC、EBS 等已經深入人心，但 PaaS 的發展卻非常緩慢。

早在 2008 年，Google 就推出了 App Engine 服務，想打造一個開發平臺，讓開發者只需要編寫業務程式碼就可以在 App Engine 上面執行。這個思想過於超前，開發者還不能完全接受。除了公有云以外，開源社群 PaaS 平臺也在左突右衝。其中，IBM 的 Cloud Foundry 和 Redhat 的 OpenShift 最為出名，他們都希望提供一個應用快速釋出的平臺，但也都是不溫不火，反而因為各種相容問題越來越難使用。

直到 2013 年 Docker 的誕生，一個對開發者充分友好、一個命令可以拉起一個服務，並極致簡單的操作方式，讓 Docker 一下成為社群最受歡迎的開源專案之一。

Docker 的優勢主要體現在：Docker 映象將應該依賴的環境和應用打包成一個壓縮檔案，這個檔案可以在任何安裝了 Docker 的機器上面直接執行，解決了應用從開發、測試到生產各個環節部署問題，並且能夠保障環境的一致性。

Docker 的成功在於極致的簡單操作而非技術的創新，像 cgroup、namespace 這些技術早就加入核心特性了。所以，Cloud Foundry 早先並沒有把 Docker 看做競爭對手，因為這些技術早就在 Cloud Foundry 上使用了。反而，Dcoker 映象這個無心插柳的功能，讓 Docker 真正實現了  “Build once, Run anywhere”。
# Kubernetes 確定江湖地位

最初的 Docker 是單機版本，面對大規模部署的場景時需要一套管理平臺，就像 OpenStack 管理 VM 一樣。

容器管理平臺初期也是百家爭鳴，譬如 Mesos、Swarm 等，但它們都沒有脫離 IaaS 固有思維，還是停留在把容器當做虛擬機器管理。直到 Kubernetes 的出現，才真正開始一統江湖。這裡除了 Google 的背書以及脫胎於 Borg 的成熟架構以外，更重要的是 Kubernetes 在誕生之初就已經想好了容器如何管理（Replica set）以及如何對外提供服務（Service）。

其中，最令人惋惜的就是 Docker 公司自家的管理系統 Swarm。當時的 Docker 雖然已經嶄露頭角，但 Docker 公司本身卻沒有實現盈利。於是公司推出了 Swarm 企業版，雖然 Swarm 後期也引入了很多 Kubernetes 的概念，但無奈大勢已去，雲原生的生態已經圍繞 Kubernetes 蓬勃發展。

Kubernetes 雖然由 Google 主導，但卻保持了足夠的開放性，將資源的管理抽象出介面規範，譬如針對容器執行時的 CRI、針對網路的 CNI、針對儲存的 CSI，以及裝置管理 Device Plugins 和各種准入控制、CRD 等。Kubernetes 正逐漸演變成雲作業系統，各種雲原生元件就是執行在這個作業系統之上的系統元件。
# 公有云託管 Kubernetes

雖然 Kubernetes 確定了領導地位，但 Kubernetes 的運維卻並非那麼容易。在這種背景下，公有云紛紛嘗試推出了雲上 Kubernetes 託管服務，比如阿里雲在 2017 年就推出了託管 Master 的方案：ACK。

在 ACK（Alibaba Cloud Container Service for Kubernetes）中，Kubernetes 管理元件的安裝和運維託管給公有云，使用 ECS 或者裸金屬作為 Kubernetes 的計算節點，這樣一來極大地減少了 Kubernetes 使用者的使用成本。使用者從雲平臺獲取一個 kubeconfig 檔案便可以直接通過 kubectl 命令列或者 Restful API 管理叢集。
![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/22456429/1647329247022-d76a6a56-3424-4363-a85b-09c275ba2425.png#clientId=u74b0ab00-b534-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=uf7050956&margin=%5Bobject%20Object%5D&originHeight=1156&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u1f0221d8-6abd-4176-b7a4-bf5f4f4cb27&title=)如果需要擴容叢集容量，只需要調整 ECS 個數，新建立的 ECS 會自動註冊到 Kubernetes Master。不僅如此，ACK 還支援一鍵升級叢集版本和各種外掛。ACK 將繁雜的運維工作轉移到雲上，並且藉助雲的彈效能力，能夠做到分鐘級別的資源擴充套件。
# 將免運維和彈性進行到底

公有云相對私有云更加關注成本，因為在私有云中，使用者的基礎設施成本基本是固定的，使用者不可能下線一個服務後去機房停一臺伺服器。與之相反，公有云則提供了按量付費的模式。

如果叢集裡面執行任務大部分都是 long run 並且資源需求是固定的任務，使用 ACK 沒有問題，但如果是大量 job 型別的任務或者存在突發流量的情況，ACK 這種臨時擴容虛擬機器在虛擬機器上啟用容器方案在彈性方面有所欠缺。

比如某線上教育公司，每天晚上 7-9 點上課高峰期會臨時擴容幾萬個 Pod，如果使用 ACK 就需要預先評估這些 Pod 的容量，然後再折算成 ECS 的算力，提前購買對應數量的計算節點加入到 Kubernetes 裡面，並且還需要在 9 點之後將這些 ECS 釋放掉，操作非常繁瑣。

那麼，有沒有一種既能相容 Kubernetes 使用方式，又能夠秒級啟動 Pod，並且按照 Pod 維度計費（ACK 按照 Node 維度計費）的方案呢？

AWS 率先提出 Fargate，可以在沒有真實 Node 的情況下，以 Pod 的維度加入到 Kubernetes 叢集。阿里雲在 2018 年也推出了類似的產品 ECI（Elastic Container Instance），每個 ECI 就是一個 Pod，這不過這個 Pod 是託管在雲上的。

Kubernetes 使用 ECI 有兩種方式 ：一種是 ASK（Alibaba Serverless Kubernetes），另一種是 ACK + Virtual Node 的方案。在 ASK 中，計算節點完全變成了 Virtaul Node。Virtaul Node 是一個虛擬的無限容量的計算節點，負責 ECI 生命週期管理。Virtaul Node 會註冊到 Kubernetes 裡面，對於 Kubernetes 來說，它就是一個普通的 Node 節點。使用者只需要提交原生的 Kubernetes Yaml 便可以建立出 Pod，完全相容 Kubernetes 的使用。
![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/22456429/1647329247514-93823356-a94b-4cc6-8d73-e4799257d6f0.png#clientId=u74b0ab00-b534-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u99f98614&margin=%5Bobject%20Object%5D&originHeight=1002&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=u25fdbd93-9b5a-416a-8891-fd4a45ab31f&title=)
Virtaul Node 還可以與普通 ACK 節點混用，使用者可以將 long run 的任務排程到 ECS 節點上執行，然後利用 ECI 的快速啟動（10s 內拉起容器），將突發或者短週期任務排程到 ECI 上面，從而達到成本最優。
![](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/22456429/1647329247620-bdc43777-a0a0-4c5d-bf31-bb3dfda03e37.png#clientId=u74b0ab00-b534-4&crop=0&crop=0&crop=1&crop=1&from=paste&id=u2d51252b&margin=%5Bobject%20Object%5D&originHeight=1191&originWidth=1080&originalType=url&ratio=1&rotation=0&showTitle=false&status=done&style=none&taskId=ucb95eabb-bc39-4df9-8356-d54b0bdcf27&title=)
目前 ECI 已經被很多網際網路以及人工智慧公司所採用。在後續的文章中，我們將逐步分享幾個典型使用者在遷移 ECI 過程中遇到的技術問題和挑戰。

總結一下，我們今天從技術發展的角度回顧了容器和 k8s 的發展歷程，可以看到公共技術正逐漸沉澱到底層，無論是 k8s 還是 ServiceMesh，都在分別嘗試將服務管理和流量管理下沉到基礎設施中。但這些元件本身也存在管理成本，所以演化出雲上託管。未來，隨著技術的下沉，雲端計算提供的能力將不斷上移、提供更加全面和豐富能力，讓開發專注在業務之上。

> 陳曉宇，阿里雲技術專家，負責阿里雲彈性容器（ECI）底層研發工作，曾出版《深入淺出 Prometheus》 和 《雲端計算那些事兒》。本文 from InfoQ，節選自陳曉宇的《深度揭祕阿里雲 Serverless Kubernetes》系列專題。

深度揭祕阿里雲 Serverless Kubernetes

相關文章