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

Serverless Kubernetes是阿里云容器服務(wù)團(tuán)隊(duì)對(duì)未來(lái)kubernetes演進(jìn)方向的一種探索，通過(guò)對(duì)kubernetes做減法，降低運(yùn)維管理負(fù)擔(dān)，簡(jiǎn)化集群管理，讓kubernetes從復(fù)雜到簡(jiǎn)單。

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

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

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

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

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

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

綜上可以看到，ACK集群至少需要2臺(tái)ecs機(jī)器以運(yùn)行這些基本的Addon，而ASK集群把這些基礎(chǔ)Addon化為無(wú)形，可以達(dá)到0成本創(chuàng)建一個(gè)開箱可用的kubernetes集群。

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

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

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

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

談起ASK，一定會(huì)談到ASK的資源底座ECI。ECI是阿里云基于ECS IaaS資源池提供的穩(wěn)定、高效、高彈性容器實(shí)例服務(wù)。ECI讓容器成為了公有云的第一等公民，用戶無(wú)需購(gòu)買和管理ecs就可以直接部署容器應(yīng)用，這種簡(jiǎn)化的容器實(shí)例產(chǎn)品形態(tài)和ASK形成了一個(gè)完美的組合。 用戶可以直接使用ECI Open API創(chuàng)建容器實(shí)例資源，但在容器場(chǎng)景中用戶普遍需要一個(gè)編排系統(tǒng)，來(lái)負(fù)責(zé)容器的調(diào)度、高可用編排等能力，而ASK正是這樣的kubernetes編排層。

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

ASK對(duì)kubernetes容器生態(tài)提供了完善的支持，目前已有大量客戶使用ASK來(lái)支撐如下各種場(chǎng)景。

原文鏈接

本文為阿里云內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。