作者 | 賢維? 阿里巴巴高級技術(shù)專家

導(dǎo)讀：Serverless Kubernetes 是阿里云容器服務(wù)團隊對未來 Kubernetes 演進方向的一種探索，通過對 Kubernetes 做減法，降低運維管理負擔，簡化集群管理，讓 Kubernetes 從復(fù)雜到簡單。

背景

Kubernetes 作為通用的容器編排系統(tǒng)，承載了廣泛的應(yīng)用和場景，包括 CI／CD，數(shù)據(jù)計算，在線應(yīng)用，AI 等，然而由于其通用性和復(fù)雜性，管理一個 Kubernetes 集群對于很多用戶而言還是充滿挑戰(zhàn)的，主要體現(xiàn)在：

• 學(xué)習(xí)成本高；
• 集群運維管理成本高，包括節(jié)點管理、容量規(guī)劃，以及各種節(jié)點異常問題的定位；
• 計算成本在很多場景中沒有達到最優(yōu)，比如對于一個定時運行 Jobs 的集群，長期持有資源池對于用戶來說是浪費的行為，資源利用率不高。

對 Kubernetes 集群做減法

無節(jié)點管理

我們相信未來用戶會更加關(guān)注應(yīng)用的開發(fā)，而不是基礎(chǔ)設(shè)施的維護。體現(xiàn)在 Kubernetes 集群中，我們希望用戶能夠關(guān)注在 pod/service/ingress/job 等應(yīng)用編排語義上，對底層 node 則可以減少關(guān)注。

無需管理節(jié)點也可以顯著降低集群的運維管理成本，經(jīng)統(tǒng)計 Kubernetes 常見的異常問題中大多數(shù)與節(jié)點相關(guān)，比如 Node NotReady 問題，也無需擔憂 Node 的安全問題，以及基礎(chǔ)系統(tǒng)軟件的升級和維護。

在 ASK 集群中，我們使用虛擬節(jié)點 virtual-kubelet 代替 ecs 節(jié)點，虛擬節(jié)點的容量可以認為是“無限大”，用戶不需要為集群的容量擔憂，無需預(yù)先做容量規(guī)劃。

無 Master 管理

和 ACK 托管版一樣，ASK 的 Master(apiserver, ccm, kcm 等)資源被容器服務(wù)平臺托管，用戶無需管理這些核心組件的升級和運維，也不用付出成本。

極簡的 K8s 基礎(chǔ)運行環(huán)境

除了無需管理節(jié)點和 Master 外，我們還對 Kubernetes 集群管理做了大量簡化，包括默認托管很多 addon，用戶無需再管理一些基礎(chǔ)的 addon，也不需要為這些 addon 付費。依賴阿里云原生的網(wǎng)絡(luò)和存儲等能力，以及獨特的托管架構(gòu)設(shè)計，我們提供了極度簡化但功能完備的 Kubernetes 基礎(chǔ)運行環(huán)境。

功能ACKASK

存儲	需要部署 aliyun-disk-controller/flexvolume	無需部署（正在支持中）
CNI 網(wǎng)絡(luò)	需要部署 terway/flannel daemonset	無需部署，基于 vpc 網(wǎng)絡(luò)通信
coredns 服務(wù)發(fā)現(xiàn)	需要部署 2 個 coredns 副本	無需部署，基于 privatezone 訪問
kube-proxy	需要部署 kube-proxy daemonset	無需部署，基于 privatezone 訪問
Ingress	需要部署 nginx-ingress-controller	無需部署，基于 SLB 七層轉(zhuǎn)發(fā)
免密拉取 ACR 鏡像	需要部署 acr-credential-helper	無需部署，默認支持
sls 日志收集	需要部署 logtail daemonset	無需部署，默認支持
metrics 統(tǒng)計	需要部署 metrics-server	無需部署，開箱即用
掛載 eip	需要部署 terway	無需部署，使用 annotaion 指定
云盤隨 pod 創(chuàng)建掛載	依賴 aliyun-disk-controller	無需部署，默認支持
彈性伸縮	需要部署 cluster-autoscaler	無需部署
GPU 插件	需要部署 Nivida-docker	無需部署，開箱即用

綜上可以看到，ACK 集群至少需要 2 臺 ecs 機器以運行這些基本的 Addon，而 ASK 集群把這些基礎(chǔ) Addon 化為無形，可以達到 0 成本創(chuàng)建一個開箱可用的 Kubernetes 集群。

簡化彈性伸縮

因為無需管理節(jié)點和容量規(guī)劃，因此當集群需要擴容時也就不需要考慮節(jié)點層面的擴容，只需要關(guān)注 pod 的擴容，
這對于擴容的速度和效率都是極大的提升，目前一些客戶指定使用 ASK/ECI 的方式來快速應(yīng)對業(yè)務(wù)流量高峰。

當前 ASK/ECI 支持 30s 完全啟動 500 個 pod（至 Running 狀態(tài)），單個 pod 啟動可以達到 10s 以內(nèi)。

更低成本

除去 ASK 集群本身的低成本創(chuàng)建外，pod 的按需使用也讓很多場景下資源利用率達到最優(yōu)。對于很多 Jobs 或者數(shù)據(jù)計算場景而言，用戶并不需要長期維護一個固定的資源池，這時 ASK/ECI 可以很好的支持這些訴求。

經(jīng)驗證，當 pod 一天中運行時間少于 16 個小時，則 ASK/ECI 的方式相比保有 ecs 資源池更節(jié)省經(jīng)濟成本。

ECI：快速交付容器資源的彈性計算服務(wù)

談起 ASK，一定會談到 ASK 的資源底座 ECI。ECI 是阿里云基于 ECS IaaS 資源池提供的穩(wěn)定、高效、高彈性容器實例服務(wù)。ECI 讓容器成為了公有云的第一等公民，用戶無需購買和管理 ecs 就可以直接部署容器應(yīng)用，這種簡化的容器實例產(chǎn)品形態(tài)和 ASK 形成了一個完美的組合。

用戶可以直接使用 ECI Open API 創(chuàng)建容器實例資源，但在容器場景中用戶普遍需要一個編排系統(tǒng)，來負責容器的調(diào)度、高可用編排等能力，而 ASK 正是這樣的 Kubernetes 編排層。

對于 ASK 而言，ECI 讓 ASK 容器服務(wù)免去了搭建后臺計算資源池的必要，更不用為底層計算資源池的容量而擔憂。基于 ECI 就意味著基于整個阿里云 IaaS 規(guī)模化資源池，天然擁有了庫存和彈性優(yōu)勢（比如可以通過 Annotation 的方式指定底層 eci 對應(yīng)的 ecs 規(guī)格，大部分 ecs 規(guī)格都可以在 ASK 中使用，滿足多種計算場景的需求）。另外 ECI 和 ECS 復(fù)用資源池意味著我們可以最大化釋放規(guī)模化紅利，給用戶提供更低成本的計算服務(wù)。

容器生態(tài)支持

ASK 對 Kubernetes 容器生態(tài)提供了完善的支持，目前已有大量客戶使用 ASK 來支撐如下各種場景：

• CI/CD：gitlab-runner，jenkins/jenkins-x
• 數(shù)據(jù)計算：spark/spark-operator，flink，presto，argo
• AI：tensorflow/arena
• ServiceMesh： istio，knative
• 測試：locust，selenium

ASK 集群不支持 Helm v2，近期 ACK/ASK 會發(fā)布 Helm v3 的支持，之后用戶可以非常方便的在 ASK 集群中部署 Charts。

更多 ASK 參考文檔

• 快速部署 jenkins 環(huán)境及執(zhí)行流水線構(gòu)建
• 創(chuàng)建 Service
• 基于 privatezone 服務(wù)發(fā)現(xiàn)
• 創(chuàng)建 Ingress
• 使用 nginx ingress
• sls 日志收集
• 使用 kaniko 自動化構(gòu)建鏡像
• 使用虛擬節(jié)點
• 使用 GPU 容器實例
• pod 掛載 eip
• 使用鏡像快照加速啟動
• 收集 pod 日志到 sls
• 運行 Argo workflow
• 使用 vk-autoscaler
• ASK Examples

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢、云原生大規(guī)模的落地實踐，做最懂云原生開發(fā)者的技術(shù)圈。”

總結(jié)

以上是生活随笔為你收集整理的Serverless Kubernetes 入门：对 Kubernetes 做减法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。