你知道最值得信賴的
運行Kubernetes的方式是什么嗎？
嘿嘿，小編今天就來為你介紹一項
完全托管的Kubernetes服務
Amazon Elastic Kubernetes Service
(Amazon EKS)
那么該如何立足Amazon Web Services(AWS)
對Amazon EKS進行成本優(yōu)化呢？
本文將為您提供一些建議
幫助您以更節(jié)省、更高效地方式
在Amazon EKS中運行Kubernetes工作負載
將Amazon Elastic Kubernetes Service(Amazon EKS)提供的全托管Kubernetes控制平面，與運行在Amazon EC2上彈性的Kubernetes工作節(jié)點組合起來，就構成了一套理想的容器化工作負載運行環(huán)境。這不僅使構建者能夠快速創(chuàng)建出Kubernetes集群，同時也能夠按需擴展集群，支持靈活多變的業(yè)務需求。但正確的選擇只是成功的第一步，我們還需要充分考量AWS Well-Architected Framework中提出的成本優(yōu)化支柱原則。
Kubernetes集群的總體運行成本涉及了許多服務，Amazon EKS控制平面是其中最易于理解的部分。接下來，我們還需要有Amazon EC2實例用作Kubernetes集群的工作節(jié)點。而Amazon EC2實例的成本涉及多個方面，除了計算成本還包括塊存儲與數(shù)據(jù)傳輸兩部分。而這兩項成本與實際的工作負載高度相關，所以本文暫時不做深入討論。換個角度，本文將深入研究Amazon EC2成本中最大的兩個方面：實例運行小時數(shù)和實例價格。
Amazon EC2成本=實例運行小時數(shù)x實例價格
在Kubernetes集群當中，實例運行小時數(shù)與集群內的Pod數(shù)量、以及分配給這些Pod的對應資源成正比。
實例運行小時數(shù)=Pod運行小時數(shù)x Pod對應資源
在本文中，我們將通過一下四種技術了解如何將Amazon EC2的資源使用成本降低80%甚至更高：
·Auto Scaling（規(guī)模自動伸縮）——通過使集群內的節(jié)點和pod數(shù)量與需求保持一致，以優(yōu)化實例運行時間。
·Right Sizing（正確調整大?。?/strong>——通過為各Pod分配適當?shù)腃PU與內存資源，以優(yōu)化Pod資源。
·Down Scaling（規(guī)模縮減）——在夜間及周末等非必要時段關閉Pod以優(yōu)化Pod運行小時數(shù)。
·Purchase Options（購買選項）——利用競價實例替代按需實例，以優(yōu)化實例價格。
Auto Scaling（規(guī)模自動伸縮）
AWS良好架構框架中的成本優(yōu)化支柱，通過專門的章節(jié)討論了“供需匹配”這部分內容，相關建議如下：
“……（供需匹配）可通過Auto Scaling實現(xiàn)，它可以幫助您根據(jù)定義的條件自動擴展或縮減Amazon EC2實例和Spot Fleet的容量?！?/em>
因此，在Kubernetes集群上進行成本優(yōu)化的先決條件是確保您已經(jīng)在集群之上使用了Cluster Autoscaler。這款工具能夠在Kubernetes集群中執(zhí)行兩項關鍵功能：
第一，它會監(jiān)控集群中那些由于資源分配不足而無法正常運行的Pod。一旦出現(xiàn)這樣的情況，Cluster Autoscaler都會自動更新Amazon EC2彈性伸縮組，從而在集群當中增加一定數(shù)量的節(jié)點。
第二，Cluster Autoscaler會檢測資源利用率較低的節(jié)點，并將其中的Pod調度到其他節(jié)點之上。接下來，Cluster Autoscaler會自動縮減Auto Scaling組所需的節(jié)點數(shù)量，實現(xiàn)集群規(guī)?？s減。
Amazon EKS用戶指南對Cluster Autoscaler的使用方式做出了詳盡介紹。在配置Cluster Autoscaler時，大家需要注意以下幾點：
服務賬戶的IAM角色——Cluster Autoscaler需要具備對應的訪問權限，才能更新Auto Scaling組中的必要容量參數(shù)。推薦的方法是根據(jù)所需的策略及信任策略創(chuàng)建一個新的IAM角色，借此限制Cluster Autoscaler對于服務賬戶的訪問權限。另外，請務必在服務賬戶上標注該角色的名稱：
apiVersion: v1
kind: ServiceAccount
metadata:
name: cluster-autoscaler
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::000000000000:role/my_role_name
當Cluster Autoscaler進行橫向擴展時，它會直接增加Auto Scaling組內的節(jié)點數(shù)量，而啟動新Amazon EC2實例的實際任務將由AWS彈性伸縮服務負責執(zhí)行。如果在多個可用區(qū)內都配置了彈性伸縮組，則可以在這些可用區(qū)內啟動新的實例。
對于使用持久存儲卷的部署方案，我們需要在各個可用區(qū)內建立一個獨立的Auto Scaling組。這樣，當Cluster Autoscaler檢測到需要對特定Pod進行橫向擴展的情況時，即可根據(jù)當前可用區(qū)內已經(jīng)存在的持久存儲卷聲明為接下來的擴展節(jié)點操作指定正確的可用區(qū)。
在使用多個Auto Scaling組時，請確保在Cluster Autoscaler的Pod規(guī)范中啟用以下參數(shù)：
--balance-similar-node-groups=true
到目前位置，Cluster Autoscaler已經(jīng)可以在集群當中正常運行，實例運行時間（Instance Hours）也將始終與集群內的Pod資源需求量緊密匹配。下一步是根據(jù)特定的Pod指標使用Horizontal Pod Autoscaler(HPA)對Pod數(shù)量進行橫向擴展或縮減，借此優(yōu)化Pod運行小時數(shù)（Pod Hours）以進一步優(yōu)化我們的實例運行小時數(shù)。
Kubernetes已經(jīng)提供了HPA控制器，因此配置HPA時只需要考慮一項前提，即確保已經(jīng)將Kubernetes指標服務器部署在您的集群中，然后在您的部署中定義HPA資源。例如，以下定義的HPA資源配置將持續(xù)監(jiān)控名為nginx-ingress-controller的部署的CPU使用率。接下來，HPA將在1到5之間擴縮Pod數(shù)量，以確保所有Pod的平均CPU使用率都能達到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相結合，能夠幫助我們將Amazon EC2實例小時數(shù)與集群內所運行工作負載的資源利用率盡可能統(tǒng)一起來。
Right sizing（正確調整大小）
回到AWS良好架構框架中的成本優(yōu)化支柱部分，在其中的“成本效益資源”章節(jié)處，對Right Sizing的定義為：
“……使用成本最低的資源，同時仍然滿足特定工作負載的技術規(guī)格要求。”
使用Kubernetes，我們可以隨時對Pod內容器的計算、CPU與內存資源進行大小調整，借此找到最合理的配額水平。各個Pod中的容器對于所能夠使用的CPU與內存資源都有著一定的要求及限制。
請謹慎嘗試，并保證這些資源的實際使用率與業(yè)務需求盡量匹配。如果設定的值太低，則容器可能存在資源不足并影響實際業(yè)務性能。而如果設定的值過高，則會浪費大量資源，導致各容器中都存在一部分未得到使用的資源。在實際利用率低于資源必要值時，我們將二者之間的差額稱為閑置成本（slack cost）。
以kube-resource-report為代表的多種工具能夠對閑置成本進行可視化，同時正確判斷Pod內的容器資源需求。在安裝說明部分，我們可以通過以下helm圖表了解如何安裝這款工具：
$helm upgrade--install kube-resource-report chart/kube-resource-report.
如以上圖所示，像Jenkins這類應用能夠顯著降低CPU與內存需求，每月可以節(jié)約高達66.53美元的閑置成本。而在對Kubernetes集群內所有應用程序正確調整Pod資源大小之后，我們實現(xiàn)了20%的成本節(jié)約，具體如下圖所示。
Down scaling（規(guī)?？s減）
除了根據(jù)需求的自動擴展之外，AWS良好架構框架成本優(yōu)化支柱中的供需匹配章節(jié)還提出以下建議：
“可以安排系統(tǒng)在特定時間（例如工作日營業(yè)時間開始時）按預定義進行規(guī)模伸縮，借此保證資源始終與用戶需求相匹配。”
在示例集群中，有相當一部分部署方案只需要在營業(yè)時段之內運行。我們可以將kube-downscaler工具部署在集群上，借此根據(jù)一天中的時間對集群資源進行規(guī)模伸縮。下面，我們通過環(huán)境變量為kube-downscaler配置默認運行時間：
在這種情況下，周一至周五上午5:00至下午7:00以外的所有時間段，集群所有部署節(jié)點資源大小都將設置為0。通過annotation標注，名稱空間與部署可以根據(jù)業(yè)務需求來自定義他們的啟停時間。主要通過設置downscaler/uptime標注來自定義啟停時間，甚至可以通過設置downscaler/exclude標注來禁用該功能。
如下圖所示：
Amazon CloudWatch–Amazon EC2實例數(shù)量
Grafana–集群CPU資源使用率
各Amazon EC2實例在啟用規(guī)?？s減之后，我們可以減少Pod運行小時數(shù)，并借此達成15%的額外資源節(jié)約比例，具體如下圖所示。
購買選項
AWS良好架構框架成本優(yōu)化支柱中的最后一部分為“購買選項”，相關建議如下：
“競價實例使您以遠低于按需Amazon EC2實例的成本（最高節(jié)約比例達90%）使用AWS中的備用計算資源。”
在Amazon EC2控制臺中查看競價實例的價格歷史記錄時，我們發(fā)現(xiàn)m5.large類型的競價實例，在實際使用成本上始終比按需實例低55%至60%。
要將您的節(jié)點設定為在競價實例（而非按需實例）上運行，請參閱題為《配合Amazon EKS，在Amazon EC2競價實例上運行您的Kubernetes工作負載（Run your Kubernetes Workloads on Amazon EC2 Spot Instances with Amazon EKS）》的AWS Compute博文。
更多資訊
識別左側二維碼即可訪問將節(jié)點
設定為競價實例上運行的相關博客
需要注意的是，此文在示例中安裝了kube-spot-termination-notice-handler工具以運行自定義終止處理程序。這是一項故障轉移功能，用于在競價實例發(fā)生服務中斷時，將各Pod安全轉移至其他節(jié)點。
除了由競價實例組成的Auto Scaling組之外，對于無法容忍實例意外中斷的各類Pod，大多數(shù)集群還會為其保留一套由按需實例構成的Auto Scaling組。在配置這些節(jié)點時，請注意向各Auto Scaling組內的kubelet傳遞額外參數(shù)，借此將各節(jié)點標記為essential或者preemptible：
Essential:--node-labels=kubernetes.io/lifecycle=essential
Preemptible:--node-labels=kubernetes.io/lifecycle=preemptible
接下來，我們可以在容器規(guī)范中使用node affinity，以確保在適當?shù)墓?jié)點上調度容器：
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
-matchExpressions:
-key:"kubernetes.io/lifecycle"
operator:"In"
values:
-essential
在將大多數(shù)節(jié)點轉移至競價實例之后，我們能夠降低實例的運行成本，實現(xiàn)了40%的額外費用節(jié)約，如下圖所示。請注意，面向競價實例的轉移不會對使用方式造成影響，只是大幅降低了資源使用費率。
總結
通過自動擴縮集群中節(jié)點及Pod，正確調整分配給Pod中容器的資源的大小，縮減業(yè)務時段以外的部署規(guī)模，并將大部分Pod轉移至競價實例，能夠為Kubernetes集群節(jié)省超過80％的Amazon EC2實例成本。這四種重要的方式，均來自AWS良好架構構架中成本優(yōu)化支柱原則所提到的最佳實踐。事實也再次證明，這些建議確實能夠幫助客戶以更節(jié)省和更高效地方式在Amazon EKS中運行Kubernetes工作負載。
AWS
專欄
閩公網(wǎng)安備 35010202001226號
