以 Kubernetes 為代表的容器技術(shù),已成為云計(jì)算的新界面

志敏、智清
作為容器編排的事實(shí)標(biāo)準(zhǔn),Kubernetes 支持 IaaS 層不同類型的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等能力,不論是 CPU、GPU、FPGA 還是專業(yè)的 ASIC 芯片,都可以統(tǒng)一調(diào)度、高效使用異構(gòu)算力的資源,同時(shí)完美支撐各種開源框架、語言和各類型應(yīng)用。

2020 年 雙11,阿里核心系統(tǒng)實(shí)現(xiàn)了全面云原生化,扛住了史上最大流量洪峰,向業(yè)界傳達(dá)出了“云原生正在大規(guī)模落地”的信號(hào)。這里包含著諸多阿里 "云原生的第一次”,其中非常關(guān)鍵的一點(diǎn)是 80% 核心業(yè)務(wù)部署在阿里云容器 ACK 上,可在 1 小時(shí)內(nèi)擴(kuò)展超百萬容器。

可以說,以 Kubernetes 為代表的容器技術(shù)正成為云計(jì)算新界面。容器提供了應(yīng)用分發(fā)和交付標(biāo)準(zhǔn),將應(yīng)用與底層運(yùn)行環(huán)境進(jìn)行解耦。Kubernetes 作為資源調(diào)度和編排的標(biāo)準(zhǔn),屏蔽底層架構(gòu)差異性,幫助應(yīng)用平滑運(yùn)行在不同基礎(chǔ)設(shè)施上。CNCF Kubernetes 的一致性認(rèn)證,進(jìn)一步確保不同云廠商 Kubernetes 實(shí)現(xiàn)的兼容性,這也讓更多的企業(yè)愿意采用容器技術(shù)來構(gòu)建云時(shí)代的應(yīng)用基礎(chǔ)設(shè)施。

1.webp.jpg

作為容器編排的事實(shí)標(biāo)準(zhǔn),Kubernetes 支持 IaaS 層不同類型的計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等能力,不論是 CPU、GPU、FPGA 還是專業(yè)的 ASIC 芯片,都可以統(tǒng)一調(diào)度、高效使用異構(gòu)算力的資源,同時(shí)完美支撐各種開源框架、語言和各類型應(yīng)用。

伴隨著 Kubernetes 成為新操作系統(tǒng)的事實(shí),以云原生容器為主的技術(shù),已經(jīng)成為云計(jì)算的新界面。

1. 云原生容器界面特征

云原生容器界面具有以下三個(gè)典型特征:

向下封裝基礎(chǔ)設(shè)施,屏蔽底層架構(gòu)的差異性。

拓展云計(jì)算新邊界,云邊端一體化管理。

向上支撐多種工作負(fù)載和分布式架構(gòu)。

1)向下封裝基礎(chǔ)設(shè)施,屏蔽底層差異性

統(tǒng)一技能棧降低人力成本:Kubernetes 可以在 IDC、云端、邊緣等不同場(chǎng)景進(jìn)行統(tǒng)一部署和交付,通過云原生提倡的 DevOps 文化和工具集的使用有效提升技術(shù)迭代速度,因此整體上可以降低人力成本。

統(tǒng)一技術(shù)棧提升資源利用率:多種計(jì)算負(fù)載在 Kubernetes 集群統(tǒng)一調(diào)度,可以有效提升資源利用率。Gartner 預(yù)測(cè)“未來 3 年,70% 的 AI 任務(wù)運(yùn)行在容器和 Serverless 上” ,而 AI 模型訓(xùn)練和大數(shù)據(jù)計(jì)算類工作負(fù)載更加需要 Kubernetes 提供更低的調(diào)度延遲、更大的并發(fā)調(diào)度吞吐和更高的異構(gòu)資源利用率。

加速數(shù)據(jù)服務(wù)的云原生化:由于計(jì)算存儲(chǔ)分離具備巨大的靈活性和成本優(yōu)勢(shì),數(shù)據(jù)服務(wù)的云原生化也逐漸成為趨勢(shì)。容器和 Serverless 的彈性可以簡(jiǎn)化對(duì)計(jì)算任務(wù)的容量規(guī)劃。結(jié)合分布式緩存加速(比如 Alluxio 或阿里云 Jindofs)和調(diào)度優(yōu)化,也可以大大提升數(shù)據(jù)計(jì)算類和 AI 任務(wù)的計(jì)算效率。

安全能力進(jìn)一步加強(qiáng):隨著數(shù)字經(jīng)濟(jì)的發(fā)展,企業(yè)的數(shù)據(jù)資產(chǎn)成為新“石油”,大量數(shù)據(jù)需要在云端進(jìn)行交換、處理。如何保障數(shù)據(jù)的安全、隱私、可信成為了企業(yè)上云的最大挑戰(zhàn)。我們需要用技術(shù)手段,建立數(shù)字化信任基礎(chǔ),保護(hù)數(shù)據(jù),幫助企業(yè)創(chuàng)建可信任的商業(yè)合作關(guān)系,促進(jìn)業(yè)務(wù)增長(zhǎng)。比如基于 Intel SGX 等加密計(jì)算技術(shù),阿里云為云上客戶提供了可信的執(zhí)行環(huán)境。不過,可信應(yīng)用開發(fā)和使用門檻都很高,需要用戶對(duì)現(xiàn)有應(yīng)用進(jìn)行重構(gòu),處理大量的底層技術(shù)細(xì)節(jié),讓這項(xiàng)技術(shù)落地非常困難。

2)拓展云計(jì)算新邊界,云邊端一體化管理

隨著邊緣計(jì)算的場(chǎng)景和需求不斷增加,“云邊協(xié)同”、“邊緣云原生”正在逐漸成為新的技術(shù)焦點(diǎn)。Kubernetes 具有強(qiáng)大的容器編排、資源調(diào)度能力,可以滿足邊緣/IoT 場(chǎng)景中,對(duì)低功耗、異構(gòu)資源適配、云邊網(wǎng)絡(luò)協(xié)同等方面的獨(dú)特需求。為了推動(dòng)云原生和邊緣計(jì)算交叉領(lǐng)域的協(xié)同發(fā)展,阿里巴巴于 2020 年 5 月正式對(duì)外開源邊緣計(jì)算云原生項(xiàng)目 OpenYurt,推動(dòng)“云邊一體化”概念落地,通過對(duì)原生 Kubernetes 進(jìn)行擴(kuò)展的方式完成對(duì)邊緣計(jì)算場(chǎng)景需求的支持,其主要特性有:

“零”侵入的邊緣云原生方案:提供完整的 Kubernetes 兼容性,支持所有原生工作負(fù)載和擴(kuò)展技術(shù)(Operator/CNI/CSI 等);可以輕松實(shí)現(xiàn)原生 Kubernetes 集群一鍵轉(zhuǎn)化為 OpenYurt 集群。

節(jié)點(diǎn)自治:具備云邊弱網(wǎng)或斷網(wǎng)環(huán)境下的邊緣節(jié)點(diǎn)自治、自愈能力,保障業(yè)務(wù)連續(xù)性。

針對(duì)海量邊緣節(jié)點(diǎn)的應(yīng)用交付,可提供高效、安全、可控的應(yīng)用發(fā)布和管理方式。

2019 年 KubeCon 上阿里云發(fā)布邊緣容器服務(wù) ACK@Edge,OpenYurt 正是其核心框架。短短一年,ACK@Edge 已經(jīng)應(yīng)用于音視頻直播、云游戲、工業(yè)互聯(lián)網(wǎng)、交通物流、城市大腦等場(chǎng)景中,并服務(wù)于盒馬、優(yōu)酷、阿里視頻云和眾多互聯(lián)網(wǎng)、新零售企業(yè)。同時(shí),作為 ACK@Edge 的開源版本 OpenYurt,已經(jīng)成為 CNCF 的沙箱項(xiàng)目,推動(dòng) Kubernetes 上游社區(qū)兼顧邊緣計(jì)算的需求,歡迎各位開發(fā)者一起共建,迎接萬物智聯(lián)的新時(shí)代。

3)向上支撐多種工作負(fù)載和分布式架構(gòu)

企業(yè)在 IT 轉(zhuǎn)型的大潮中對(duì)數(shù)字化和智能化的訴求越來越強(qiáng)烈,最突出的需求是如何能快速、精準(zhǔn)地從海量業(yè)務(wù)數(shù)據(jù)中挖掘出新的商業(yè)機(jī)會(huì)和模式創(chuàng)新,才能更好應(yīng)對(duì)多變、不確定性的業(yè)務(wù)挑戰(zhàn)。

Kubernetes 可以向上支持眾多開源主流框架構(gòu)建微服務(wù)、數(shù)據(jù)庫(kù)、消息中間件、大數(shù)據(jù)、AI、區(qū)塊鏈等各種類型應(yīng)用。從無狀態(tài)應(yīng)用、到企業(yè)核心應(yīng)用、再到數(shù)字智能應(yīng)用,企業(yè)和開發(fā)者都可以基于 Kubernetes 順利地自動(dòng)部署、擴(kuò)展和管理容器化應(yīng)用。

2. 阿里巴巴如何理解云原生容器界面

阿里巴巴將云原生看作未來重要的技術(shù)趨勢(shì),為了更快加速、更好協(xié)同,制定了清晰的經(jīng)濟(jì)體云原生技術(shù)路線,舉集團(tuán)之力統(tǒng)籌推動(dòng)云原生。

在云原生容器界面的指引下,阿里巴巴集團(tuán)以基礎(chǔ)設(shè)施、運(yùn)維及其周邊系統(tǒng)作為切入點(diǎn),掀起全面云原生化的浪潮,陸續(xù)將系統(tǒng)改造為適配云原生架構(gòu)的新方案,推動(dòng)集團(tuán)內(nèi)部使用的技術(shù)框架、工具等被云可接受的標(biāo)準(zhǔn)產(chǎn)品或云產(chǎn)品替代;進(jìn)一步轉(zhuǎn)變運(yùn)維思路和工作方式,兼容適配新的運(yùn)維模式。例如:DevOps 需要改變傳統(tǒng)虛擬機(jī)時(shí)代的運(yùn)維思想,容器運(yùn)行時(shí)的組件要改為支持 Kubernetes Pod 下的新模式,容器內(nèi)日志、監(jiān)控等各類運(yùn)維組件都需要變化、運(yùn)維模式也隨之變化。

在計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)方面,用戶通過 Kubernetes 的統(tǒng)一管理,可以充分利用阿里云的 IaaS 能力,讓每個(gè)業(yè)務(wù)擁有自己獨(dú)立的彈性網(wǎng)卡和云盤,對(duì)網(wǎng)絡(luò)和存儲(chǔ)性能有著高低不同需求的業(yè)務(wù),也有能力部署在同一臺(tái)宿主機(jī)上,并保證互相不被干擾的隔離性。傳統(tǒng)非云物理機(jī)機(jī)型決定業(yè)務(wù)部署類型,會(huì)導(dǎo)致的彈性不足問題,也得到了很好的解決。因此,用戶在提升資源利用率、降低成本的同時(shí),也極大提升了業(yè)務(wù)的穩(wěn)定性。

在節(jié)點(diǎn)資源層,用戶可充分利用 Kubernetes 的底座擴(kuò)展能力,讓節(jié)點(diǎn)管理實(shí)現(xiàn)云原生化;在架構(gòu)層面,通過節(jié)點(diǎn)生命周期控制器、自愈控制器和組件升級(jí)控制器等,可實(shí)現(xiàn)節(jié)點(diǎn)自愈、流轉(zhuǎn)、交付、環(huán)境組件變更的節(jié)點(diǎn)生命周期的完全閉環(huán),讓容器層完全屏蔽底層節(jié)點(diǎn)感知,完全改變了節(jié)點(diǎn)的運(yùn)維管理模式。基于強(qiáng)大的云原生節(jié)點(diǎn)管理模式,阿里巴巴內(nèi)部將集團(tuán)之前相對(duì)割裂的節(jié)點(diǎn)資源整合為一體,真正實(shí)現(xiàn)了資源池從點(diǎn)形成面,將內(nèi)核、環(huán)境組件、機(jī)型規(guī)格等進(jìn)行統(tǒng)一標(biāo)準(zhǔn)整合,資源池的大一統(tǒng)并結(jié)合統(tǒng)一調(diào)度形成巨大的彈性能力,這也是云原生節(jié)點(diǎn)管理中的『書同文,車同軌,度同制,行同倫,地同域』,讓節(jié)點(diǎn)資源從諸侯格局變成了大一統(tǒng)的云原生資源池。

新興的生態(tài)和業(yè)務(wù),基于 ACK(阿里云容器服務(wù))提供的云原生土壤,如 Service Mesh、Serverless、Faas 等,也非常快速地在集團(tuán)內(nèi)落地,并得到蓬勃發(fā)展。

在應(yīng)用 PaaS 層,云原生的應(yīng)用交付模式走向了更為徹底的容器化,充分利用了 Kubernetes 的自動(dòng)化調(diào)度能力,基于 OAM Trait 的標(biāo)準(zhǔn)定義來構(gòu)建集團(tuán)內(nèi)統(tǒng)一的 PaaS 運(yùn)維能力,基于 GitOps 研發(fā)模式讓基礎(chǔ)設(shè)施和云資源代碼化、可編程。

阿里集團(tuán)向云原生容器界面的演進(jìn)

為了支撐阿里集團(tuán)龐大而復(fù)雜的業(yè)務(wù),十年之間,眾多技術(shù)工程師走出了一條深深淺淺的容器之旅。

那么,在阿里集團(tuán)內(nèi)部,容器界面是如何演進(jìn)的呢?

在過去十年,阿里集團(tuán)內(nèi)的容器技術(shù),經(jīng)歷了從自研 LXC(Linux Container)容器 T4,到富容器,再到 Kubernetes 云原生輕量級(jí)容器的演進(jìn)歷程。每一次轉(zhuǎn)變升級(jí),都是基于不同時(shí)期的業(yè)務(wù)背景,所做出的技術(shù)迭代和自我革新。

第一階段:基于 LXC 的容器 T4 嘗試

受困于虛擬機(jī) KVM 的巨大開銷,以及 KVM 編排管理的復(fù)雜度,阿里集團(tuán)在 2011 年時(shí)發(fā)起對(duì) LXC 和 Linux Kernel 的定制,在內(nèi)部上線了基于 LXC 的 T4 容器。但相比后面出現(xiàn)的 Docker, T4 容器在技術(shù)上存在一些不足,比如沒有實(shí)現(xiàn)鏡像提取和應(yīng)用描述。T4 誕生后的多年,阿里持續(xù)嘗試在 T4 之上構(gòu)建復(fù)雜的基線定義,但屢屢遭遇問題。

第二階段:引入容器鏡像機(jī)制的 AliDocker,實(shí)現(xiàn)大規(guī)模分發(fā)

2015 年,阿里引入 Docker 的鏡像機(jī)制,將 Docker 和 T4 的功能取長(zhǎng)補(bǔ)短互相整合,即:讓 T4 具備 Docker 鏡像能力,同時(shí)又讓 Docker 具備了 T4 對(duì)內(nèi)部運(yùn)維體系的友好性,并在此基礎(chǔ)上形成內(nèi)部產(chǎn)品 AliDocker。

過程中,阿里引入 P2P 鏡像分發(fā)機(jī)制,隨著電商核心應(yīng)用逐步全面升級(jí)到 AliDocker,通過宿主機(jī)的環(huán)境隔離性和移植性,屏蔽了底層環(huán)境差異,為云化/統(tǒng)一調(diào)度/混部/存儲(chǔ)計(jì)算分離等后續(xù)基礎(chǔ)架構(gòu)變革打下了基礎(chǔ),鏡像機(jī)制的優(yōu)勢(shì)得以體現(xiàn)。其中,孵化的 P2P 鏡像分發(fā)是 2018 年 10 月加入 CNCF 的 Dragonfly。

第三階段:完全自主產(chǎn)權(quán)的容器 Pouch,阿里內(nèi)部全面容器化

隨著容器技術(shù)的規(guī)模化鋪開,AliDocker 化的優(yōu)勢(shì)得以體現(xiàn),阿里完全自主產(chǎn)權(quán)的 Pouch 得以展開并逐漸替代 AliDocker。同時(shí),阿里集團(tuán) 100% Pouch 化也一直在快速推進(jìn),2016 年 雙11 前,已經(jīng)實(shí)現(xiàn)了全網(wǎng)的容器化。

Pouch 寓意是一個(gè)神奇的育兒袋,為里面的應(yīng)用提供貼心的服務(wù)。因?yàn)?Pouch 統(tǒng)一了集團(tuán)在線應(yīng)用的運(yùn)行時(shí),應(yīng)用開發(fā)人員就無需關(guān)注底層基礎(chǔ)設(shè)施的變化。接下來的數(shù)年,底層基礎(chǔ)設(shè)施發(fā)生了云化、混部、網(wǎng)絡(luò) VPC 化、存儲(chǔ)無盤化、內(nèi)核升級(jí)、調(diào)度系統(tǒng)升級(jí)等各種技術(shù)演進(jìn),但 Pouch 容器運(yùn)行時(shí)使絕大部分底層變化對(duì)應(yīng)用無感知,屏蔽了對(duì)上層應(yīng)用的影響。Pouch 自身也把運(yùn)行時(shí)從 LXC 切換到了 runC,并將其核心技術(shù)反哺給開源社區(qū),同時(shí)集團(tuán)也逐步將過去的存量 AliDocker 實(shí)例無縫切換為開源的 Pouch 實(shí)現(xiàn)。

過程中富容器模式的存在,一方面讓用戶和應(yīng)用能夠無縫平滑地切換到容器化,另一方面應(yīng)用依賴的各種運(yùn)維、監(jiān)控、日志收集等運(yùn)維系統(tǒng),基于富容器模式也得以跟隨容器化平滑遷移。

但富容器也有著較多缺點(diǎn)。由于富容器中可以存在多個(gè)進(jìn)程,并且允許應(yīng)用開發(fā)和運(yùn)維人員登錄到容器中,這違反了容器的“單一功能”原則,也不利于不可變基礎(chǔ)設(shè)施的技術(shù)演進(jìn)。例如:Serverless 演進(jìn)過程中,調(diào)度插入的代理進(jìn)程實(shí)際上是與應(yīng)用無關(guān)的,一個(gè)容器中有太多的功能也不利于容器的健康檢查和彈性。

容器化是云原生的必經(jīng)之路。阿里集團(tuán)正是通過這種方式,快速走完了容器化這一步,極大加速了云原生的進(jìn)一步演進(jìn)。全面容器化后,云原生的大勢(shì)已經(jīng)不可阻擋,越來越多新的理念和應(yīng)用架構(gòu)在容器生態(tài)中成長(zhǎng)起來,基于容器和鏡像的應(yīng)用打包、分發(fā)、編排、運(yùn)維的優(yōu)勢(shì)被越多的人看到、接受和擁抱,各種運(yùn)維系統(tǒng)開始適配云原生架構(gòu)。

第四階段:調(diào)度系統(tǒng)兼收并蓄及 ACK 的演進(jìn)

隨著以 Kubernetes 為代表的容器技術(shù)成為云計(jì)算的新界面,阿里自研的 Sigma 也在持續(xù)探索 Kubernetes 的落地實(shí)踐,并借助集團(tuán)全面上云的契機(jī),最終實(shí)現(xiàn)了從 Sigma 管控到 ACK 的全面遷移。

2018 年,集團(tuán)調(diào)度系統(tǒng)開始了從內(nèi)部定制的 Sigma 到  ACK 的逐步演進(jìn),容器輕量化成為一個(gè)重要的演進(jìn)目標(biāo)。云原生浪潮下,集團(tuán)內(nèi)部的運(yùn)維生態(tài)也隨之快速演進(jìn)。輕量化容器的解決思路是用 Kubernetes 的 Pod 來拆分容器,剝離出獨(dú)立的運(yùn)維容器,并將眾多與應(yīng)用無關(guān)的運(yùn)維進(jìn)程逐個(gè)轉(zhuǎn)移至運(yùn)維容器。

Sigma 誕生之初致力于將阿里集團(tuán)眾多割裂的在線資源池整合統(tǒng)一,在此基礎(chǔ)上,不斷探索新的資源混跑形態(tài),包括在離線混部、離在線混部、Job 調(diào)度、CPUShare、VPA 等眾多技術(shù)。通過提升阿里集團(tuán)數(shù)據(jù)中心整體資源利用率,帶來巨大的成本節(jié)約效益?;谌泄苊膺\(yùn)維 Sigma Master、公共大資源池、應(yīng)用額度服務(wù),提供 Serverless 的資源交付和最佳的用戶體驗(yàn)。Sigma 調(diào)度也加速了 T4 到 Pouch 的全面容器化進(jìn)程,通過應(yīng)用研發(fā)自定義的 Dockerfile 標(biāo)準(zhǔn)化容器,以及透明化基礎(chǔ)設(shè)施的 Sigma 調(diào)度引擎,業(yè)務(wù)研發(fā)已無需關(guān)心底層運(yùn)維,工作重心得以聚焦于業(yè)務(wù)本身。

從 Sigma 到 ACK 的升級(jí),是希望 ACK 領(lǐng)先的云產(chǎn)品能力得以賦能阿里集團(tuán),使得 Sigma 可以加速享受云計(jì)算的能力,包括異構(gòu)資源的統(tǒng)一管理、面向全球化的安全合規(guī)等。但實(shí)際上,遷移 ACK 的過程并非一帆風(fēng)順:

首先,圍繞著核心管控鏈路,阿里原有的規(guī)模和復(fù)雜場(chǎng)景能力、原有的龐大存量容器如何遷移到新的平臺(tái),以及容器界面如何兼容并影響現(xiàn)有的龐大生態(tài)體系升級(jí),實(shí)際上都會(huì)成為演進(jìn)中的包袱和劣勢(shì)。實(shí)現(xiàn)在高速飛行中換引擎并解決存量遷移問題的難度,這在業(yè)界都有共鳴。

其次,性能、多集群運(yùn)維、安全防御、穩(wěn)定性等眾多問題,都是全面遷移 ACK 的挑戰(zhàn)。圍繞著性能,阿里基于原生 Kubernetes 做了非常多的優(yōu)化并回饋給社區(qū),如 Cache Index、Watch Bookmark 等,并建設(shè)了一整套 Kubernetes 規(guī)?;O(shè)施,包括安全防御組件、OpenKruise、多集群組件發(fā)布等能力等。

圍繞 “經(jīng)濟(jì)體調(diào)度 = ACK + 經(jīng)濟(jì)體擴(kuò)展” 的總體思路,阿里集團(tuán)內(nèi)部遷移至 ACK 過程中的積累又能沉淀給云,豐富產(chǎn)品能力,幫助客戶形成云上的競(jìng)爭(zhēng)力。至此,阿里集團(tuán)內(nèi)部、阿里云、開源社區(qū)形成了非常好的技術(shù)合力,自研、商用、開源,三位一體融合互補(bǔ)。

自研、商用、開源,三位一體融合互補(bǔ)

技術(shù)和業(yè)務(wù)是相輔相成的,業(yè)務(wù)為技術(shù)提供場(chǎng)景促進(jìn)技術(shù)進(jìn)步;技術(shù)的進(jìn)步反過來帶動(dòng)業(yè)務(wù)更好的發(fā)展。復(fù)雜而豐富的場(chǎng)景,提供了一個(gè)天然肥沃的土壤,進(jìn)一步推動(dòng)阿里技術(shù)的發(fā)展。阿里集團(tuán)的技術(shù)一直持續(xù)保持先進(jìn)。在過去,業(yè)內(nèi)一直非常領(lǐng)先的中間件、容器、調(diào)度等各類技術(shù),阿里都率先應(yīng)用于業(yè)務(wù),并將能力沉淀到云產(chǎn)品再輸送給客戶,助力企業(yè)加速數(shù)字化轉(zhuǎn)型,產(chǎn)生了廣泛的引領(lǐng)者影響力。

但在新云原生時(shí)代,如何在云原生標(biāo)準(zhǔn)下持續(xù)保持這份影響力,我們看到了更多挑戰(zhàn)。上述的阿里容器界面演進(jìn)簡(jiǎn)史記錄了一線阿里工程師們?nèi)绾螒?yīng)對(duì)這些挑戰(zhàn)。更抽象地講,這些得益于阿里巴巴云原生技術(shù)體系自研、商用、開源三位一體的戰(zhàn)略決策。

1. 阿里云側(cè)的挑戰(zhàn)

阿里云過去面對(duì)的用戶大部分是普適性用戶,而阿里集團(tuán)內(nèi)部場(chǎng)景的訴求是需要解決大規(guī)模、超高性能等問題,阿里云產(chǎn)品能否很好地兼顧和支撐是非常大的挑戰(zhàn)。進(jìn)一步考慮,如果我們能很好地抽象出大眾用戶的訴求,阿里集團(tuán)對(duì)阿里云來說又是一個(gè)非常好的“試煉場(chǎng)”。

2. 集團(tuán)內(nèi)部的挑戰(zhàn)

船小好調(diào)頭,而船大就沒那么靈活了。過去業(yè)界獨(dú)有的阿里集團(tuán)內(nèi)部龐大規(guī)模場(chǎng)景,現(xiàn)在反而是邁向云原生的包袱。問題的根本在于如何讓阿里集團(tuán)的技術(shù)能夠快速融合和貢獻(xiàn)云原生標(biāo)準(zhǔn),而不是形成技術(shù)孤島。

3. 開源側(cè)的挑戰(zhàn)和機(jī)遇

開源側(cè)的挑戰(zhàn)和機(jī)遇:阿里云在云原生開源項(xiàng)目貢獻(xiàn)中有著持續(xù)投入,推出了 OpenKruise、聯(lián)合微軟推出 OAM、KubeVela 等開源項(xiàng)目,這些都源于阿里巴巴在云原生領(lǐng)域的沉淀, 并且通過開源社區(qū)用戶的反饋,完善在阿里云原生落地的解決方案。以 OpenKruise 為例, 該項(xiàng)目是阿里巴巴打造的一個(gè)基于 Kubernetes 的、面向大規(guī)模應(yīng)用場(chǎng)景的通用擴(kuò)展引擎,它的開源使每一位 Kubernetes 開發(fā)者和阿里云上的用戶都能便捷地使用阿里巴巴內(nèi)部云原生應(yīng)用統(tǒng)一的部署發(fā)布能力。當(dāng)社區(qū)用戶或外部企業(yè)遇到了 Kubernetes 原生 workload 不滿足的困境時(shí),企業(yè)內(nèi)部不需要重復(fù)造一套相似的“輪子”,而是可以選擇使用 OpenKruise 的成熟能力。而且,阿里集團(tuán)內(nèi)部使用的 OpenKruise 和開源社區(qū)版本中有 95% 以上的代碼是完全一樣的。我們希望和每一位參與 OpenKruise 建設(shè)的云原生愛好者,共同打造了這個(gè)更完善、普適的云原生應(yīng)用負(fù)載引擎。

云原生操作系統(tǒng)的進(jìn)化

2.webp.jpg

如今,在云原生應(yīng)用架構(gòu)界面層,阿里集團(tuán)的技術(shù)體系正在全面切向云原生技術(shù)、云產(chǎn)品。

阿里云為客戶提供的云原生操作系統(tǒng), 首先基礎(chǔ)設(shè)施層是強(qiáng)大的 IaaS 資源,基于第三代神龍架構(gòu)的計(jì)算資源可以更彈性的擴(kuò)展,以更加優(yōu)化的成本提供更高的性能;云原生的分布式文件系統(tǒng),為容器持久化數(shù)據(jù)而生;云原生網(wǎng)絡(luò)加速應(yīng)用交付能力,提供應(yīng)用型負(fù)載均衡與容器網(wǎng)絡(luò)基礎(chǔ)設(shè)施。

其次在容器編排層,阿里云容器服務(wù)自 2015 年上線來,伴隨數(shù)千家企業(yè)客戶,共同實(shí)踐過各行各業(yè)大量生產(chǎn)級(jí)場(chǎng)景。越來越多的客戶以云原生的方式架構(gòu)其大部分甚至全量應(yīng)用,隨著業(yè)務(wù)深入發(fā)展,為了滿足大中型企業(yè)對(duì)可靠性、安全性的強(qiáng)烈需求,阿里云推出新品可供賠付 SLA 的容器服務(wù)企業(yè)版 ACK Pro,并同樣支撐了阿里集團(tuán)內(nèi)部的眾多產(chǎn)品的落地。

容器服務(wù) ACK Pro 版,針對(duì)金融、大型互聯(lián)網(wǎng)、政企客戶的需求,支持更大規(guī)模集群,更高性能和更加全面的安全防護(hù)。

首先,基于神龍架構(gòu),軟硬一體化優(yōu)化設(shè)計(jì),提供卓越性能:

無損 Terway 容器網(wǎng)絡(luò),簡(jiǎn)化數(shù)據(jù)鏈路,相比路由網(wǎng)絡(luò)延遲下降 30%。

支持全球首款持久性內(nèi)存實(shí)例,相比 NVMe,I/O 密集應(yīng)用 TPS 提升 100%。

其次,提供對(duì)異構(gòu)算力和工作負(fù)載優(yōu)化的高效調(diào)度:

智能 CPU 調(diào)度優(yōu)化,在保障 SLA 和密度的前提下,Web 應(yīng)用 QPS 提升 30%。

支持 GPU 算力共享, AI 模型預(yù)測(cè)成本節(jié)省 50% 以上。

最后,為企業(yè)提供全面安全防護(hù):

支持阿里云安全沙箱容器,滿足企業(yè)客戶對(duì)應(yīng)用的安全、隔離需求,性能相比開源提升 30%。

國(guó)內(nèi)首批通過可信云容器安全先進(jìn)性認(rèn)證,支持運(yùn)行時(shí)風(fēng)險(xiǎn)秒級(jí)阻斷。

同時(shí),阿里云全托管托管服務(wù)網(wǎng)格 ASM 正式商用化,這是業(yè)內(nèi)首個(gè)全托管 Istio 兼容服務(wù)網(wǎng)格 ASM。

ASM 可以實(shí)現(xiàn)多種異構(gòu)應(yīng)用服務(wù)統(tǒng)一治理,提供了對(duì)云上虛擬機(jī),容器,彈性容器實(shí)例,和 IDC 應(yīng)用等異構(gòu)服務(wù)的統(tǒng)一管理,提供全鏈路可觀測(cè)性和端到端安全防護(hù)。幫助您加速企業(yè)應(yīng)用的現(xiàn)代化改造,輕松構(gòu)建混合云 IT 架構(gòu)。

3.webp.jpg

阿里云容器服務(wù)連續(xù)兩年國(guó)內(nèi)唯一進(jìn)入 Gartner《公有云容器服務(wù)競(jìng)爭(zhēng)格局》報(bào)告;在 Forrester 首個(gè)企業(yè)級(jí)公共云容器平臺(tái)報(bào)告中,阿里云容器服務(wù)位列 Strong Performer, 中國(guó)第一。

展望

云計(jì)算的未來是云原生,容器新界面是進(jìn)化中的關(guān)鍵一小步。向下,容器新界面帶來的高密度、高頻度的能力要求會(huì)進(jìn)一步催熟云計(jì)算的端到端優(yōu)化;向上,基于容器新界面的 Serverless、新一代的中間件、新一代的應(yīng)用 PaaS 方興未艾。

云原生技術(shù)正成為釋放云價(jià)值的最短路徑,未來,阿里巴巴將會(huì)持續(xù)在云原生上進(jìn)行投入,而阿里的云原生技術(shù)不僅會(huì)在內(nèi)部大規(guī)模普及,也通過阿里云服務(wù)全社會(huì)。

THEEND

最新評(píng)論(評(píng)論僅代表用戶觀點(diǎn))

更多
暫無評(píng)論