文章目錄
- 1、前置準備
- 2、需求場景
- 3、Scale 靜態擴縮容
- 3.1、創建 Deployment 腳本
- 3.2、Scale 擴縮容
- 3、HPA 自動擴縮容
- 3.1、安裝 Metrics
- 3.2、創建 Deployment 演示案例
- 3.3、創建 HPA
- 3.4、觸發 HPA 自動擴縮容
1、前置準備
本次案例演示，我選擇了阿里云ECS（搶占式）搭建了 K8S 1主2從集群，資源配置規格如下：
- 主節點 k8s-master：4核8G、40GB硬盤、CentOS7.9（內網IP：172.16.0.172）
- 從節點 k8s-node1： 4核8G、40GB硬盤、CentOS7.9（內網IP：172.16.0.173）
- 從節點 k8s-node2： 4核8G、40GB硬盤、CentOS7.9（內網IP：172.16.0.174）
K8S集群構建參考：https://blog.csdn.net/weixin_46594796/article/details/139649056
2、需求場景
在企業級生產環境中，經常會遇到某個服務容器性能不足的情況，例如：CPU、內存飚高，這種情況一般會想到對該服務進行橫向擴容，創建更多的服務容器來分攤工作量。或者說容器資源過剩，想要把資源節省出來，通常這種情況需要我們去手動的進行擴縮容。動態調整應用實例數量以滿足業務需求，同時優化資源利用率。
- 突發流量：當應用訪問量突然激增（如促銷活動、熱點事件），增加Pod副本數，避免服務過載或崩潰。
- 低峰時段：在流量低谷時減少Pod數量，節省資源成本。
3、Scale 靜態擴縮容
3.1、創建 Deployment 腳本
在K8S環境中，我們一般使用 scale 命令來對 Pod 資源進行手動擴縮容，首先先通過 Deployment 創建3個 Niginx Pod，deploy-nginx.yaml內容如下：
mkdir /etc/k8s
cat > /etc/k8s/deploy-nginx.yaml <<-'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:name: deploy-nginx
spec:selector:matchLabels:app: nginxreplicas: 3template:metadata:labels:app: nginxspec:containers:- name: container-nginximage: nginx:1.20.2-alpineports:- containerPort: 80
EOF
執行 delopment 文件：
kubectl apply -f /etc/k8s/deploy-nginx.yaml
此時可以看到，3個Pod容器已經成功部署完成了：
3.2、Scale 擴縮容
上面腳本執行完畢后，已經自動創建3個Pod了，想要把3個Pod擴容為5個，就需要使用 scale 命令手動執行：
kubectl scale deploy deploy-nginx --replicas=5
就可以看到，直接將容器數量擴容為5個了：
縮容只需要把數字調小即可，這里就不演示了。
但是這樣終歸是需要運維人員手動的進行調整，有些特殊場景流量高峰期可能很隨機，這樣在通過人工進行處理就不太合適了，有沒有可以根據資源使用情況自動擴縮容Pod的方案，官方提供了就是 HPA。
3、HPA 自動擴縮容
3.1、安裝 Metrics
首先，通過命令查看哪些 Pod 占用資源比較高：kubectl top pods，執行完畢后可以發現，錯誤日志：error: Metrics API not available，說明沒有安裝Metrics
首先在主節點上下載配置文件：
wget https://xuzhibin-bucket.oss-cn-beijing.aliyuncs.com/k8s/metric-server.yaml
這個配置文件中已經被修改過，相比于官方的配置文件有兩處修改：
- 處理加密證書不匹配問題（生產環境需要配置好證書的）
- Metrics鏡像改成了使用阿里云，否則無法下載
這個時候，就可以直接部署 Metrics：
kubectl apply -f metric-server.yaml
最后通過該命令查看，部署是否完畢：
kubectl get po -n kube-system | grep metrics-server
3.2、創建 Deployment 演示案例
演示案例 deployment 腳本（svc-hpa.yaml），這是由Apache提供的，配置如下：
mkdir -p /etc/sca/hpa
cd /etc/sca/hpa
cat > svc-hpa.yaml <<-'EOF'
apiVersion: apps/v1
kind: Deployment
metadata:name: php-apache
spec:selector:matchLabels:run: php-apachetemplate:metadata:labels:run: php-apachespec:containers:- name: php-apacheimage: deis/hpa-exampleports:- containerPort: 80resources:limits:cpu: 500mrequests:cpu: 200m
---
apiVersion: v1
kind: Service
metadata:name: php-apachelabels:run: php-apache
spec:ports:- port: 80selector:run: php-apache
EOF
啟動演示案例容器，就會創建一個Pod：
kubectl apply -f svc-hpa.yaml
這里面主要注意的是，有個資源限定的配置：表示對pod容器資源的限定，啟動最少占用0.2核CPU，最大占用0.5核CPU：
3.3、創建 HPA
創建HPA需要使用 autoscale 命令，這里--cpu-percent=50說明是50%，結合上面最大占用500m（0.5核）CPU，所以如果當前Pod占用了0.25核CPU，就會對Pod容器進行擴容，最多可以達到10個，但不會少于1個。
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
?? 如果不再使用HPA，可以用下述命令進行刪除：
kubectl delete hpa php-apache
3.4、觸發 HPA 自動擴縮容
先新開一個窗口，通過下述命令監聽一下HPA狀態：
kubectl get hpa php-apache --watch
此時沒有請求量，還是比較平靜的：
在新開一個窗口，通過 Linux 系統提供的工具BusyBox，每過0.1s發送請求，模擬大流量場景讓HPA觸發擴容，通過下述命令：
kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
過了一段時間，可以看到窗口展示大量接口調用：
這個時候再去看監控窗口，發現確實開始自動擴容了：只要過了50%，Pod副本數量就開始不斷新增，隨著Pod增多，CPU占用也逐漸下降了，發現8個Pod就能控制在50%以下，就不會繼續擴容了。
此時已經擴容到8個容器了：
這個時候把調用腳本停掉，再看監控日志會發現，Pod自動被逐漸銷毀，但是并不是馬上進行縮容，CPU使用率降下來后，他會先等待一會兒，然后才開始銷毀Pod容器，原因是擔心只是短暫流量跌下來，會給一點緩沖時間，重復創建銷毀容器的代價太高了！
部署)
