Serverless Kubernetes 入門：對 Kubernetes 做減法

本文轉載自查看原文 2020-01-08 10:25 273 kubernetes/ serverless

作者 | 賢維阿里巴巴高級技術專家

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

背景

Kubernetes 作為通用的容器編排系統，承載了廣泛的應用和場景，包括 CI／CD，數據計算，在線應用，AI 等，然而由於其通用性和復雜性，管理一個 Kubernetes 集群對於很多用戶而言還是充滿挑戰的，主要體現在：

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

對 Kubernetes 集群做減法

無節點管理

我們相信未來用戶會更加關注應用的開發，而不是基礎設施的維護。體現在 Kubernetes 集群中，我們希望用戶能夠關注在 pod/service/ingress/job 等應用編排語義上，對底層 node 則可以減少關注。

無需管理節點也可以顯著降低集群的運維管理成本，經統計 Kubernetes 常見的異常問題中大多數與節點相關，比如 Node NotReady 問題，也無需擔憂 Node 的安全問題，以及基礎系統軟件的升級和維護。

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

無 Master 管理

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

極簡的 K8s 基礎運行環境

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

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

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

簡化彈性伸縮

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

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

更低成本

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

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

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

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

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

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

容器生態支持

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

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

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