目錄
- k8s應用自動擴縮容概述
- 為什么要自動擴縮容
- 擴縮容分類
- 按對象層面
- 按方式分類
- 如何實現自動擴縮容
- HPA運作方式
- 指標信息來源
- 部署HPA實現pod自動擴縮容
- 數據采集組件metrics-server
- 概述
- 部署
- 測試環境準備
- 創建php-apache服務
- 創建nginx服務
- HPA基于cpu自動擴縮容
- 創建HPA基于cpu自動擴縮容
- 壓測php-apache服務,看擴容
- 停止對 php-apache 服務壓測,看縮容
- HPA基于內存自動擴縮容
- 創建HPA基于內存自動擴縮容
- 壓測nginx服務,看擴容
- 取消壓測,看縮容
- kubernetes cluster-autoscaler概述
- 什么是 cluster-autoscaler呢?
- Cluster Autoscaler 什么時候伸縮集群?
- 什么時候集群節點不會被 CA 刪除?
- HPA 如何與 Cluster Autoscaler 一起使用?
- Cluster Autoscaler 支持那些云廠商?
- 總結
k8s應用自動擴縮容概述
為什么要自動擴縮容
在實際的業務場景中,我們經常會遇到某個服務需要擴容的場景(例如:測試對服務壓測、電商平臺秒殺、大促活動、或由于資源緊張、工作負載降低等都需要對服務實例數進行擴縮容操作)。
擴縮容分類
按對象層面
- node擴縮容
在使用 kubernetes 集群經常問到的一個問題是,我應該保持多大的節點規模來滿足應用需求呢?cluster-autoscaler 的出現解決了這個問題, 可以通過 cluster-autoscaler 實現節點級別的動態添加與刪除,動態調整容器資源池,應對峰值流量。 - pod層面
我們一般會使用 Deployment 中的 replicas 參數,設置多個副本集來保證服務的高可用,但是這是一個固定的值,比如我們設置 10 個副本,就會啟 10 個 pod 同時 running 來提供服務。
如果這個服務平時流量很少的時候,也是 10 個 pod 同時在 running,而流量突然暴增時,又可能出現 10 個 pod 不夠用的情況。針對這種情況怎么辦?就需要自動擴縮容。
按方式分類
- 手動模式::通過 kubectl scale 命令,這樣需要每次去手工操作一次,而且不確定什么時候業務請求量就很大了,所以如果不能做到自動化的去擴縮容的話,這也是一個很麻煩的事情。
- 自動模式:
1、kubernetes HPA(Horizontal Pod Autoscaling):根據監控指標(cpu 使用率、磁盤、自定義的等)自動擴容或縮容服務中的pod數量,當業務需求增加時,系統將無縫地自動增加適量 pod 容器,提高系統穩定性。
2、kubernetes KPA(Knative Pod Autoscaler):基于請求數對 Pod 自動擴縮容,KPA 的主要限制在于它不支持基于 CPU 的自動擴縮容。
3、kubernetes VPA(Vertical Pod Autoscaler):基于 Pod 的資源使用情況自動設置 pod 的 CPU 和內存的 requests,從而讓集群將 Pod 調度到有足夠資源的最佳節點上。
如何實現自動擴縮容
HPA運作方式
- 整體邏輯:K8s 的 HPA controller 已經實現了一套簡單的自動擴縮容邏輯,默認情況下,每 15s 檢測一次指標,只要檢測到了配置 HPA 的目標值,則會計算出預期的工作負載的副本數,再進行擴縮容操作。同時,為了避免過于頻繁的擴縮容,默認在 5min 內沒有重新擴縮容的情況下,才會觸發擴縮容。
- 缺陷:HPA 本身的算法相對比較保守,可能并不適用于很多場景。例如,一個快速的流量突發場景,如果正處在 5min 內的 HPA 穩定期,這個時候根據 HPA 的策略,會導致無法擴容。
- pod數量計算方式:通過現有 pods 的 CPU 使用率的平均值(計算方式是最近的 pod 使用量(最近一分鐘的平均值,從 metrics-server 中獲得)除以設定的每個 Pod 的 CPU 使用率限額)跟目標使用率進行比較,并且在擴容時,還要遵循預先設定的副本數限制:MinReplicas <= Replicas <= MaxReplicas。
計算擴容后 Pod 的個數:sum(最近一分鐘內某個 Pod 的 CPU 使用率的平均值)/CPU 使用上限的整數+1
指標信息來源
K8S 從 1.8 版本開始,各節點CPU、內存等資源的 metrics 信息可以通過 Metrics API 來獲取,用戶可以直接獲取這些 metrics 信息(例如通過執行 kubect top 命令),HPA 使用這些 metics 信息來實現動態伸縮。
部署HPA實現pod自動擴縮容
基于1.23.1版kubernetes
HPA官網:https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/
數據采集組件metrics-server
概述
metrics-server 是一個集群范圍內的資源數據集和工具,同樣的,metrics-server 也只是顯示數據,并不提供數據存儲服務,主要關注的是資源度量 API 的實現,比如 CPU、文件描述符、內存、請求延時等指標,metric-server 收集數據給 k8s 集群內使用,如 kubectl,hpa,scheduler 等。
github地址:https://github.com/kubernetes-sigs/metrics-server/
不同k8s版本根據官網安裝對應版本的metrics-server
部署
1、鏡像下載
所用鏡像可提前自行下載:registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.6.1
2、導入鏡像
docker load -i metrics-server-0.6.1.tar.gz
3、修改apiserver配置
注意:會中斷業務,生產環境謹慎操作!
這個是 k8s 在 1.17 的新特性,如果是 1.16 版本的可以不用添加,1.17 以后要添加。這個參數的作用是 Aggregation 允許在不修改 Kubernetes 核心代碼的同時擴展 Kubernetes API。
vim /etc/kubernetes/manifests/kube-apiserver.yaml
增加如下內容:
- --enable-aggregator-routing=true
添加后的效果如下圖所示:
修改完成后重啟kubelet
systemctl restart kubelet
4、部署metrics-server 服務
kubectl apply -f components.yaml
用到的yaml文件到github下載,地址:https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.6.1/components.yaml
5、驗證metrics-server是否部署成功
kubectl get pods -n kube-system | grep metrics
可以看到pod處于Running狀態:
kubectl top nodes # 查看各節點資源使用情況
kubectl top pods -n kube-system # 查看kube-system名稱空間下pod資源使用情況
測試環境準備
創建php-apache服務
1、鏡像準備
使用 dockerfile 構建一個新的鏡像,在 k8s 的 xuegod63 節點構建
mkdir php cd php vim dockerfile
dockerfile內容如下:
FROM php:5-apache ADD index.php /var/www/html/index.php RUN chmod a+rx index.php
創建index.php文件,內容如下:
<?php $x = 0.0001; for ($i = 0; $i <= 1000000;$i++) { $x += sqrt($x); } echo "OK!"; ?>
docker build -t k8s.gcr.io/hpa-example:v1 . # 構建鏡像 docker save -o hpa-example.tar.gz k8s.gcr.io/hpa-example:v1 # 打包鏡像 scp hpa-example.tar.gz xuegod64:/root/ # 將鏡像傳到工作節點
在工作節點導入鏡像:
docker load -i hpa-example.tar.gz
2、通過 deployment 部署一個 php-apache 服務
cat php-apache.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: php-apache spec: selector: matchLabels: run: php-apache replicas: 1 template: metadata: labels: run: php-apache spec: containers: - name: php-apache image: k8s.gcr.io/hpa-example:v1 imagePullPolicy: IfNotPresent ports: - containerPort: 80 resources: limits: cpu: 500m requests: cpu: 200m --- apiVersion: v1 kind: Service metadata: name: php-apache labels: run: php-apache spec: ports: - port: 80 selector: run: php-apache
kubectl apply -f php-apache.yaml # 更新資源清單文件 kubectl get pods # 驗證 php 是否部署成功
創建nginx服務
1、通過deployment部署一個nginx服務
cat nginx.yaml
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-hpa spec: selector: matchLabels: app: nginx replicas: 1 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.9.1 imagePullPolicy: IfNotPresent ports: - containerPort: 80 name: http protocol: TCP resources: requests: cpu: 0.01 memory: 25Mi limits: cpu: 0.05 memory: 60Mi --- apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: selector: app: nginx type: NodePort ports: - name: http protocol: TCP port: 80 targetPort: 80 nodePort: 30080
注意:nginx 的 pod 里需要有如下字段,否則 hpa 會采集不到內存指標
resources: requests: cpu: 0.01 memory: 25Mi limits: cpu: 0.05 memory: 60Mi
創建資源并查看:
kubectl apply -f nginx.yaml # 更新資源清單 kubectl get pods # 查看pod kubectl get svc # 查看service
HPA基于cpu自動擴縮容
php-apache 服務正在運行,使用 kubectl autoscale 創建自動縮放器,實現對 php-apache 這個deployment 創建的 pod 自動擴縮容,下面的命令將會創建一個 HPA,HPA 將會根據 CPU資源指標增加或減少副本數,創建一個可以實現如下目的的 hpa:
(1)讓副本數維持在 1-10 個之間(這里副本數指的是通過 deployment 部署的 pod 的副本數)
(2)將所有 Pod 的平均 CPU 使用率維持在 50%(通過 kubectl run 運行的每個 pod 如果是 200毫核,這意味著平均 CPU 利用率為 100 毫核)
創建HPA基于cpu自動擴縮容
創建:
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
查看:
kubectl get hpa
可以看到cpu目標及當前狀態,最大、最小、當前副本數。
壓測php-apache服務,看擴容
重新打開一個master節點的終端,進行如下操作:
kubectl run v1 -it --image=busybox --image-pull-policy=IfNotPresent /bin/sh while true; do wget -q -O- http://php-apache.default.svc.cluster.local; done
在原master終端查看hpa情況:
kubectl get hpa kubectl get pods
可以看到平均cpu使用率達到了98%,副本數已經變為5個。
注意:可能需要幾分鐘來穩定副本數。由于不以任何方式控制負載量,因此最終副本數可能會與此示例不同。
停止對 php-apache 服務壓測,看縮容
停止向 php-apache 這個服務發送查詢請求,在 busybox 鏡像創建容器的終端中,通過 Ctrl+ C 把剛才 while 請求停止,然后,我們將驗證結果狀態(大約一分鐘后):
kubectl get hpa
可以看到平均cpu使用率降為0%,副本數降為1。
HPA基于內存自動擴縮容
nginx 服務正在運行,使用 kubectl autoscale 創建自動縮放器,實現對 nginx 這個deployment 創建的 pod 自動擴縮容,下面的命令將會創建一個 HPA,HPA 將會根據內存資源指標增加或減少副本數,創建一個可以實現如下目的的 hpa:
(1)讓副本數維持在 1-10 個之間(這里副本數指的是通過 deployment 部署的 pod 的副本數)
(2)將所有 Pod 的平均內存使用率維持在 60%
創建HPA基于內存自動擴縮容
hpa-v1.yaml 內容如下:
apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: nginx-hpa spec: maxReplicas: 10 minReplicas: 1 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-hpa metrics: - type: Resource resource: name: memory target: type: Utilization averageUtilization: 60
kubectl apply -f hpa-v1.yaml # 更新資源清單 kubectl get hpa nginx-hpa # 查看創建的hpa
可以看到當前內存使用率、目標內存使用率,最大、最小、當前副本數。
壓測nginx服務,看擴容
使用master節點的終端2登錄到上面通過 pod 創建的 nginx,并生成一個文件,增加內存
kubectl exec -it nginx-hpa-7f5d6fbfd9-4d95f -- /bin/bash dd if=/dev/zero of=/tmp/a
使用終端1查看hpa情況:
kubectl get hpa nginx-hpa
可以看到平均內存使用率達到了238%,,副本數達到了4個。
取消壓測,看縮容
到終端2使用 Ctrl + C 中斷dd進程,刪除/tmp/a這個文件
rm -rf /tmp/a
在終端1查看hpa的情況:
kubectl get hpa nginx-hpa
可以看到平均內存使用率已經降到5%,副本數也降為1。(需要等幾分鐘才能看到)
kubernetes cluster-autoscaler概述
什么是 cluster-autoscaler呢?
Cluster Autoscaler (CA)是一個獨立程序,是用來彈性伸縮 kubernetes 集群的。它可以自動根據部署應用所請求的資源量來動態的伸縮集群。當集群容量不足時,它會自動去 Cloud Provider (支持GCE、GKE 和 AWS)創建新的 Node,而在 Node 長時間資源利用率很低時自動將其刪除以節省開支。
項目地址:https://github.com/kubernetes/autoscaler
Cluster Autoscaler 什么時候伸縮集群?
在以下情況下,集群自動擴容或者縮放:
擴容:由于資源不足,某些 Pod 無法在任何當前節點上進行調度。
縮容: Node 節點資源利用率較低時,且此 node 節點上存在的 pod 都能被重新調度到其他 node節點上運行。
什么時候集群節點不會被 CA 刪除?
1、節點上有 pod 被 PodDisruptionBudget 控制器限制。
2、節點上有命名空間是 kube-system 的 pods。
3、節點上的 pod 不是被控制器創建,例如不是被 deployment, replica set, job, stateful set 創建。
4、節點上有 pod 使用了本地存儲。
5、節點上 pod 驅逐后無處可去,即沒有其他 node 能調度這個 pod。
6、節點有注解:“cluster-autoscaler.kubernetes.io/scale-down-disabled”: “true”(在 CA 1.0.3 或更高版本中受支持)。
kubectl annotate node <nodename> cluster-autoscaler.kubernetes.io/scale-down-disabled=true
HPA 如何與 Cluster Autoscaler 一起使用?
Horizontal Pod Autoscaler 會根據當前 CPU 負載更改部署或副本集的副本數。如果負載增加,則 HPA 將創建新的副本,集群中可能有足夠的空間,也可能沒有足夠的空間。如果沒有足夠的資源,CA將嘗試啟動一些節點,以便 HPA 創建的 Pod 可以運行。如果負載減少,則 HPA 將停止某些副本。結果,某些節點可能變得利用率過低或完全為空,然后 CA 將終止這些不需要的節點。
Cluster Autoscaler 支持那些云廠商?
- GCE https://kubernetes.io/docs/concepts/cluster-administration/cluster-management/
- GKE https://cloud.google.com/container-engine/docs/cluster-autoscaler
- AWS(亞馬遜) https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md
- Azure(微軟) https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/azure/README.md
- Alibaba Cloud https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/alicloud/README.md
- OpenStack Magnum https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/magnum/README.md
- DigitalOcean https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/digitalocean/README.md
- CloudStack https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/cloudstack/README.md
- Exoscale https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/exoscale/README.md
- Packet https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/packet/README.md
- OVHcloud https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/ovhcloud/README.md
- Linode https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/linode/README.md
- Hetzner https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/hetzner/README.md
- Cluster API https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/clusterapi/README.md