深度揭秘阿里云Serverless Kubernetes

伴隨著云原生的發(fā)展，從早先的單機(jī)版 Docker 到 Kubernetes 的編排領(lǐng)域的一統(tǒng)江湖，再到云上托管 Kubernetes，技術(shù)風(fēng)雨變化。今天我們就沿著歷史的脈絡(luò)，一起看一下 Serverless Kubernetes 的發(fā)展史。

故事，從 Docker 講起

故事雖然從 Docker 講起，但我們不能忽視了 IaaS 先輩們?cè)谇懊娴呐G斬棘，以及云計(jì)算大佬們很早就確定的云計(jì)算發(fā)展規(guī)劃。

在十幾年前，先輩們從按照用戶(hù)使用（云平臺(tái)提供能力）維度，將云分為三層：

IaaS：Infrastructure as a Service，基礎(chǔ)設(shè)施即服務(wù)，提供虛擬機(jī)或者其他基礎(chǔ)資源作為服務(wù)提供給用戶(hù)；

PaaS：Platform as a Service，平臺(tái)即服務(wù)，將平臺(tái)作為服務(wù)提供給用戶(hù)，譬如在平臺(tái)中可以隨用隨取各種中間件服務(wù)；

SaaS：Software as a Service，軟件即服務(wù)，將應(yīng)用作為服務(wù)提供給用戶(hù)，譬如郵件服務(wù)。

如下圖所示，從 IaaS 到 PaaS，用戶(hù)（開(kāi)發(fā)和運(yùn)維）越來(lái)越少地感知基礎(chǔ)資源，更加關(guān)注到業(yè)務(wù)當(dāng)中。

讓專(zhuān)業(yè)的人做專(zhuān)業(yè)的事情，從而發(fā)揮整體的最大效率。譬如一個(gè)初創(chuàng)的互聯(lián)網(wǎng)買(mǎi)菜公司，沒(méi)有必要自己去建機(jī)房、采購(gòu)硬件、配置網(wǎng)絡(luò)存儲(chǔ)以及安裝操作系統(tǒng)等與業(yè)務(wù)無(wú)關(guān)的事情，更應(yīng)該把精力放到業(yè)務(wù)的開(kāi)發(fā)和運(yùn)營(yíng)上面。

經(jīng)過(guò)十幾年的發(fā)展，IaaS 已經(jīng)比較成熟，各種基礎(chǔ)資源，如 ECS、VPC、EBS 等已經(jīng)深入人心，但 PaaS 的發(fā)展卻非常緩慢。

早在 2008 年，Google 就推出了 App Engine 服務(wù)，想打造一個(gè)開(kāi)發(fā)平臺(tái)，讓開(kāi)發(fā)者只需要編寫(xiě)業(yè)務(wù)代碼就可以在 App Engine 上面運(yùn)行。這個(gè)思想過(guò)于超前，開(kāi)發(fā)者還不能完全接受。除了公有云以外，開(kāi)源社區(qū) PaaS 平臺(tái)也在左突右沖。其中，IBM 的 Cloud Foundry 和 Redhat 的 OpenShift 最為出名，他們都希望提供一個(gè)應(yīng)用快速發(fā)布的平臺(tái)，但也都是不溫不火，反而因?yàn)楦鞣N兼容問(wèn)題越來(lái)越難使用。

直到 2013 年 Docker 的誕生，一個(gè)對(duì)開(kāi)發(fā)者充分友好、一個(gè)命令可以拉起一個(gè)服務(wù)，并極致簡(jiǎn)單的操作方式，讓 Docker 一下成為社區(qū)最受歡迎的開(kāi)源項(xiàng)目之一。

Docker 的優(yōu)勢(shì)主要體現(xiàn)在：Docker 鏡像將應(yīng)該依賴(lài)的環(huán)境和應(yīng)用打包成一個(gè)壓縮文件，這個(gè)文件可以在任何安裝了 Docker 的機(jī)器上面直接運(yùn)行，解決了應(yīng)用從開(kāi)發(fā)、測(cè)試到生產(chǎn)各個(gè)環(huán)節(jié)部署問(wèn)題，并且能夠保障環(huán)境的一致性。

Docker 的成功在于極致的簡(jiǎn)單操作而非技術(shù)的創(chuàng)新，像 cgroup、namespace 這些技術(shù)早就加入內(nèi)核特性了。所以，Cloud Foundry 早先并沒(méi)有把 Docker 看做競(jìng)爭(zhēng)對(duì)手，因?yàn)檫@些技術(shù)早就在 Cloud Foundry 上使用了。反而，Dcoker 鏡像這個(gè)無(wú)心插柳的功能，讓 Docker 真正實(shí)現(xiàn)了“Build once, Run anywhere”。

Kubernetes 確定江湖地位

最初的 Docker 是單機(jī)版本，面對(duì)大規(guī)模部署的場(chǎng)景時(shí)需要一套管理平臺(tái)，就像 OpenStack 管理 VM 一樣。

容器管理平臺(tái)初期也是百家爭(zhēng)鳴，譬如 Mesos、Swarm 等，但它們都沒(méi)有脫離 IaaS 固有思維，還是停留在把容器當(dāng)做虛擬機(jī)管理。直到 Kubernetes 的出現(xiàn)，才真正開(kāi)始一統(tǒng)江湖。這里除了 Google 的背書(shū)以及脫胎于 Borg 的成熟架構(gòu)以外，更重要的是 Kubernetes 在誕生之初就已經(jīng)想好了容器如何管理（ Replica set）以及如何對(duì)外提供服務(wù)（Service）。

其中，最令人惋惜的就是 Docker 公司自家的管理系統(tǒng) Swarm。當(dāng)時(shí)的 Docker 雖然已經(jīng)斬落頭角，但 Docker 公司本身卻沒(méi)有實(shí)現(xiàn)盈利。于是公司推出了 Swarm 企業(yè)版，雖然 Swarm 后期也引入了很多 Kubernetes 的概念，但無(wú)奈大勢(shì)已去，云原生的生態(tài)已經(jīng)圍繞 Kubernetes 蓬勃發(fā)展。

Kubernetes 雖然由 Google 主導(dǎo)，但卻保持了足夠的開(kāi)放性，將資源的管理抽象出接口規(guī)范，譬如針對(duì)容器運(yùn)行時(shí)的 CRI、針對(duì)網(wǎng)絡(luò)的 CNI、針對(duì)存儲(chǔ)的 CSI，以及設(shè)備管理 Device Plugins 和各種準(zhǔn)入控制、CRD 等。Kubernetes 正逐漸演變成云操作系統(tǒng)，各種云原生組件就是運(yùn)行在這個(gè)操作系統(tǒng)之上的系統(tǒng)組件。

公有云托管 Kubernetes

雖然 Kubernetes 確定了領(lǐng)導(dǎo)地位，但 Kubernetes 的運(yùn)維卻并非那么容易。在這種背景下，公有云嘗試紛紛推出了云上 Kubernetes 托管服務(wù)，比如國(guó)內(nèi)的阿里云在 2017 年就推出了托管 Master 的方案：ACK（Alibaba Cloud Container Service for Kubernetes）。

在 ACK 中，Kubernetes 管理組件的安裝和運(yùn)維托管給公有云，使用 ECS 或者裸金屬作為 Kubernetes 的計(jì)算節(jié)點(diǎn)，極大地減少了 Kubernetes 用戶(hù)的使用成本。用戶(hù)從云平臺(tái)獲取一個(gè) kubeconfig 文件便可以直接通過(guò) kubectl 命令行或者 Restful API 管理集群。

如果需要擴(kuò)容集群容量，只需要調(diào)整 ECS 個(gè)數(shù)，新創(chuàng)建的 ECS 會(huì)自動(dòng)注冊(cè)到 Kubernetes Master。不僅如此，ACK 還支持一鍵升級(jí)集群版本和各種插件。ACK 將繁雜的運(yùn)維工作轉(zhuǎn)移到云上，并且借助云的彈性能力，可以做到分鐘級(jí)別的資源擴(kuò)展。

將免運(yùn)維和彈性進(jìn)行到底

公有云相對(duì)私有云更加關(guān)注成本，因?yàn)樵谒接性浦?，用?hù)的基礎(chǔ)設(shè)施成本基本是固定的，用戶(hù)不可能下線一個(gè)服務(wù)后去機(jī)房停一臺(tái)服務(wù)器。與之相反，公有云則提供了按量付費(fèi)的模式。

如果集群里面運(yùn)行任務(wù)大部分都是 long run 并且資源需求是固定的任務(wù)，使用 ACK 沒(méi)有問(wèn)題，但如果是大量 job 類(lèi)型的任務(wù)或者存在突發(fā)流量的情況，ACK 這種臨時(shí)擴(kuò)容虛擬機(jī)在虛擬機(jī)上啟用容器方案在彈性方面有所欠缺。

比如某在線教育公司，每天晚上 7-9 點(diǎn)上課高峰期會(huì)臨時(shí)擴(kuò)容幾萬(wàn)個(gè) Pod，如果使用 ACK 就需要預(yù)先評(píng)估這些 Pod 的容量，然后再折算成 ECS 的算力，提前購(gòu)買(mǎi)對(duì)應(yīng)數(shù)量的計(jì)算節(jié)點(diǎn)加入到 Kubernetes 里面，并且還需要在 9 點(diǎn)之后將這些 ECS 釋放掉，操作非常繁瑣。

那么，有沒(méi)有一種既能兼容 Kubernetes 使用方式，又能夠秒級(jí)啟動(dòng) Pod，并且按照 Pod 維度計(jì)費(fèi)（ACK 按照 Node 維度計(jì)費(fèi)）的方案呢？

AWS 率先提出 Fargate，可以在沒(méi)有真實(shí) Node 的情況下，以 Pod 的維度加入到 Kubernetes 集群。阿里云在 2018 年也推出了類(lèi)似的產(chǎn)品 ECI（Elastic Container Instance），每個(gè) ECI 就是一個(gè) Pod，這不過(guò)這個(gè) Pod 是托管在云上的。

Kubernetes 使用 ECI 有兩種方式 ：一種是 ASK（Alibaba Serverless Kubernetes），另一種是 ACK + Virtual Node 的方案。在 ASK 中，計(jì)算節(jié)點(diǎn)完全變成了 Virtaul Node。Virtaul Node 是一個(gè)虛擬的無(wú)限容量的計(jì)算節(jié)點(diǎn)，負(fù)責(zé) ECI 生命周期管理。Virtaul Node 會(huì)注冊(cè)到 Kubernetes 里面，對(duì)于 Kubernetes 來(lái)說(shuō)，它就是一個(gè)普通的 Node 節(jié)點(diǎn)。用戶(hù)只需要提交原生的 Kubernetes Yaml 便可以創(chuàng)建出 Pod，完全兼容 Kubernetes 的使用。

Virtaul Node 還可以與普通 ACK 節(jié)點(diǎn)混用，用戶(hù)可以將 long run 的任務(wù)調(diào)度到 ECS 節(jié)點(diǎn)上運(yùn)行，然后利用 ECI 的快速啟動(dòng)（10s 內(nèi)拉起容器），將突發(fā)或者短周期任務(wù)調(diào)度到 ECI 上面，從而達(dá)到成本最優(yōu)。

目前 ECI 已經(jīng)被很多互聯(lián)網(wǎng)以及人工智能公司所采用。在后續(xù)的文章中，我們將逐步分享幾個(gè)典型用戶(hù)在遷移 ECI 過(guò)程中遇到的技術(shù)問(wèn)題和挑戰(zhàn)。

總結(jié)一下，我們今天從技術(shù)發(fā)展的角度回顧了容器和 k8s 的發(fā)展歷程，可以看到公共技術(shù)正逐漸沉淀到底層，無(wú)論是 k8s 還是 ServiceMesh，都在分別嘗試將服務(wù)管理和流量管理下沉到基礎(chǔ)設(shè)施中。但這些組件本身也存在管理成本，所以演化出云上托管。未來(lái)，隨著技術(shù)的下沉，云計(jì)算提供的能力將不斷上移、提供更加全面和豐富能力，讓開(kāi)發(fā)專(zhuān)注在業(yè)務(wù)之上。

本文節(jié)選自阿里云技術(shù)專(zhuān)家陳曉宇的《深度揭秘阿里云 Serverless Kubernetes》系列專(zhuān)題。本專(zhuān)欄將主要圍繞如何在 Serverless Kubernetes 場(chǎng)景中實(shí)現(xiàn)秒級(jí)擴(kuò)容，以及在大規(guī)模并發(fā)啟動(dòng)中遇到的各種技術(shù)挑戰(zhàn)、難點(diǎn)以及解決方案，系統(tǒng)地揭秘阿里云 Serverless Kubernetes 的發(fā)展、架構(gòu)以及核心技術(shù)。

審核編輯 ：李倩