基本上使用容器雲我們最看重的一項重點之一就是容器(Pod)的自動擴縮容機制(Auto-Scaling),雖然傳統VM世界便有相同的機制,但容器的Auto-Scaling更加輕量與方便。有一個說法是:"業務系統上容器雲的目標就是打造一個從下到上都可做的彈性擴展的雲應用系統。[1]"
容器雲自動擴縮容的商業策略有兩個:一種是預期業務上升的預先容器自動擴充然後再縮容;另一種是根據性能指標自動擴縮容器數量。
而Kubernetes在Auto-Scaling的實現上有三種方式可以達成上述擴縮容目標:
手動擴縮容
手動擴縮容是透過手動下指令的方式對容器數量進行調整,其實這並不算是Auto-Scaling的機制,但是它卻可以方便我們實現第一種商業上的擴充容器策略,即在業務旺季來臨前可以手動預先擴展容器到可應付業務的數量,等業務旺季過去再手動調整回正常的容器數量。
在這邊指令大概是使用$kubectl scale 去達成我們的目的,通常我們scale的對象是Deployment或Replication Controller(RC)物件所產生的Pod,以下是一些常用指令範本[2]:
$ kubectl scale --replicas=3 rs/foo # Scale a replica set named 'foo' to 3
$ kubectl scale --replicas=3 -f foo.yaml # Scale a resource specified in "foo.yaml" to 3
$ kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deployment named mysql's current size is 2, scale mysql to 3
$ kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple rc
$ kubectl scale rc redis-slave --replicas=3 # Scale a rc named redis-slave to 3
透過HPA物件根據CPU指標實現的擴縮容
早期的Kubernetes版本貼心地提供了HPA( Horizontal Pod Autoscaler)物件可以根據pod本身的CPU使用率來決定是否Auto-Scaling,也就是說一個Pod本身CPU使用率如果超過特定的門檻值,HPA就會就會建立一個新的Pod分擔流量,反之HPA就會減少Pod來釋放多餘資源,所以HPA物件必須設定三個參數:最高及最低Pod數量以及CPU門檻值。
設定最低的Pod數量是避免Pod被砍光光(最少要留一個Pod茍活吧?);而設定最高的Pod數量則是避免資源超用,然後Pod要不要擴充則是根據CPU門檻值決定。
所以要建立Auto-Scaling,那就必須在Kubernetes中加入HPA物件。以下是建立一個HPA物件的yaml實例:
apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: name: php-apache-hpa spec: scaleTargetRef: apiVersion: v1 kind: ReplicationController name: php-apache minReplicas: 1 maxReplicas: 8 targetCPUUtilizationPercentage: 80
|
以下稍作說明:
- kind: HorizontalPodAutoscaler : 這是HPA物件,物件名稱php-apache-hpa
- scaleTargetRef: 這個HPA物件是針對一個名為php-apache的RC物件作用。
- minReplicas: 維持php-apache的最少pod數量是 1。
- maxReplicas: 維持php-apache的最多pod數量是 8。
- targetCPUutilizationPercentage: 當Pod的CPU超過80%用量則新增一個Pod。
因為hpa也是一個k8s物件,所以我們有建立hpa物件的話,也可以針對hpa去查看該物件內容:
$ kubectl get hpa
透過HPA物件根據使用者自訂指標實現的擴縮容
CPU本身並不是一個很好的Auto-Scaling指標,因為很多應用並不是CPU密集性的,而且如果用CPU作為擴縮容指標,如果設定不當,就會出現頻繁擴縮容的狀況,容易損耗系統性能,系統也會不穩定。
為解決這個缺點,kubernetes發展出新一版的HPA物件可以支援使用者自定義指標來實現Auto-Scaling,原理基本上與CPU Based的HPA做法一樣,但差異與複雜度在於必須同時建立一些物件並透過相關API來收集各種不同指標,以下是基本架構給大家參考,實現做法就不在這邊贅述,大家先知道HPA也可以實現CPU以外的擴縮機制即可。
[圖片來源]https://banzaicloud.com/[3]
最後,提醒大家在做pod的auto-scaling其實不該直接只擴充pod在同一個node上,通常比較建議的做法是先自動新增一個node再擴展新的pod在上面,但這樣要自動化的步驟就會更加複雜許多。
手動擴縮容可以實現第一種預期業務上升(如生產旺季)時預先擴充容器的策略,之後再手動調回原本一般業務容器量;而另外兩種透過HPA物件Auto-Scaling的方式則可以實現自動的根據系統容量變化來彈性擴縮容器的商業策略。
[Reference]
- Kubernetes 權威指南 企業級容器雲實戰
- https://jimmysong.io/kubernetes-handbook/guide/kubectl-cheatsheet.html
- https://banzaicloud.com/blog/k8s-horizontal-pod-autoscaler/
2019年12月16日星期一