DevOps課程-AWS-EKS 3

針對EKS叢集設置自動擴展

ZONGRU Li

13 min readOct 7, 2022

延續到前篇

手動(UI)建立EKS叢集-Part II

7.為叢集設定Auto-scaling

Configure Autoscaling

這邊順便在上課前調回以下數量:

就會看到Auto Scaling groups:

但是這邊講師有提醒到,這是AWS上的自動擴展元件
但是它僅僅只是把一堆EC2實體機台圈起來成為group罷了
然後有EC2機台數量的最小數量與最大數量
最重要的是,這個Auto Scaling groups:

不會也不是自動擴展資源,也就是EKS不會透過Auto Scaling groups來做自動擴展

取而代之能夠實行我們想要達成的EC2機台數量自動擴展的功能
是要在K8S內的叫K8S Autoscaler配合Auto Scaling groups一起
才能達成我們要的EC2機台數量"自動"擴展

**K8S Autoscaler + (AWS)Auto Scaling Group=自動擴展Worker Node(EC2)**

至於執行的流程可能如下

1.Resource縮減可能流程(pod少,所以不需要太多Worker node):

假設有很多台Worker Nodes(EC2機台),都佈署很多Pod:

當要執行自動縮減機台時候會先將Pod趕到其他Node上:

然後機台消滅:

2.或是服務滿載,pod太多,機台數量不夠,需要擴增:

然後由K8S的Autoscaler通知AWS的Auto Scaling group來擴增worker node

這其中Auto Scaling group上面Max與Min數量

讓我們很好地控制實際EC2機台數量上下限

接著我們要達到能夠自動化調整Auto Scaling group的機台數量

需要額外的權限(permissions),也就是要有相關的Role設定

讓這個Role可以調配Auto Scaling group或說EC2的數量

來讓AWS API call能夠跟Auto Scaling group做搭配

而這個IAM policy權限組合在AWS上面沒有現有適合的

所以我們要從AWS的IAM policies組合一個我們需要的

建立客製化IAM policy來提供Node Group IAM Role權限

所以這邊我登入我AWS的root帳號到IAM服務的Policies頁面

接下來就要做一個客製化的policy:

用json格式貼入以下:

tag就先不加了:

給個名稱叫:node-group-autoscale-policy

接著就要賦予之前建立的Role →eks-node-group-role

讓這個Role擴增剛剛建的policy

此時

再來還有一件事要做的是調用Auto Scaling group上的Tag:

會看到既有的Tag:

這些Tag有的是跟其他服務或元件串接的時候使用

之後要佈署K8S上的auto scaler也會需要自動發現這AWS帳號內的"Auto Scaling group"

ITOW,之後要佈署到EKS Cluster的auto scaler元件

需要與上述我們之前建出來的"Auto Scaling group"溝通

我們會需要兩個Auto Scaling group元件的Tag來指定

也就是這兩個:

可以直接沿用就好,不用更改

接著就是替EKS Cluster安裝K8S的auto scaler元件

#講師提供執行的指令是:
kubectl apply -f https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

相關doc講師沒有提供出處,我自己找到如下:

可以直接在網址上看大概內容(YAML LINK):

其中往下會看到一個Deployment元件是 →cluster-autoscaler

再稍微往下會看到:

所以執行:

#執行指令確認一下:
kubectl get deploy -n kube-system

再來需要針對這個Deployment做一些微調:

#執行針對cluster-autoscaler這個Deployment的微調:
kubectl edit deployment cluster-autoscaler -n kube-system

第一處:

第二處:

第三處,接著還要新增一些options到這行指令:

我發現這文件也有寫

第四處也是最後一處該調整的地方是Cluster版本號的部分:

參考doc文件(LINK)

找到github的分頁位置:

所以變成:

就可以儲存關掉記事本:

可以簡單檢查看看

#執行確認有autoscale相關的pod在運作:
kubectl get pod -n kube-system

#更詳細看這個pod:
kubectl get pod {pod名子} -n kube-system -o wide

#看看裡面logs:
kubectl logs {pod名子} -n kube-system

不過log內容太長了

#改將其倒出成檔案:
kubectl logs {pod名子} -n kube-system > ax-logs.txt

用VScode打開來看看:

現在先試著把min數量調到1:

看看能不能觸發這個自動元件運作把機台數量調整

等好了後

再次導出新的log內容來看看:

後面一些pod有的有轉移,有的沒有node不用轉

此時再看看node數量:

#執行以下指令:
kubectl get nodes

也就是現在可以基於pod有沒有需要新的Node去長,來自動擴展worker數量

然後還是有上下限設置,不會無限長

而且長的Node是我們自己設定的t3.small等級機台

可以大大的減少花費(用多少花多少!) — Trade Off!

但是是否需要擴增機台是需要點時間做計算

而實際機台擴增時的機台建立(或移除)也要一點時間

以上還要特別注意

以上就是EKS的auto scaling(自動擴展機台)設置!!

8.透過kubectl工具,實際部署應用程式到EKS上

後面就要來做一點點實驗實際佈署一些應用來看看會不會擴展機台

Deploy nginx Application LoadBalancer

前一篇(第二篇)筆記有提到過

在EKS上面建立type為LoadBalancer的Service元件

AWS會同時幫我們一起建立Cloud Native Loadbalancer元件

對應AWS服務就是Elastic Load Balancer元件(其他雲平台也會自動對應LB)

所以這時候可以嘗試建立以下兩個K8S元件:

Deployment & Service

其中特別注意到:

**只有type是LoadBalancer的Server元件,才會觸發自動建立雲平台的LB**

在建立前先看看:

#執行以下指令建立上述兩個K8S元件:
kubectl apply -f nginx-config.yaml

#立刻可以用kubectl指令做簡單確認:
kubectl get svc

回頭看看AWS的LB頁面:

然後特別注意到幾個特別之處

第一點:

對應AWS的LB:

上述外部80就是瀏覽器瀏覽url的預設port號

以上PORT對應是可以注意的第一點

第二點:

在前面我們為worker node特別建立的VPC

(透過CloudFormation並使用EKS文件的public與private subnet的yaml檔)

有特別定義了兩個subnet →public與private

其中可以注意到的AWS的LB元件,要讓外部可以打到

所以這個AWS LB元件是在public的部分,但其實還有...

再由上面畫面可以知道

AWS開的LB其實真的是腳踏兩條船(橫跨public與private的IP位置)

其中AWS開的LB使用到private的部分是供給內部VPC這部分溝通用

另外還可以注意的是,AWS開的LB背後對應的機台:

這邊還有以前上K8S的一個重點

就是AWS的LB先天有特殊限制是,LB必須橫跨兩個AZ

也就是至少一個instance橫跨兩個AZ

20 Replicas — Autoscaler in Action

#簡單編輯一下Deployment裡面Replica的數量到20:
kubectl edit deployment nginx#後面可以順便拿到log,確認pod名子:
kubectl get pod -n kube-system#拿到log:
kubectl logs {cluster-auotscaler的pod} -n kube-system > as-logs.txt#後面可以看看nodes變化:
kubectl get nodes