如何立足AWS對(duì)Amazon EKS進(jìn)行成本優(yōu)化？這四種方式，輕松又高效！

你知道最值得信賴的

運(yùn)行Kubernetes的方式是什么嗎？

嘿嘿，小編今天就來為你介紹一項(xiàng)

完全托管的Kubernetes服務(wù)

Amazon Elastic Kubernetes Service

(Amazon EKS)

那么該如何立足Amazon Web Services(AWS)

對(duì)Amazon EKS進(jìn)行成本優(yōu)化呢？

本文將為您提供一些建議

幫助您以更節(jié)省、更高效地方式

在Amazon EKS中運(yùn)行Kubernetes工作負(fù)載

將Amazon Elastic Kubernetes Service(Amazon EKS)提供的全托管Kubernetes控制平面，與運(yùn)行在Amazon EC2上彈性的Kubernetes工作節(jié)點(diǎn)組合起來，就構(gòu)成了一套理想的容器化工作負(fù)載運(yùn)行環(huán)境。這不僅使構(gòu)建者能夠快速創(chuàng)建出Kubernetes集群，同時(shí)也能夠按需擴(kuò)展集群，支持靈活多變的業(yè)務(wù)需求。但正確的選擇只是成功的第一步，我們還需要充分考量AWS Well-Architected Framework中提出的成本優(yōu)化支柱原則。

Kubernetes集群的總體運(yùn)行成本涉及了許多服務(wù)，Amazon EKS控制平面是其中最易于理解的部分。接下來，我們還需要有Amazon EC2實(shí)例用作Kubernetes集群的工作節(jié)點(diǎn)。而Amazon EC2實(shí)例的成本涉及多個(gè)方面，除了計(jì)算成本還包括塊存儲(chǔ)與數(shù)據(jù)傳輸兩部分。而這兩項(xiàng)成本與實(shí)際的工作負(fù)載高度相關(guān)，所以本文暫時(shí)不做深入討論。換個(gè)角度，本文將深入研究Amazon EC2成本中最大的兩個(gè)方面：實(shí)例運(yùn)行小時(shí)數(shù)和實(shí)例價(jià)格。

Amazon EC2成本=實(shí)例運(yùn)行小時(shí)數(shù)x實(shí)例價(jià)格

在Kubernetes集群當(dāng)中，實(shí)例運(yùn)行小時(shí)數(shù)與集群內(nèi)的Pod數(shù)量、以及分配給這些Pod的對(duì)應(yīng)資源成正比。

實(shí)例運(yùn)行小時(shí)數(shù)=Pod運(yùn)行小時(shí)數(shù)x Pod對(duì)應(yīng)資源

在本文中，我們將通過一下四種技術(shù)了解如何將Amazon EC2的資源使用成本降低80%甚至更高：

·Auto Scaling（規(guī)模自動(dòng)伸縮）——通過使集群內(nèi)的節(jié)點(diǎn)和pod數(shù)量與需求保持一致，以優(yōu)化實(shí)例運(yùn)行時(shí)間。

·Right Sizing（正確調(diào)整大?。?/strong>——通過為各Pod分配適當(dāng)?shù)腃PU與內(nèi)存資源，以優(yōu)化Pod資源。

·Down Scaling（規(guī)?？s減）——在夜間及周末等非必要時(shí)段關(guān)閉Pod以優(yōu)化Pod運(yùn)行小時(shí)數(shù)。

·Purchase Options（購買選項(xiàng)）——利用競(jìng)價(jià)實(shí)例替代按需實(shí)例，以優(yōu)化實(shí)例價(jià)格。

Auto Scaling（規(guī)模自動(dòng)伸縮）

AWS良好架構(gòu)框架中的成本優(yōu)化支柱，通過專門的章節(jié)討論了“供需匹配”這部分內(nèi)容，相關(guān)建議如下：

“……（供需匹配）可通過Auto Scaling實(shí)現(xiàn)，它可以幫助您根據(jù)定義的條件自動(dòng)擴(kuò)展或縮減Amazon EC2實(shí)例和Spot Fleet的容量。”

因此，在Kubernetes集群上進(jìn)行成本優(yōu)化的先決條件是確保您已經(jīng)在集群之上使用了Cluster Autoscaler。這款工具能夠在Kubernetes集群中執(zhí)行兩項(xiàng)關(guān)鍵功能：

第一，它會(huì)監(jiān)控集群中那些由于資源分配不足而無法正常運(yùn)行的Pod。一旦出現(xiàn)這樣的情況，Cluster Autoscaler都會(huì)自動(dòng)更新Amazon EC2彈性伸縮組，從而在集群當(dāng)中增加一定數(shù)量的節(jié)點(diǎn)。

第二，Cluster Autoscaler會(huì)檢測(cè)資源利用率較低的節(jié)點(diǎn)，并將其中的Pod調(diào)度到其他節(jié)點(diǎn)之上。接下來，Cluster Autoscaler會(huì)自動(dòng)縮減Auto Scaling組所需的節(jié)點(diǎn)數(shù)量，實(shí)現(xiàn)集群規(guī)模縮減。

Amazon EKS用戶指南對(duì)Cluster Autoscaler的使用方式做出了詳盡介紹。在配置Cluster Autoscaler時(shí)，大家需要注意以下幾點(diǎn)：

服務(wù)賬戶的IAM角色——Cluster Autoscaler需要具備對(duì)應(yīng)的訪問權(quán)限，才能更新Auto Scaling組中的必要容量參數(shù)。推薦的方法是根據(jù)所需的策略及信任策略創(chuàng)建一個(gè)新的IAM角色，借此限制Cluster Autoscaler對(duì)于服務(wù)賬戶的訪問權(quán)限。另外，請(qǐng)務(wù)必在服務(wù)賬戶上標(biāo)注該角色的名稱：

apiVersion: v1

kind: ServiceAccount

metadata:

  name: cluster-autoscaler

  annotations:

    eks.amazonaws.com/role-arn: arn:aws:iam::000000000000:role/my_role_name

當(dāng)Cluster Autoscaler進(jìn)行橫向擴(kuò)展時(shí)，它會(huì)直接增加Auto Scaling組內(nèi)的節(jié)點(diǎn)數(shù)量，而啟動(dòng)新Amazon EC2實(shí)例的實(shí)際任務(wù)將由AWS彈性伸縮服務(wù)負(fù)責(zé)執(zhí)行。如果在多個(gè)可用區(qū)內(nèi)都配置了彈性伸縮組，則可以在這些可用區(qū)內(nèi)啟動(dòng)新的實(shí)例。

對(duì)于使用持久存儲(chǔ)卷的部署方案，我們需要在各個(gè)可用區(qū)內(nèi)建立一個(gè)獨(dú)立的Auto Scaling組。這樣，當(dāng)Cluster Autoscaler檢測(cè)到需要對(duì)特定Pod進(jìn)行橫向擴(kuò)展的情況時(shí)，即可根據(jù)當(dāng)前可用區(qū)內(nèi)已經(jīng)存在的持久存儲(chǔ)卷聲明為接下來的擴(kuò)展節(jié)點(diǎn)操作指定正確的可用區(qū)。

在使用多個(gè)Auto Scaling組時(shí)，請(qǐng)確保在Cluster Autoscaler的Pod規(guī)范中啟用以下參數(shù)：

--balance-similar-node-groups=true

到目前位置，Cluster Autoscaler已經(jīng)可以在集群當(dāng)中正常運(yùn)行，實(shí)例運(yùn)行時(shí)間（Instance Hours）也將始終與集群內(nèi)的Pod資源需求量緊密匹配。下一步是根據(jù)特定的Pod指標(biāo)使用Horizontal Pod Autoscaler(HPA)對(duì)Pod數(shù)量進(jìn)行橫向擴(kuò)展或縮減，借此優(yōu)化Pod運(yùn)行小時(shí)數(shù)（Pod Hours）以進(jìn)一步優(yōu)化我們的實(shí)例運(yùn)行小時(shí)數(shù)。

Kubernetes已經(jīng)提供了HPA控制器，因此配置HPA時(shí)只需要考慮一項(xiàng)前提，即確保已經(jīng)將Kubernetes指標(biāo)服務(wù)器部署在您的集群中，然后在您的部署中定義HPA資源。例如，以下定義的HPA資源配置將持續(xù)監(jiān)控名為nginx-ingress-controller的部署的CPU使用率。接下來，HPA將在1到5之間擴(kuò)縮Pod數(shù)量，以確保所有Pod的平均CPU使用率都能達(dá)到80%：

apiVersion: autoscaling/v1

kind: HorizontalPodAutoscaler

metadata:

  name: nginx-ingress-controller

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: nginx-ingress-controller

  minReplicas: 1

  maxReplicas: 5

  targetCPUUtilizationPercentage: 80

把Cluster Autoscaler與Horizontal Pod Autoscaler相結(jié)合，能夠幫助我們將Amazon EC2實(shí)例小時(shí)數(shù)與集群內(nèi)所運(yùn)行工作負(fù)載的資源利用率盡可能統(tǒng)一起來。

Right sizing（正確調(diào)整大?。?/span>

回到AWS良好架構(gòu)框架中的成本優(yōu)化支柱部分，在其中的“成本效益資源”章節(jié)處，對(duì)Right Sizing的定義為：

“……使用成本最低的資源，同時(shí)仍然滿足特定工作負(fù)載的技術(shù)規(guī)格要求。”

使用Kubernetes，我們可以隨時(shí)對(duì)Pod內(nèi)容器的計(jì)算、CPU與內(nèi)存資源進(jìn)行大小調(diào)整，借此找到最合理的配額水平。各個(gè)Pod中的容器對(duì)于所能夠使用的CPU與內(nèi)存資源都有著一定的要求及限制。

請(qǐng)謹(jǐn)慎嘗試，并保證這些資源的實(shí)際使用率與業(yè)務(wù)需求盡量匹配。如果設(shè)定的值太低，則容器可能存在資源不足并影響實(shí)際業(yè)務(wù)性能。而如果設(shè)定的值過高，則會(huì)浪費(fèi)大量資源，導(dǎo)致各容器中都存在一部分未得到使用的資源。在實(shí)際利用率低于資源必要值時(shí)，我們將二者之間的差額稱為閑置成本（slack cost）。

以kube-resource-report為代表的多種工具能夠?qū)﹂e置成本進(jìn)行可視化，同時(shí)正確判斷Pod內(nèi)的容器資源需求。在安裝說明部分，我們可以通過以下helm圖表了解如何安裝這款工具：

$helm upgrade--install kube-resource-report chart/kube-resource-report.

如以上圖所示，像Jenkins這類應(yīng)用能夠顯著降低CPU與內(nèi)存需求，每月可以節(jié)約高達(dá)66.53美元的閑置成本。而在對(duì)Kubernetes集群內(nèi)所有應(yīng)用程序正確調(diào)整Pod資源大小之后，我們實(shí)現(xiàn)了20%的成本節(jié)約，具體如下圖所示。

Down scaling（規(guī)模縮減）

除了根據(jù)需求的自動(dòng)擴(kuò)展之外，AWS良好架構(gòu)框架成本優(yōu)化支柱中的供需匹配章節(jié)還提出以下建議：

“可以安排系統(tǒng)在特定時(shí)間（例如工作日營(yíng)業(yè)時(shí)間開始時(shí)）按預(yù)定義進(jìn)行規(guī)模伸縮，借此保證資源始終與用戶需求相匹配。”

在示例集群中，有相當(dāng)一部分部署方案只需要在營(yíng)業(yè)時(shí)段之內(nèi)運(yùn)行。我們可以將kube-downscaler工具部署在集群上，借此根據(jù)一天中的時(shí)間對(duì)集群資源進(jìn)行規(guī)模伸縮。下面，我們通過環(huán)境變量為kube-downscaler配置默認(rèn)運(yùn)行時(shí)間：

在這種情況下，周一至周五上午5:00至下午7:00以外的所有時(shí)間段，集群所有部署節(jié)點(diǎn)資源大小都將設(shè)置為0。通過annotation標(biāo)注，名稱空間與部署可以根據(jù)業(yè)務(wù)需求來自定義他們的啟停時(shí)間。主要通過設(shè)置downscaler/uptime標(biāo)注來自定義啟停時(shí)間，甚至可以通過設(shè)置downscaler/exclude標(biāo)注來禁用該功能。

如下圖所示：

Amazon CloudWatch–Amazon EC2實(shí)例數(shù)量

Grafana–集群CPU資源使用率

各Amazon EC2實(shí)例在啟用規(guī)?？s減之后，我們可以減少Pod運(yùn)行小時(shí)數(shù)，并借此達(dá)成15%的額外資源節(jié)約比例，具體如下圖所示。

購買選項(xiàng)

AWS良好架構(gòu)框架成本優(yōu)化支柱中的最后一部分為“購買選項(xiàng)”，相關(guān)建議如下：

“競(jìng)價(jià)實(shí)例使您以遠(yuǎn)低于按需Amazon EC2實(shí)例的成本（最高節(jié)約比例達(dá)90%）使用AWS中的備用計(jì)算資源?！?/em>

在Amazon EC2控制臺(tái)中查看競(jìng)價(jià)實(shí)例的價(jià)格歷史記錄時(shí)，我們發(fā)現(xiàn)m5.large類型的競(jìng)價(jià)實(shí)例，在實(shí)際使用成本上始終比按需實(shí)例低55%至60%。

要將您的節(jié)點(diǎn)設(shè)定為在競(jìng)價(jià)實(shí)例（而非按需實(shí)例）上運(yùn)行，請(qǐng)參閱題為《配合Amazon EKS，在Amazon EC2競(jìng)價(jià)實(shí)例上運(yùn)行您的Kubernetes工作負(fù)載（Run your Kubernetes Workloads on Amazon EC2 Spot Instances with Amazon EKS）》的AWS Compute博文。

更多資訊

識(shí)別左側(cè)二維碼即可訪問將節(jié)點(diǎn)

設(shè)定為競(jìng)價(jià)實(shí)例上運(yùn)行的相關(guān)博客

需要注意的是，此文在示例中安裝了kube-spot-termination-notice-handler工具以運(yùn)行自定義終止處理程序。這是一項(xiàng)故障轉(zhuǎn)移功能，用于在競(jìng)價(jià)實(shí)例發(fā)生服務(wù)中斷時(shí)，將各Pod安全轉(zhuǎn)移至其他節(jié)點(diǎn)。

除了由競(jìng)價(jià)實(shí)例組成的Auto Scaling組之外，對(duì)于無法容忍實(shí)例意外中斷的各類Pod，大多數(shù)集群還會(huì)為其保留一套由按需實(shí)例構(gòu)成的Auto Scaling組。在配置這些節(jié)點(diǎn)時(shí)，請(qǐng)注意向各Auto Scaling組內(nèi)的kubelet傳遞額外參數(shù)，借此將各節(jié)點(diǎn)標(biāo)記為essential或者preemptible：

Essential:--node-labels=kubernetes.io/lifecycle=essential

Preemptible:--node-labels=kubernetes.io/lifecycle=preemptible

接下來，我們可以在容器規(guī)范中使用node affinity，以確保在適當(dāng)?shù)墓?jié)點(diǎn)上調(diào)度容器：

affinity:

nodeAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

-matchExpressions:

-key:"kubernetes.io/lifecycle"

operator:"In"

values:

-essential

在將大多數(shù)節(jié)點(diǎn)轉(zhuǎn)移至競(jìng)價(jià)實(shí)例之后，我們能夠降低實(shí)例的運(yùn)行成本，實(shí)現(xiàn)了40%的額外費(fèi)用節(jié)約，如下圖所示。請(qǐng)注意，面向競(jìng)價(jià)實(shí)例的轉(zhuǎn)移不會(huì)對(duì)使用方式造成影響，只是大幅降低了資源使用費(fèi)率。

總結(jié)

通過自動(dòng)擴(kuò)縮集群中節(jié)點(diǎn)及Pod，正確調(diào)整分配給Pod中容器的資源的大小，縮減業(yè)務(wù)時(shí)段以外的部署規(guī)模，并將大部分Pod轉(zhuǎn)移至競(jìng)價(jià)實(shí)例，能夠?yàn)镵ubernetes集群節(jié)省超過80％的Amazon EC2實(shí)例成本。這四種重要的方式，均來自AWS良好架構(gòu)構(gòu)架中成本優(yōu)化支柱原則所提到的最佳實(shí)踐。事實(shí)也再次證明，這些建議確實(shí)能夠幫助客戶以更節(jié)省和更高效地方式在Amazon EKS中運(yùn)行Kubernetes工作負(fù)載。