通過EKS、Fargate與Amazon Compute Savings Plans降低Pod單位使用成本

在Re:Invent 2019大會上，我們公布了可以在Amazon Elastic Kubernetes Service（Amazon EKS）上使用Amazon Fargate來部署Kubernetes Pod的全新功能。因為我們看到客戶快速接受使用Kubernetes API的方式將Pod部署在用于運行容器的Amazon無服務器基礎設服務施Fargate當中。這種全新實踐幫助他們徹底擺脫了由Kubernetes集群維護工作帶來的沉重負擔，包括與之相關的管理、修復、安全、隔離與擴展等日常任務。

如果大家希望了解關于Amazon EKS與Fargate協同運作的更多詳細信息，請參閱我在re:Invent大會上的分組討論內容。

在此之前，Amazon Fargate雖然一直歸屬于Amazon Compute Savings Plan節(jié)約計劃的范圍之內，但只適用于運行在ECS上的任務上。今天，我們宣布在Fargate上運行的EKS Pod也將被納入Amazon Compute Savings Plans之內。您可以參閱What’s New公告帖以了解更多詳細信息。如果您已經激活了Compute Savings Plan，那么無需任何額外操作，系統(tǒng)會根據您的Saving Plan為Fargate Pod提供相應折扣。如果您還沒有激活Compute Savings Plan，不妨首先閱讀我們發(fā)布的Amazon Compute Savings Plan常見問題，逐步了解該如何讓自己的運營體系獲得價格優(yōu)惠。只要客戶承諾在一年或三年周期內保持穩(wěn)定的計算資源使用量，即可節(jié)約最高52%的Fargate使用成本。

Compute Savings Plans面向的不僅僅限定于某一項特定技術。Compute Savings Plans靈活性極高，能夠為您實際選用的多種計算服務提供價格優(yōu)惠。例如，您可以選擇EC2、Fargate或Lambda。如果選擇Fargate，則可在ECS與EKS之間自由使用您所熟悉的編排方案。無論如何選擇，Compute Savings Plans都將為您帶來可觀的價格折扣。

Compute Savings Plans是將EKS與Fargate結合起來，進而降低并優(yōu)化成本的最直接、最具實效的方法之一。在今天的博文中，我們將概括并總結當Farget和傳統(tǒng)EC2集群對比時需要考慮的一些點。

AMAZON Fargate使用成本詳解

有時候，客戶會將Fargate計算成本與EC2計算成本進行比較。這里我們舉個簡單的例子，在us-east-1區(qū)域內選擇m5.large Linux按需實例（包含2個vCPU與8 GB內存）和同等配置的Fargate作為比較對象。截至目前，此EC2實例的運行成本為每小時0.096美元。而在同一區(qū)域中，Fargate的計算成本可通過以下公式計算得出：(0.04048美元x 2 vCPU)+(0.004445美元x 8GB)=0.08096+0.03556=0.11652美元/小時。

但需要強調的是，Fargate使用混合EC2實例類型集群，其性能可能與最新一代EC2實例（例如m5或c5家族）有所不同。因此，盡管以上示例體現的是Fargate成本僅比EC2高出20%的最理想狀況，但考慮到實例之內的代際更迭，實際性價比結論可能還將受到影響。這里建議大家根據特定設置進行測試，并充分考慮自己的實際需求。我們一直在推動Fargate底層計算資源的更新，致力于幫助客戶消除這種性能差異及資源不統(tǒng)一問題。

如前文所述，在Fargate上啟動EKS Pod此前并不在Compute Savings Plans節(jié)約計劃的范圍之內。因此在考慮Compute Savings Plans給EC2實例帶來的折扣之后，Fargate與EC2實例成本之間的差距將更加明顯。但在此次公告中，我們將EKS/Fargate組合正式納入Compute Savings Plans，這不僅縮小了Fargate與EC2實例之間的成本差距，同時也保證選擇不同購買模式的客戶都能享受到這一重要優(yōu)惠。

另外需要強調的是，準確比較的前提應該是對整體情況的確切考量。在使用Fargate的情況下，我們不僅幫助客戶承擔起大量管理負擔，同時也消除了傳統(tǒng)虛擬機集群中常見的資源閑置或未能充分使用等問題。再有，AMAZON的基礎設施規(guī)模極為龐大，由此帶來的規(guī)模經濟效應足以在同等配置條件下為客戶帶來遠超本地基礎設施的成本優(yōu)勢。這也是我們?yōu)閿蛋偃f客戶服務的同時，建立起的一種獨特優(yōu)勢。

Amazon Fargate的價值與隱性運營成本

使用托管服務的一大核心收益，在于客戶能夠將自己的時間與精力從無差別性的繁重工作當中解放出來。Fargate同樣提供這樣的收益，可幫助客戶擺脫基礎設施運營及維護相關的煩惱，將更多精力集中在應用程序構建與業(yè)務成果實現身上。

下面，我們將整理出一份粗略的全面清單，列出您選擇使用Fargate等托管服務時無需繼續(xù)關注的傳統(tǒng)問題。這些問題都有著相應的“擁有成本”，屬于同“購置成本”并行存在的重要因素。

安全性

雖然容器技術在隔離與應用程序依賴項打包（即容器鏡像）方面擁有著無可比擬的價值，但其帶來的運行時隔離與安全性保障能力卻不及傳統(tǒng)虛擬機。最典型的就是“容器逃逸”問題，即惡意用戶可能在控制主機之后，訪問運行在同一主機上的所有其他容器。

大家當然可以使用各類技術緩解這些問題，包括創(chuàng)建單獨的主機區(qū)域以運行高度敏感的工作負載、在容器配置當中強制要求只能以非root用戶身份運行等等。在實際使用中，一部分用戶寄希望于Kubernetes提供的高級配置，包括使用污點與容忍機制，或者親和與反親和規(guī)則等。但這一切都會帶來額外的復雜性，導致基礎設施優(yōu)化水平下降或運營負擔增加，最終拉升運營成本。Fargate則通過為任何給定Pod分配專用的、大小合適的虛擬機，從根本上解決了這個問題。在任意時間點上，兩個Pod都絕對不會同時運行在同一虛擬機之上。借助Fargate，您可以在享受容器技術打包與靈活性優(yōu)勢的同時，繼續(xù)保持虛擬機代碼運行硬邊界所帶來的安全優(yōu)勢。另外，運行在Fargate上的各Kubernetes Pod并不共享同一操作系統(tǒng)，因此容器逃逸問題將得到很好的控制。

此外，同樣需要指出的是，Fargate臨時存儲會默認進行加密，用戶無需執(zhí)行任何額外配置即可獲得安全保障。

總體而言，Fargate推動了AMAZON責任分攤模型的普及。在使用Fargate的場景下，AMAZON負責承擔與安全相關的運營任務，例如對用于運行各Pod的虛擬機操作系統(tǒng)進行更新等。這里建議大家參閱Amazon EKS安全最佳實踐指南，其中詳盡闡述了使用EC2與Fargate運行Kubernetes Pod時在安全性方面的一些差別。

合規(guī)性

在受到嚴格監(jiān)管的行業(yè)中，客戶往往需要投入大量時間以保證所運行的技術棧符合合規(guī)性要求。無論是ISO合規(guī)性、HIPAA合規(guī)性、PCI合規(guī)性還是其他類型的合規(guī)要求，都會給客戶的日常運營帶來沉重負擔，特別是合規(guī)性自證報告所帶來的高昂人力與時間成本。而使用Amazon Fargate等托管服務的一項核心優(yōu)勢，在于您可以將合規(guī)保障任務交由亞馬遜云科技處理，因此只需要向審計人員提供特定服務的亞馬遜云科技相關合規(guī)文檔。另一種解決選項則是使用經典的計算資源（例如Amazon EC2），并投入額外的時間與資金以保證其設置符合要求（并正確加以記錄）。截至本文撰稿時，大多數Fargate合規(guī)性認證已經適用于運行在Fargate之上的ECS實例。我們也在努力將認證覆蓋范圍擴展到EKS/Fargate，請大家持續(xù)關注AMAZON合規(guī)性文檔以了解最新進展。

AMI管理

去年，我們正式推出了EKS托管節(jié)點組，旨在減輕Kubernetes工作節(jié)點所帶來的管理負擔。托管節(jié)點仍然運行在您的亞馬遜云科技賬戶之內，并由您承擔節(jié)點的保護與修復責任；盡管亞馬遜云科技將為您提供經過更新的AMI（Amazon Machine Imagine）以替換各工作節(jié)點，借此簡化運營流程。您仍將保留對這些實例的root訪問權限，而EKS則協助處理生命周期管理工作，因此這種新機制并不屬于亞馬遜云科技完全托管方案。與這種托管節(jié)點不同，在使用Fargate時，亞馬遜云科技將包攬所有運營任務，您不必插手AMI或底層主機操作系統(tǒng)修復等事務。同樣的，使用Fargate時亞馬遜云科技將保證您的每一個新Pod都運行在經過完全修復及強化的基礎設施之上。換言之，您無需考慮應該在運行Pod的節(jié)點上使用哪種AMI。

這里需要強調的是，即使是在托管狀態(tài)下，節(jié)點更新仍然需要通過滾動部署新的AMI來實現。而這種操作方式會給Pod帶來影響，因為Pod會在節(jié)點終止之前發(fā)送一條終止信號以撤出當前節(jié)點。對于純橫向擴展及無狀態(tài)應用程序來說，這項操作一般不會構成問題，但其他類型的應用程序，當基礎設施經歷滾動更新時，是有可能因此受到沖擊的。對于一般每30天定期進行一波AMI輪替的金融機構而言，這種滾動部署有可能給日常運營帶來額外負擔。

通用K8s工作節(jié)點管理

除了AMI管理之外，結合前文所述，大家還需要考慮通用工作節(jié)點管理及其相應成本問題。在使用托管節(jié)點與自動規(guī)模伸縮組（ASG）時，雖然您的運營工作量將得到顯著削減，但仍需要在實例之上運行Kubernetes生態(tài)系統(tǒng)提供的多種工具以實現適當的基礎設施操作。以節(jié)點問題檢測器為例，雖然其占用的資源不算很多，但在運營用于支持Pod的基礎設施時，該檢測器仍然會增加你的工作量。

使用Fargate，基礎設施的管理工作將完全歸于亞馬遜云科技?；A設施將定期接收更新；在啟動Pod時，亞馬遜云科技會在全新虛擬機中預先部署全部最新軟件版本，以保證Pod始終在最新技術棧內啟動。

Cluster Autoscaler

Cluster Autoscaler(CA)是一款常用的Kubernetes插件，用于根據集群中所運行Pod的負載情況，對工作節(jié)點進行縱向規(guī)模伸縮調整。CA提供多種豐富功能，但也可能會令您的運營體系變得更加復雜。例如，用于確定何時向集群中添加節(jié)點、以及何時刪除節(jié)點的整個配置，會極大影響到集群的運行成本。建議大家參閱CA常見問題解答以了解其中配置的豐富度與靈活性。此外，您也可以點擊此處查看用于調整CA運行方式的受支持參數清單。

當CA確定應執(zhí)行規(guī)?？s減操作時，大家同樣需要考慮其對Pod運行造成的影響。運行在待擴展節(jié)點上的原有Pod將被逐出，并在其他節(jié)點上重新啟動。這部分內容，請參閱常見問題解答部分?？傊鶕鄳狿od的實際作用，這種情況有可能破壞業(yè)務的正常運轉，且對不完全無狀態(tài)類應用的影響尤其明顯。

使用Fargate，您將不再需要CA，因此上述問題也將不復存在。配合Fargate，每個容器都將在大小合適的虛擬機上啟動并運行，且該虛擬機的生命周期與容器本身完全相同。由于不涉及節(jié)點，因此我們無需執(zhí)行任何集群擴展操作。

工作節(jié)點的大小調整與可用容量

您的Kubernetes Pod通常需要運行在一組EC2實例之上，而這些實例也決定了集群的總體容量。但是，選擇合適的實例大小并非易事。同樣的，由于單一節(jié)點組僅支持單一實例類型，因此只選擇特定的實例大小也有可能導致容量失衡。我們當然可以使用Cluster Autoscaler跨越多個不同節(jié)點組實施管理，借此優(yōu)化資源容量；但這無疑也會增加集群設置的復雜程度。使用Fargate，每個Pod都將運行在大小合適的虛擬機上，您只需要為Pod運行當中實際消耗的資源量付費。實例大小、類型或者實例資源利用率，這一切從此與您無關。

節(jié)點大小調整中的另一項重要工作，在于平衡Pod可支配容量與主機規(guī)定總容量之間的關系。如果您的工作節(jié)點擁有8 GB內存，那么其中只有一部分可用于運行實際應用程序。例如，您需要為操作系統(tǒng)本體中運行的部分服務保留資源，為Kubelet保留資源，還需要為Kubernetes逐出操作的閾值觸發(fā)器保留資源?？傮w而言，這些“系統(tǒng)預留”資源一般會占到主機總資源量的10%到30%。這里推薦另一篇說明文章，其中列出了部分系統(tǒng)預留容量示例。再有，如果需要從節(jié)點中逐出部分負載，大家還需要考慮如何對工作負載進行優(yōu)先級分類及排序。從這個角度來看，我們顯然無法簡單將主機的總體容量數值除以單一Pod的資源需求量，由此粗暴計算出其上所能承載的Pod總數。即使不考慮這些“系統(tǒng)預留”，主機上同樣有可能存在其他固有的效率低下因素。但在Fargate方面，除了Kubelet之外，所有資源都可供Fargate充分使用，且您只需要按Fargate的凈使用資源付費。稍后我們將進一步討論這個話題。

除了設計層面帶來的系統(tǒng)預留資源量外，很多客戶還傾向于人為對集群進行過度配置。這樣做當然有其道理，包括通過Cluster Autoscaler的豐富功能選項對Pod進行快速擴展，借此實現更高的可用性。從本質上講，這意味著提醒CA在未來添加或刪除某些Pod時，可能需要隨之調整集群大小。這種方式雖然帶來了充分的靈活性，但同時也會引發(fā)額外的基礎設施成本，導致大家為實際上并未用到的容量（至少沒有充分使用）付費。

成本追溯

相當一部分EKS客戶使用的是多租戶集群。因此，對于集中IT團隊而言，必須能夠在不同內部用戶（即各集群租戶）之間明確劃分成本歸屬。但這里存在著嚴重的斷層。EKS集群管理員使用的成本單位是作為工作節(jié)點的實例類型，而EKS集群用戶的成本單位則是其當前運行的一個個Pod。不少客戶只能通過跟蹤“誰用了什么”來實現資源使用成本的規(guī)范化追溯。但出于種種原因，這種處理方式相當復雜且難以實現。Kubernetes容器并非亞馬遜云科技中的第一類對象，因此我們無法使用原生亞馬遜云科技成本分配機制對容器開展追蹤。

因此，客戶經常會使用第三方工具以跟蹤資源使用情況，并據此生成成本追溯報告。但是，這些工具很難回答另一個同樣重要的問題：誰該為未經實際使用的資源付費？如前所述，您的集群很可能從未以100%的利用率運行過。結合實際經歷，大多數集群可能長期處于利用率不足50%的狀態(tài)。雖然一部分客戶會投入大量時間與工程資源對這些集群進行調優(yōu)，但即使如此其資源利用率也幾乎不可能超過80%。這些數字背后并無特定的科學依據，主要源自我們與客戶之間的交流與總結。根據以上的分歧，造成了一些問題，例如誰該為這部分20%或者50%的閑置資源買單？我們能否將這些資源在現有租戶之間重新分配？或者說這部分支出應該被劃歸負責管理云支出的集中IT部門？

使用EKS/Fargate，集中IT部門可以構建起多租戶集群，從根本上消除這個惱人的難題。

換言之，他們可以將云賬單中的成本與內部用戶一一對應起來。

Fargate Pod的大小調整與資源節(jié)約

以上各個方面當然都很重要，而且對于Fargate的業(yè)務用例而言具有重要意義。但從核心角度出發(fā)，我們真正應該關心的是實際使用容量與您為之付費的容量之間到底存在怎樣的差距。

例如，在嘗試使用Fargate時，很多客戶錯誤地將Fargate Pod容量與傳統(tǒng)工作節(jié)點容量進行直接比較。前文已經提到，Pod容量屬于容器能夠全部使用的凈容量，而工作節(jié)點容量則是您需要為之付費的CPU加內存的總容量——但其中只有一部分可被有效用于運行容器。

我們也提到過，在傳統(tǒng)Kubernetes集群中，根據您的實際業(yè)務要求與運營成熟度，集群中往往有20%到50%的資源被長期閑置。通過使用Fargate，您可以自動將理論容量使用率提升至接近100%，借此大大改善資源浪費問題。

當然，上述結論的基本前提，在于假設您能夠充分利用為Pod分配的全部容量。但很多客戶最終也遇到過EKS Pod資源利用率僅為50%，卻需要為全部容量付費的情況。這個時候，即使使用Fargate也不會帶來比傳統(tǒng)EC2實例更好的任何成本效益。正因為如此，我們才需要“合理調整Pod大小”，這不僅將直接決定您的實際運營效能，同時也是對Amazon Compute Savings Plans優(yōu)惠政策的良好補充。

下面，我們詳細聊聊如何正確調整Kubernetes容器的大小。

在傳統(tǒng)Kubernetes集群之上，工作節(jié)點就是最基本的計算單元。這些基本單元定義了各Pod所能使用的總容量以及集群的整體運行成本。以此為基礎，我們建議大家充分使用作為可選功能的Kubernetes請求限制選項。在容器之上設置CPU請求限制以及內存請求限制之后，相關設置將為容器定義虛擬資源沙箱。而如果不在Pod上設置這些參數，則所有Pod都將爭用當前可用的集群總資源（特別是所處工作節(jié)點上的資源）。

在EKS/Fargate上，使用的則是另外一套完全不同的資源模型。由于集群中不存在工作節(jié)點，因此Pod本身的大小將直接決定必要的底層容量。要有效使用Fargate服務，就必須要正確對Pod大小做出設置。正因為如此，正確配置Pod才成為實現良好性能、避免資源浪費的必要前提。

您可以參閱此份說明文檔中的對應部分，或者觀看EKS/Fargate re:Invent突破性講解，以了解在Fargate部署中設定Kubernetes容器大小的更多詳細信息?？偨Y來講，其中的基本邏輯就是讀取各個容器中的“請求”，而后應用這些資料中提出的資源分配方法。

另外，您所指定的Pod大小（通過顯式請求實現）還應高度契合您的工作負載模式。在理想情況下，我們需要盡可能充分運用所指定的資源容量。而要保證這一點，大家必須持續(xù)監(jiān)控Pod的資源利用率指標。您可以使用Datadog等工具（為EKS/Fargate提供開箱支持）監(jiān)控各個Pod，也可以使用本文中推薦的Prometheus與Grafana實施監(jiān)控。

請注意，運行在EKS/Fargate上的各Pod能夠全面支持Kubernetes橫向autoscaler與縱向autoscaler。開發(fā)人員可以使用前者根據工作負載增加及減少Pod數量，并使用后者提升或削減分配給特定Pod的資源總量。不過二者之間無法良好協同，因此如果您希望讓Kubernetes自動調整各Pod的大小，只能根據實際資源消費模式二選其一?？傊?，我們的目標非常明確——盡可能將已分配資源的利用率提升至100%，一切措施都應為這項目標服務。

總結

在本文中，我們介紹了一項新功能，可幫助EKS客戶在使用Fargate部署Kubernetes Pod時充分享受AmazonCompute Savings Plans帶來的優(yōu)惠政策。之前，只有通過Amazon ECS啟動的Fargate任務才有資格享受AmazonCompute Savings Plans折扣。另外，我們還借此機會討論了EKS/Fargate組合提出的價值主張，特別是如何運用無服務器方法顯著降低業(yè)務體系的總體擁有成本（TCO）。

另外需要強調的是，Fargate并不是適用于一切應用場景的萬靈藥。在很多情況下，客戶仍然有理由繼續(xù)使用傳統(tǒng)EC2實例，例如需要特定硬件支持（如GPU）或選擇特定實例類型進行微調部署等。除此之外，使用Fargate進行EKS部署時還應關注其他一些注意事項以及一些可能不適合Farget的案例場景。