伴随着雲原生的發展，從早先的單機版 Docker 到 Kubernetes 的編排領域的一統江湖，再到雲上托管 Kubernetes，技術風雨變化。今天我們就沿着曆史的脈絡，一起看一下 Serverless Kubernetes 的發展史。
故事，從 Docker 講起
故事雖然從 Docker 講起，但我們不能忽視了 IaaS 先輩們在前面的披荊斬棘，以及雲計算大佬們很早就确定的雲計算發展規劃。
在十幾年前，先輩們從按照使用者使用（雲平台提供能力）次元，将雲分為三層：
- IaaS：Infrastructure as a Service，基礎設施即服務，提供虛拟機或者其他基礎資源作為服務提供給使用者；
- PaaS：Platform as a Service，平台即服務，将平台作為服務提供給使用者，譬如在平台中可以随用随取各種中間件服務；
- SaaS：Software as a Service，軟體即服務，将應用作為服務提供給使用者，譬如郵件服務。
如下圖所示，從 IaaS 到 PaaS，使用者（開發和運維）越來越少地感覺基礎資源，更加關注到業務當中。
讓專業的人做專業的事情，進而發揮整體的最大效率。譬如一個初創的網際網路買菜公司，沒有必要自己去建機房、采購硬體、配置網絡存儲以及安裝作業系統等與業務無關的事情，更應該把精力放到業務的開發和營運上面。
經過十幾年的發展，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（Alibaba Cloud Container Service for Kubernetes）。
在 ACK 中，Kubernetes 管理元件的安裝和運維托管給公有雲，使用 ECS 或者裸金屬作為 Kubernetes 的計算節點，極大地減少了 Kubernetes 使用者的使用成本。使用者從雲平台擷取一個 kubeconfig 檔案便可以直接通過 kubectl 指令行或者 Restful API 管理叢集。
如果需要擴容叢集容量，隻需要調整 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 的使用。
Virtaul Node 還可以與普通 ACK 節點混用，使用者可以将 long run 的任務排程到 ECS 節點上運作，然後利用 ECI 的快速啟動（10s 内拉起容器），将突發或者短周期任務排程到 ECI 上面，進而達到成本最優。
目前 ECI 已經被很多網際網路以及人工智能公司所采用。在後續的文章中，我們将逐漸分享幾個典型使用者在遷移 ECI 過程中遇到的技術問題和挑戰。
總結一下，我們今天從技術發展的角度回顧了容器和 k8s 的發展曆程，可以看到公共技術正逐漸沉澱到底層，無論是 k8s 還是 ServiceMesh，都在分别嘗試将服務管理和流量管理下沉到基礎設施中。但這些元件本身也存在管理成本，是以演化出雲上托管。未來，随着技術的下沉，雲計算提供的能力将不斷上移、提供更加全面和豐富能力，讓開發專注在業務之上。
本文節選自阿裡雲技術專家陳曉宇的《深度揭秘阿裡雲 Serverless Kubernetes》系列專題。本專欄将主要圍繞如何在 Serverless Kubernetes 場景中實作秒級擴容，以及在大規模并發啟動中遇到的各種技術挑戰、難點以及解決方案，系統地揭秘阿裡雲 Serverless Kubernetes 的發展、架構以及核心技術。
作者簡介：
陳曉宇，阿裡雲技術專家，負責阿裡雲彈性容器（ECI）底層研發工作，曾出版《深入淺出 Prometheus》 和 《雲計算那些事兒》。