2020年12月1日，當(dāng)世界為以COVID-19大流行為主導(dǎo)的動(dòng)蕩年末做準(zhǔn)備時(shí)，AWS為云社區(qū)帶來了早期的禮物。 對(duì)AWS Lambda函數(shù)的容器支持。將Lambda函數(shù)打包和部署為容器映像的能力，因此使您可以利用容器提供的好處運(yùn)行Lambda函數(shù)。

無服務(wù)器功能使行業(yè)可以立即啟動(dòng)并運(yùn)行業(yè)務(wù)代碼。新穎的計(jì)算服務(wù)提供了擺脫設(shè)置復(fù)雜基礎(chǔ)架構(gòu)和配置的復(fù)雜性以及在生產(chǎn)中運(yùn)行的可伸縮性和相關(guān)操作的能力。

但是，無服務(wù)器產(chǎn)品處于當(dāng)前狀態(tài)，因此受到很大限制。例如，當(dāng)嘗試使用您正在使用的無服務(wù)器產(chǎn)品不支持的編程語言時(shí)，或者在鍵入以導(dǎo)入庫時(shí)。AWS Lambda層 通過允許用戶將所需的庫和外部代碼庫作為“層”添加到您的AWS Lambda函數(shù)之上來解決此問題。同樣，Azure提供了“綁定擴(kuò)展” ，該綁定擴(kuò)展用作社區(qū)的開放源代碼模型來構(gòu)建新的綁定類型，然后可以將其引入您的Azure函數(shù)中。

不幸的是，這些方法在如何利用它們方面有局限性。因此， 對(duì)AWS Lambda功能的新容器映像支持遵循了AWS的目標(biāo)，即提供緩解措施和解決方案來緩解云社區(qū)所面臨的障礙。

結(jié)合并平衡無服務(wù)器和容器產(chǎn)品的功能，這不是一個(gè)新的跨越。問題在于，無服務(wù)器帶來的好處使計(jì)算范例極具吸引力，但同時(shí)也導(dǎo)致靈活性和使用性受到其他限制。這是有蛋糕卻不能吃的古老諺語。

但是，云供應(yīng)商現(xiàn)在正努力克服這一問題，因?yàn)樗麄兏傁嗵峁└鞣N云計(jì)算服務(wù)，并通過提供方便的靈活性的功能來增強(qiáng)這些服務(wù)。考慮考慮在列出這些折衷時(shí)可以進(jìn)行的各種排列，每項(xiàng)服務(wù)都提供自己的折衷。這樣做的目的是提供足夠多的服務(wù)產(chǎn)品列表以及這些服務(wù)中的功能，以確保它們可以通過其多樣化的客戶群最好地滿足云市場的需求。

例如，AWS提供 EC2容器，AWS Lambda函數(shù)和AWS Fargate。Azure 和GCP 提供類似的服務(wù)，例如Azure容器注冊表，Azure容器實(shí)例，Google Cloud Run等。此外，我們可以注意到一些功能，例如AWS Lambda層，AZure Binding Extensions和各種其他增量改進(jìn)。

可以看出，云供應(yīng)商擁有跨計(jì)算范式和范式本身的高級(jí)服務(wù)。除了我們在這些供應(yīng)商的無服務(wù)器產(chǎn)品中注意到的改進(jìn)之外，我們還看到無服務(wù)器容器的興起，即容器即服務(wù)（CaaS）。因此，本文的目的是探索容器即服務(wù)的概念，并認(rèn)可著名的云供應(yīng)商AWS，Azure和Google Cloud在云中可用的當(dāng)前服務(wù)。

探究CaaS范式

云計(jì)算的誘人前景之一是大大降低了管理服務(wù)器硬件的復(fù)雜性。隨著云產(chǎn)品的興起，我們可以簡單地將硬件管理職責(zé)委托給云供應(yīng)商。但是，我們現(xiàn)在必須學(xué)習(xí)如何通過云供應(yīng)商平臺(tái)配置虛擬服務(wù)器，從而引入一種新型的操作負(fù)擔(dān)。多年來，基礎(chǔ)架構(gòu)即服務(wù)（IaaS）已從容器即服務(wù)（CaaS）演變?yōu)樽罱K功能即服務(wù)（FaaS）。這些不同的范例都提供不同的抽象級(jí)別，而FaaS是最容易使用的范例，因?yàn)樗哂凶疃嗟某橄蠹?jí)別。

自然，云開發(fā)人員會(huì)急于使用FaaS服務(wù)，此后已經(jīng)成為無服務(wù)器 產(chǎn)品。但是，有一個(gè)陷阱。隨著更多的抽象導(dǎo)致更少的操作負(fù)擔(dān)，人們不得不犧牲靈活性并忍受操作限制。

例如，對(duì)于可以被視為IaaS范式的Amazon EC2實(shí)例，您必須指定規(guī)則，網(wǎng)絡(luò)安全監(jiān)控等等。除了容器編排之外，主要問題還在于自動(dòng)縮放，因?yàn)樵谌萜骷?jí)別定義縮放規(guī)則非常繁瑣。但是，所有這些額外的操作負(fù)擔(dān)確實(shí)意味著您幾乎可以按照任何希望的方式來配置環(huán)境。因此，您可以選擇任何運(yùn)行時(shí)，例如，不必?fù)?dān)心超時(shí)限制，還可以定義最適合您的業(yè)務(wù)需求的精細(xì)自動(dòng)縮放規(guī)則。

但是，有了這種增加的靈活性，您將失去無服務(wù)器的三個(gè)主要特征，這也是計(jì)算模型的最大優(yōu)勢。這些如下：

· 服務(wù)器管理抽象給供應(yīng)商

· 隨用隨付模式，您只需為使用的商品付費(fèi)

· 自動(dòng)可擴(kuò)展且高度可用

這就是CaaS范式旨在通過方便地坐在容器和無服務(wù)器服務(wù)之間來達(dá)到最佳效果的地方。要了解如何操作，讓我們考慮該領(lǐng)域的三家主要云供應(yīng)商提供的CaaS產(chǎn)品。

浮在云端的容器

AWS Fargate

與分別是傳統(tǒng)Iaas和FaaS服務(wù)的Amazon EC2和AWS Lambda函數(shù)相比，AWS Fargate是AWS的CaaS解決方案。因此，與Amazon EC2不同，已經(jīng)建立了容器基礎(chǔ)架構(gòu)，包括網(wǎng)絡(luò)，安全性，最重要的是擴(kuò)展。使用該服務(wù)，您只需要為每個(gè)容器實(shí)例指定資源，然后讓Fargate在后臺(tái)進(jìn)行工作即可。

每個(gè)Fargate實(shí)例都帶有其專用的ENI， 以允許任務(wù)間群集之間進(jìn)行通信，而同一任務(wù)的群集則通過localhost進(jìn)行通信。此外，這些任務(wù)的管理再次由ECS完成。Fargate被定義為ECS的計(jì)算引擎，提供了一種不同的任務(wù)管理方式，這就是Fargate將其鏈接到容器服務(wù)的定義特征。

但是，這只是Fargate的一面，也有整個(gè)無服務(wù)器的一面，這是由于它建立在AWS Firecracker之上。因此，能夠?qū)崿F(xiàn)所需的自動(dòng)擴(kuò)展風(fēng)扇有助于按需付費(fèi)模型。

Azure容器實(shí)例

Azure 在2017年中宣布Azure容器實(shí)例（ACI）時(shí)，成為第一家提供CaaS服務(wù)的云供應(yīng)商。其目的是為了簡化開發(fā)人員設(shè)置容器實(shí)例的經(jīng)驗(yàn)，從而在其CaaS產(chǎn)品中引起所有其他供應(yīng)商的共鳴。

考慮到安全性，網(wǎng)絡(luò)和存儲(chǔ)，ACI允許設(shè)置具有預(yù)配置屬性的隔離容器。例如，所有ACI都增強(qiáng)了其安全能力，因?yàn)槠涓髯缘娜萜髂Ｐ驮谔摂M機(jī)監(jiān)控程序級(jí)別提供了保護(hù)。這使得ACI成為多租戶用例的理想解決方案。此外，計(jì)費(fèi)模型遵循無服務(wù)器計(jì)算服務(wù)的計(jì)費(fèi)模型，在該模型中，ACI的采用者只需按 每秒使用的內(nèi)存和vCPU數(shù)來支付他們使用的資源，這與AWS Fargate相似。

必須注意，定價(jià)模型可能會(huì)因Azure提供的不同資源類型而異。但是，這也是因?yàn)锳WS Fargate在不支持特殊容器（例如GPU）的情況下限制了您可以預(yù)配的容器類型，這些特殊容器在ACI中可用，但由于明顯的原因而定價(jià)不同。

Azure提供了一個(gè)高度集成的生態(tài)系統(tǒng)，可以在采用ACI時(shí)增強(qiáng)開發(fā)人員的體驗(yàn)。例如， 在部署容器映像時(shí)，我們可以利用Azure容器注冊表（ACR），類似于Docker注冊表。此外，還有一些工具和服務(wù)，如Azure的門戶網(wǎng)站，Azure的CLI ， 和Azure的資源管理器 在我們的處置模板。

我們應(yīng)該探索的第三個(gè)CaaS服務(wù)是Google Cloud的Cloud Run。這是這組CaaS列表中發(fā)布的最新服務(wù)，將于2019年11月開始普遍提供。使用Google Cloud Run，開發(fā)人員可以置備無狀態(tài)容器，類似于其他兩家供應(yīng)商提供的CaaS服務(wù)。借助該服務(wù)，Google設(shè)法保留了無服務(wù)器的核心優(yōu)勢，同時(shí)以對(duì)其他編程語言，系統(tǒng)二進(jìn)制文件或任何所需的庫的支持的形式提供了額外的靈活性。

盡管Google Cloud Run是最后進(jìn)入市場的產(chǎn)品，但Google已經(jīng)以Google Kubernetes Engine（GKE）的形式提供了某種CaaS服務(wù)。作為Kubernetes的創(chuàng)造者，Google提供完全托管的Kubernetes服務(wù)是很自然的。丈量Atamel 談到GKE，以及如何在他帶來Kubernetes到無服務(wù)器平臺(tái)的談話 在ServerlessDays伊斯坦布爾。

我之所以將GKE描述為某種CaaS的原因是，根據(jù)我的說法，它更多地是Kubernetes即服務(wù)（KaaS）產(chǎn)品而不是CaaS。這是因?yàn)樗煌耆袷丶锤都从媚Ｊ?。手?dòng)創(chuàng)建GKE集群時(shí)，節(jié)點(diǎn)和環(huán)境將永久可用，因此無論使用情況如何，都將產(chǎn)生成本。考慮到這一點(diǎn)，Google Cloud Run更加無服務(wù)器，因此可以更好地定義為CaaS服務(wù)。總體而言，在比較GKE和Google Cloud Run時(shí)，我們看到后者需要按需付費(fèi)的模型，因此編排較少，更貼切。

結(jié)論

隨著向云計(jì)算的發(fā)展，云供應(yīng)商正在不斷創(chuàng)新以滿足客戶的需求。隨著行業(yè)開始采用云技術(shù)，容器編排成為發(fā)展的主要痛點(diǎn)。為了緩解這些問題，我們看到了無服務(wù)器時(shí)代的到來。即使新穎的計(jì)算模型設(shè)法抽象了所有基礎(chǔ)架構(gòu)設(shè)置，但它還是犧牲了靈活性。因此，現(xiàn)在看到無服務(wù)器容器的興起，兩全其美。

AWS，Azure和最近的Google Cloud都已通過各自的服務(wù)進(jìn)入該領(lǐng)域。無論他們提供的產(chǎn)品有何不同，我們都看到這三個(gè)目標(biāo)之間的共鳴。在簡化容器編排的同時(shí)，仍保留所需的靈活性，以便利開發(fā)人員在使用云的過程中的眾多用例，從而總體上促進(jìn)云的采用。畢竟，自從過去十年以來，云的概念一直是軟件的主要焦點(diǎn)，從而改變了軟件的構(gòu)建和運(yùn)行方式。CaaS只是通過創(chuàng)新方式改善了體驗(yàn)，使偉大發(fā)明家Thomas Edison的創(chuàng)新路線永垂不朽。“一個(gè)想法的價(jià)值在于它的使用”。
責(zé)任編輯：YYX