在Re:Invent 2019大會上，我們公布了可以在Amazon Elastic Kubernetes Service（Amazon EKS）上使用Amazon Fargate來部署Kubernetes Pod的全新功能。因?yàn)槲覀兛吹娇蛻艨焖俳邮苁褂肒ubernetes API的方式將Pod部署在用于運(yùn)行容器的Amazon無服務(wù)器基礎(chǔ)設(shè)服務(wù)施Fargate當(dāng)中。這種全新實(shí)踐幫助他們徹底擺脫了由Kubernetes集群維護(hù)工作帶來的沉重負(fù)擔(dān)，包括與之相關(guān)的管理、修復(fù)、安全、隔離與擴(kuò)展等日常任務(wù)。
如果大家希望了解關(guān)于Amazon EKS與Fargate協(xié)同運(yùn)作的更多詳細(xì)信息，請參閱我在re:Invent大會上的分組討論內(nèi)容。
在此之前，Amazon Fargate雖然一直歸屬于Amazon Compute Savings Plan節(jié)約計劃的范圍之內(nèi)，但只適用于運(yùn)行在ECS上的任務(wù)上。今天，我們宣布在Fargate上運(yùn)行的EKS Pod也將被納入Amazon Compute Savings Plans之內(nèi)。您可以參閱What’s New公告帖以了解更多詳細(xì)信息。如果您已經(jīng)激活了Compute Savings Plan，那么無需任何額外操作，系統(tǒng)會根據(jù)您的Saving Plan為Fargate Pod提供相應(yīng)折扣。如果您還沒有激活Compute Savings Plan，不妨首先閱讀我們發(fā)布的Amazon Compute Savings Plan常見問題，逐步了解該如何讓自己的運(yùn)營體系獲得價格優(yōu)惠。只要客戶承諾在一年或三年周期內(nèi)保持穩(wěn)定的計算資源使用量，即可節(jié)約最高52%的Fargate使用成本。
Compute Savings Plans面向的不僅僅限定于某一項(xiàng)特定技術(shù)。Compute Savings Plans靈活性極高，能夠?yàn)槟鷮?shí)際選用的多種計算服務(wù)提供價格優(yōu)惠。例如，您可以選擇EC2、Fargate或Lambda。如果選擇Fargate，則可在ECS與EKS之間自由使用您所熟悉的編排方案。無論如何選擇，Compute Savings Plans都將為您帶來可觀的價格折扣。
Compute Savings Plans是將EKS與Fargate結(jié)合起來，進(jìn)而降低并優(yōu)化成本的最直接、最具實(shí)效的方法之一。在今天的博文中，我們將概括并總結(jié)當(dāng)Farget和傳統(tǒng)EC2集群對比時需要考慮的一些點(diǎn)。
AMAZON Fargate使用成本詳解
有時候，客戶會將Fargate計算成本與EC2計算成本進(jìn)行比較。這里我們舉個簡單的例子，在us-east-1區(qū)域內(nèi)選擇m5.large Linux按需實(shí)例（包含2個vCPU與8 GB內(nèi)存）和同等配置的Fargate作為比較對象。截至目前，此EC2實(shí)例的運(yùn)行成本為每小時0.096美元。而在同一區(qū)域中，F(xiàn)argate的計算成本可通過以下公式計算得出：(0.04048美元x 2 vCPU)+(0.004445美元x 8GB)=0.08096+0.03556=0.11652美元/小時。
但需要強(qiáng)調(diào)的是，F(xiàn)argate使用混合EC2實(shí)例類型集群，其性能可能與最新一代EC2實(shí)例（例如m5或c5家族）有所不同。因此，盡管以上示例體現(xiàn)的是Fargate成本僅比EC2高出20%的最理想狀況，但考慮到實(shí)例之內(nèi)的代際更迭，實(shí)際性價比結(jié)論可能還將受到影響。這里建議大家根據(jù)特定設(shè)置進(jìn)行測試，并充分考慮自己的實(shí)際需求。我們一直在推動Fargate底層計算資源的更新，致力于幫助客戶消除這種性能差異及資源不統(tǒng)一問題。
如前文所述，在Fargate上啟動EKS Pod此前并不在Compute Savings Plans節(jié)約計劃的范圍之內(nèi)。因此在考慮Compute Savings Plans給EC2實(shí)例帶來的折扣之后，F(xiàn)argate與EC2實(shí)例成本之間的差距將更加明顯。但在此次公告中，我們將EKS/Fargate組合正式納入Compute Savings Plans，這不僅縮小了Fargate與EC2實(shí)例之間的成本差距，同時也保證選擇不同購買模式的客戶都能享受到這一重要優(yōu)惠。
另外需要強(qiáng)調(diào)的是，準(zhǔn)確比較的前提應(yīng)該是對整體情況的確切考量。在使用Fargate的情況下，我們不僅幫助客戶承擔(dān)起大量管理負(fù)擔(dān)，同時也消除了傳統(tǒng)虛擬機(jī)集群中常見的資源閑置或未能充分使用等問題。再有，AMAZON的基礎(chǔ)設(shè)施規(guī)模極為龐大，由此帶來的規(guī)模經(jīng)濟(jì)效應(yīng)足以在同等配置條件下為客戶帶來遠(yuǎn)超本地基礎(chǔ)設(shè)施的成本優(yōu)勢。這也是我們?yōu)閿?shù)百萬客戶服務(wù)的同時，建立起的一種獨(dú)特優(yōu)勢。
Amazon Fargate的價值與隱性運(yùn)營成本
使用托管服務(wù)的一大核心收益，在于客戶能夠?qū)⒆约旱臅r間與精力從無差別性的繁重工作當(dāng)中解放出來。Fargate同樣提供這樣的收益，可幫助客戶擺脫基礎(chǔ)設(shè)施運(yùn)營及維護(hù)相關(guān)的煩惱，將更多精力集中在應(yīng)用程序構(gòu)建與業(yè)務(wù)成果實(shí)現(xiàn)身上。
下面，我們將整理出一份粗略的全面清單，列出您選擇使用Fargate等托管服務(wù)時無需繼續(xù)關(guān)注的傳統(tǒng)問題。這些問題都有著相應(yīng)的“擁有成本”，屬于同“購置成本”并行存在的重要因素。
安全性
雖然容器技術(shù)在隔離與應(yīng)用程序依賴項(xiàng)打包（即容器鏡像）方面擁有著無可比擬的價值，但其帶來的運(yùn)行時隔離與安全性保障能力卻不及傳統(tǒng)虛擬機(jī)。最典型的就是“容器逃逸”問題，即惡意用戶可能在控制主機(jī)之后，訪問運(yùn)行在同一主機(jī)上的所有其他容器。
大家當(dāng)然可以使用各類技術(shù)緩解這些問題，包括創(chuàng)建單獨(dú)的主機(jī)區(qū)域以運(yùn)行高度敏感的工作負(fù)載、在容器配置當(dāng)中強(qiáng)制要求只能以非root用戶身份運(yùn)行等等。在實(shí)際使用中，一部分用戶寄希望于Kubernetes提供的高級配置，包括使用污點(diǎn)與容忍機(jī)制，或者親和與反親和規(guī)則等。但這一切都會帶來額外的復(fù)雜性，導(dǎo)致基礎(chǔ)設(shè)施優(yōu)化水平下降或運(yùn)營負(fù)擔(dān)增加，最終拉升運(yùn)營成本。Fargate則通過為任何給定Pod分配專用的、大小合適的虛擬機(jī)，從根本上解決了這個問題。在任意時間點(diǎn)上，兩個Pod都絕對不會同時運(yùn)行在同一虛擬機(jī)之上。借助Fargate，您可以在享受容器技術(shù)打包與靈活性優(yōu)勢的同時，繼續(xù)保持虛擬機(jī)代碼運(yùn)行硬邊界所帶來的安全優(yōu)勢。另外，運(yùn)行在Fargate上的各Kubernetes Pod并不共享同一操作系統(tǒng)，因此容器逃逸問題將得到很好的控制。
此外，同樣需要指出的是，F(xiàn)argate臨時存儲會默認(rèn)進(jìn)行加密，用戶無需執(zhí)行任何額外配置即可獲得安全保障。
總體而言，F(xiàn)argate推動了AMAZON責(zé)任分?jǐn)偰Ｐ偷钠占?。在使用Fargate的場景下，AMAZON負(fù)責(zé)承擔(dān)與安全相關(guān)的運(yùn)營任務(wù)，例如對用于運(yùn)行各Pod的虛擬機(jī)操作系統(tǒng)進(jìn)行更新等。這里建議大家參閱Amazon EKS安全最佳實(shí)踐指南，其中詳盡闡述了使用EC2與Fargate運(yùn)行Kubernetes Pod時在安全性方面的一些差別。
合規(guī)性
在受到嚴(yán)格監(jiān)管的行業(yè)中，客戶往往需要投入大量時間以保證所運(yùn)行的技術(shù)棧符合合規(guī)性要求。無論是ISO合規(guī)性、HIPAA合規(guī)性、PCI合規(guī)性還是其他類型的合規(guī)要求，都會給客戶的日常運(yùn)營帶來沉重負(fù)擔(dān)，特別是合規(guī)性自證報告所帶來的高昂人力與時間成本。而使用Amazon Fargate等托管服務(wù)的一項(xiàng)核心優(yōu)勢，在于您可以將合規(guī)保障任務(wù)交由亞馬遜云科技處理，因此只需要向?qū)徲嬋藛T提供特定服務(wù)的亞馬遜云科技相關(guān)合規(guī)文檔。另一種解決選項(xiàng)則是使用經(jīng)典的計算資源（例如Amazon EC2），并投入額外的時間與資金以保證其設(shè)置符合要求（并正確加以記錄）。截至本文撰稿時，大多數(shù)Fargate合規(guī)性認(rèn)證已經(jīng)適用于運(yùn)行在Fargate之上的ECS實(shí)例。我們也在努力將認(rèn)證覆蓋范圍擴(kuò)展到EKS/Fargate，請大家持續(xù)關(guān)注AMAZON合規(guī)性文檔以了解最新進(jìn)展。
AMI管理
去年，我們正式推出了EKS托管節(jié)點(diǎn)組，旨在減輕Kubernetes工作節(jié)點(diǎn)所帶來的管理負(fù)擔(dān)。托管節(jié)點(diǎn)仍然運(yùn)行在您的亞馬遜云科技賬戶之內(nèi)，并由您承擔(dān)節(jié)點(diǎn)的保護(hù)與修復(fù)責(zé)任；盡管亞馬遜云科技將為您提供經(jīng)過更新的AMI（Amazon Machine Imagine）以替換各工作節(jié)點(diǎn)，借此簡化運(yùn)營流程。您仍將保留對這些實(shí)例的root訪問權(quán)限，而EKS則協(xié)助處理生命周期管理工作，因此這種新機(jī)制并不屬于亞馬遜云科技完全托管方案。與這種托管節(jié)點(diǎn)不同，在使用Fargate時，亞馬遜云科技將包攬所有運(yùn)營任務(wù)，您不必插手AMI或底層主機(jī)操作系統(tǒng)修復(fù)等事務(wù)。同樣的，使用Fargate時亞馬遜云科技將保證您的每一個新Pod都運(yùn)行在經(jīng)過完全修復(fù)及強(qiáng)化的基礎(chǔ)設(shè)施之上。換言之，您無需考慮應(yīng)該在運(yùn)行Pod的節(jié)點(diǎn)上使用哪種AMI。
這里需要強(qiáng)調(diào)的是，即使是在托管狀態(tài)下，節(jié)點(diǎn)更新仍然需要通過滾動部署新的AMI來實(shí)現(xiàn)。而這種操作方式會給Pod帶來影響，因?yàn)镻od會在節(jié)點(diǎn)終止之前發(fā)送一條終止信號以撤出當(dāng)前節(jié)點(diǎn)。對于純橫向擴(kuò)展及無狀態(tài)應(yīng)用程序來說，這項(xiàng)操作一般不會構(gòu)成問題，但其他類型的應(yīng)用程序，當(dāng)基礎(chǔ)設(shè)施經(jīng)歷滾動更新時，是有可能因此受到?jīng)_擊的。對于一般每30天定期進(jìn)行一波AMI輪替的金融機(jī)構(gòu)而言，這種滾動部署有可能給日常運(yùn)營帶來額外負(fù)擔(dān)。
通用K8s工作節(jié)點(diǎn)管理
除了AMI管理之外，結(jié)合前文所述，大家還需要考慮通用工作節(jié)點(diǎn)管理及其相應(yīng)成本問題。在使用托管節(jié)點(diǎn)與自動規(guī)模伸縮組（ASG）時，雖然您的運(yùn)營工作量將得到顯著削減，但仍需要在實(shí)例之上運(yùn)行Kubernetes生態(tài)系統(tǒng)提供的多種工具以實(shí)現(xiàn)適當(dāng)?shù)幕A(chǔ)設(shè)施操作。以節(jié)點(diǎn)問題檢測器為例，雖然其占用的資源不算很多，但在運(yùn)營用于支持Pod的基礎(chǔ)設(shè)施時，該檢測器仍然會增加你的工作量。
使用Fargate，基礎(chǔ)設(shè)施的管理工作將完全歸于亞馬遜云科技?；A(chǔ)設(shè)施將定期接收更新；在啟動Pod時，亞馬遜云科技會在全新虛擬機(jī)中預(yù)先部署全部最新軟件版本，以保證Pod始終在最新技術(shù)棧內(nèi)啟動。
Cluster Autoscaler
Cluster Autoscaler(CA)是一款常用的Kubernetes插件，用于根據(jù)集群中所運(yùn)行Pod的負(fù)載情況，對工作節(jié)點(diǎn)進(jìn)行縱向規(guī)模伸縮調(diào)整。CA提供多種豐富功能，但也可能會令您的運(yùn)營體系變得更加復(fù)雜。例如，用于確定何時向集群中添加節(jié)點(diǎn)、以及何時刪除節(jié)點(diǎn)的整個配置，會極大影響到集群的運(yùn)行成本。建議大家參閱CA常見問題解答以了解其中配置的豐富度與靈活性。此外，您也可以點(diǎn)擊此處查看用于調(diào)整CA運(yùn)行方式的受支持參數(shù)清單。
當(dāng)CA確定應(yīng)執(zhí)行規(guī)?？s減操作時，大家同樣需要考慮其對Pod運(yùn)行造成的影響。運(yùn)行在待擴(kuò)展節(jié)點(diǎn)上的原有Pod將被逐出，并在其他節(jié)點(diǎn)上重新啟動。這部分內(nèi)容，請參閱常見問題解答部分?？傊?，根據(jù)相應(yīng)Pod的實(shí)際作用，這種情況有可能破壞業(yè)務(wù)的正常運(yùn)轉(zhuǎn)，且對不完全無狀態(tài)類應(yīng)用的影響尤其明顯。
使用Fargate，您將不再需要CA，因此上述問題也將不復(fù)存在。配合Fargate，每個容器都將在大小合適的虛擬機(jī)上啟動并運(yùn)行，且該虛擬機(jī)的生命周期與容器本身完全相同。由于不涉及節(jié)點(diǎn)，因此我們無需執(zhí)行任何集群擴(kuò)展操作。
工作節(jié)點(diǎn)的大小調(diào)整與可用容量
您的Kubernetes Pod通常需要運(yùn)行在一組EC2實(shí)例之上，而這些實(shí)例也決定了集群的總體容量。但是，選擇合適的實(shí)例大小并非易事。同樣的，由于單一節(jié)點(diǎn)組僅支持單一實(shí)例類型，因此只選擇特定的實(shí)例大小也有可能導(dǎo)致容量失衡。我們當(dāng)然可以使用Cluster Autoscaler跨越多個不同節(jié)點(diǎn)組實(shí)施管理，借此優(yōu)化資源容量；但這無疑也會增加集群設(shè)置的復(fù)雜程度。使用Fargate，每個Pod都將運(yùn)行在大小合適的虛擬機(jī)上，您只需要為Pod運(yùn)行當(dāng)中實(shí)際消耗的資源量付費(fèi)。實(shí)例大小、類型或者實(shí)例資源利用率，這一切從此與您無關(guān)。
節(jié)點(diǎn)大小調(diào)整中的另一項(xiàng)重要工作，在于平衡Pod可支配容量與主機(jī)規(guī)定總?cè)萘恐g的關(guān)系。如果您的工作節(jié)點(diǎn)擁有8 GB內(nèi)存，那么其中只有一部分可用于運(yùn)行實(shí)際應(yīng)用程序。例如，您需要為操作系統(tǒng)本體中運(yùn)行的部分服務(wù)保留資源，為Kubelet保留資源，還需要為Kubernetes逐出操作的閾值觸發(fā)器保留資源。總體而言，這些“系統(tǒng)預(yù)留”資源一般會占到主機(jī)總資源量的10%到30%。這里推薦另一篇說明文章，其中列出了部分系統(tǒng)預(yù)留容量示例。再有，如果需要從節(jié)點(diǎn)中逐出部分負(fù)載，大家還需要考慮如何對工作負(fù)載進(jìn)行優(yōu)先級分類及排序。從這個角度來看，我們顯然無法簡單將主機(jī)的總體容量數(shù)值除以單一Pod的資源需求量，由此粗暴計算出其上所能承載的Pod總數(shù)。即使不考慮這些“系統(tǒng)預(yù)留”，主機(jī)上同樣有可能存在其他固有的效率低下因素。但在Fargate方面，除了Kubelet之外，所有資源都可供Fargate充分使用，且您只需要按Fargate的凈使用資源付費(fèi)。稍后我們將進(jìn)一步討論這個話題。
除了設(shè)計層面帶來的系統(tǒng)預(yù)留資源量外，很多客戶還傾向于人為對集群進(jìn)行過度配置。這樣做當(dāng)然有其道理，包括通過Cluster Autoscaler的豐富功能選項(xiàng)對Pod進(jìn)行快速擴(kuò)展，借此實(shí)現(xiàn)更高的可用性。從本質(zhì)上講，這意味著提醒CA在未來添加或刪除某些Pod時，可能需要隨之調(diào)整集群大小。這種方式雖然帶來了充分的靈活性，但同時也會引發(fā)額外的基礎(chǔ)設(shè)施成本，導(dǎo)致大家為實(shí)際上并未用到的容量（至少沒有充分使用）付費(fèi)。
成本追溯
相當(dāng)一部分EKS客戶使用的是多租戶集群。因此，對于集中IT團(tuán)隊而言，必須能夠在不同內(nèi)部用戶（即各集群租戶）之間明確劃分成本歸屬。但這里存在著嚴(yán)重的斷層。EKS集群管理員使用的成本單位是作為工作節(jié)點(diǎn)的實(shí)例類型，而EKS集群用戶的成本單位則是其當(dāng)前運(yùn)行的一個個Pod。不少客戶只能通過跟蹤“誰用了什么”來實(shí)現(xiàn)資源使用成本的規(guī)范化追溯。但出于種種原因，這種處理方式相當(dāng)復(fù)雜且難以實(shí)現(xiàn)。Kubernetes容器并非亞馬遜云科技中的第一類對象，因此我們無法使用原生亞馬遜云科技成本分配機(jī)制對容器開展追蹤。
因此，客戶經(jīng)常會使用第三方工具以跟蹤資源使用情況，并據(jù)此生成成本追溯報告。但是，這些工具很難回答另一個同樣重要的問題：誰該為未經(jīng)實(shí)際使用的資源付費(fèi)？如前所述，您的集群很可能從未以100%的利用率運(yùn)行過。結(jié)合實(shí)際經(jīng)歷，大多數(shù)集群可能長期處于利用率不足50%的狀態(tài)。雖然一部分客戶會投入大量時間與工程資源對這些集群進(jìn)行調(diào)優(yōu)，但即使如此其資源利用率也幾乎不可能超過80%。這些數(shù)字背后并無特定的科學(xué)依據(jù)，主要源自我們與客戶之間的交流與總結(jié)。根據(jù)以上的分歧，造成了一些問題，例如誰該為這部分20%或者50%的閑置資源買單？我們能否將這些資源在現(xiàn)有租戶之間重新分配？或者說這部分支出應(yīng)該被劃歸負(fù)責(zé)管理云支出的集中IT部門？
使用EKS/Fargate，集中IT部門可以構(gòu)建起多租戶集群，從根本上消除這個惱人的難題。
換言之，他們可以將云賬單中的成本與內(nèi)部用戶一一對應(yīng)起來。
Fargate Pod的大小調(diào)整與資源節(jié)約
以上各個方面當(dāng)然都很重要，而且對于Fargate的業(yè)務(wù)用例而言具有重要意義。但從核心角度出發(fā)，我們真正應(yīng)該關(guān)心的是實(shí)際使用容量與您為之付費(fèi)的容量之間到底存在怎樣的差距。
例如，在嘗試使用Fargate時，很多客戶錯誤地將Fargate Pod容量與傳統(tǒng)工作節(jié)點(diǎn)容量進(jìn)行直接比較。前文已經(jīng)提到，Pod容量屬于容器能夠全部使用的凈容量，而工作節(jié)點(diǎn)容量則是您需要為之付費(fèi)的CPU加內(nèi)存的總?cè)萘俊渲兄挥幸徊糠挚杀挥行в糜谶\(yùn)行容器。
我們也提到過，在傳統(tǒng)Kubernetes集群中，根據(jù)您的實(shí)際業(yè)務(wù)要求與運(yùn)營成熟度，集群中往往有20%到50%的資源被長期閑置。通過使用Fargate，您可以自動將理論容量使用率提升至接近100%，借此大大改善資源浪費(fèi)問題。
當(dāng)然，上述結(jié)論的基本前提，在于假設(shè)您能夠充分利用為Pod分配的全部容量。但很多客戶最終也遇到過EKS Pod資源利用率僅為50%，卻需要為全部容量付費(fèi)的情況。這個時候，即使使用Fargate也不會帶來比傳統(tǒng)EC2實(shí)例更好的任何成本效益。正因?yàn)槿绱耍覀儾判枰昂侠碚{(diào)整Pod大小”，這不僅將直接決定您的實(shí)際運(yùn)營效能，同時也是對Amazon Compute Savings Plans優(yōu)惠政策的良好補(bǔ)充。
下面，我們詳細(xì)聊聊如何正確調(diào)整Kubernetes容器的大小。
在傳統(tǒng)Kubernetes集群之上，工作節(jié)點(diǎn)就是最基本的計算單元。這些基本單元定義了各Pod所能使用的總?cè)萘恳约凹旱恼w運(yùn)行成本。以此為基礎(chǔ)，我們建議大家充分使用作為可選功能的Kubernetes請求限制選項(xiàng)。在容器之上設(shè)置CPU請求限制以及內(nèi)存請求限制之后，相關(guān)設(shè)置將為容器定義虛擬資源沙箱。而如果不在Pod上設(shè)置這些參數(shù)，則所有Pod都將爭用當(dāng)前可用的集群總資源（特別是所處工作節(jié)點(diǎn)上的資源）。
在EKS/Fargate上，使用的則是另外一套完全不同的資源模型。由于集群中不存在工作節(jié)點(diǎn)，因此Pod本身的大小將直接決定必要的底層容量。要有效使用Fargate服務(wù)，就必須要正確對Pod大小做出設(shè)置。正因?yàn)槿绱?，正確配置Pod才成為實(shí)現(xiàn)良好性能、避免資源浪費(fèi)的必要前提。
您可以參閱此份說明文檔中的對應(yīng)部分，或者觀看EKS/Fargate re:Invent突破性講解，以了解在Fargate部署中設(shè)定Kubernetes容器大小的更多詳細(xì)信息。總結(jié)來講，其中的基本邏輯就是讀取各個容器中的“請求”，而后應(yīng)用這些資料中提出的資源分配方法。
另外，您所指定的Pod大?。ㄍㄟ^顯式請求實(shí)現(xiàn)）還應(yīng)高度契合您的工作負(fù)載模式。在理想情況下，我們需要盡可能充分運(yùn)用所指定的資源容量。而要保證這一點(diǎn)，大家必須持續(xù)監(jiān)控Pod的資源利用率指標(biāo)。您可以使用Datadog等工具（為EKS/Fargate提供開箱支持）監(jiān)控各個Pod，也可以使用本文中推薦的Prometheus與Grafana實(shí)施監(jiān)控。
請注意，運(yùn)行在EKS/Fargate上的各Pod能夠全面支持Kubernetes橫向autoscaler與縱向autoscaler。開發(fā)人員可以使用前者根據(jù)工作負(fù)載增加及減少Pod數(shù)量，并使用后者提升或削減分配給特定Pod的資源總量。不過二者之間無法良好協(xié)同，因此如果您希望讓Kubernetes自動調(diào)整各Pod的大小，只能根據(jù)實(shí)際資源消費(fèi)模式二選其一?？傊覀兊哪繕?biāo)非常明確——盡可能將已分配資源的利用率提升至100%，一切措施都應(yīng)為這項(xiàng)目標(biāo)服務(wù)。
總結(jié)
在本文中，我們介紹了一項(xiàng)新功能，可幫助EKS客戶在使用Fargate部署Kubernetes Pod時充分享受AmazonCompute Savings Plans帶來的優(yōu)惠政策。之前，只有通過Amazon ECS啟動的Fargate任務(wù)才有資格享受AmazonCompute Savings Plans折扣。另外，我們還借此機(jī)會討論了EKS/Fargate組合提出的價值主張，特別是如何運(yùn)用無服務(wù)器方法顯著降低業(yè)務(wù)體系的總體擁有成本（TCO）。
另外需要強(qiáng)調(diào)的是，F(xiàn)argate并不是適用于一切應(yīng)用場景的萬靈藥。在很多情況下，客戶仍然有理由繼續(xù)使用傳統(tǒng)EC2實(shí)例，例如需要特定硬件支持（如GPU）或選擇特定實(shí)例類型進(jìn)行微調(diào)部署等。除此之外，使用Fargate進(jìn)行EKS部署時還應(yīng)關(guān)注其他一些注意事項(xiàng)以及一些可能不適合Farget的案例場景。
AWS
專欄
閩公網(wǎng)安備 35010202001226號
