023.掌握Pod-Pod擴容和縮容
一 Pod的擴容和縮容
Kubernetes對Pod的擴縮容操作提供了手動和自動兩種模式，手動模式通過執行kubectl scale命令或通過RESTful API對一個Deployment/RC進行Pod副本數量的設置。自動模式則需要用戶根據某個性能指標或者自定義業務指標，並指定Pod副本數量的範圍，系統將自動在這個範圍內根據性能指標的變化進行調整。
1.1 手動縮容和擴容
1 [root@uk8s-m-01 study]# vi nginx-deployment.yaml 2 apiVersion: apps/v1beta1 3 kind: Deployment 4 metadata: 5 name: nginx-deployment 6 spec: 7 replicas: 3 8 template: 9 metadata: 10 labels: 11 app: nginx 12 spec: 13 containers: 14 - name: nginx 15 image: nginx:1.7.9 16 ports: 17 - containerPort: 80
1 [root@uk8s-m-01 study]# kubectl create -f nginx-deployment.yaml 2 [root@uk8s-m-01 study]# kubectl scale deployment nginx-deployment --replicas=5 #擴容至5個 3 [root@uk8s-m-01 study]# kubectl get pods #查看擴容后的Pod
1 [root@uk8s-m-01 study]# kubectl scale deployment nginx-deployment --replicas=2 #縮容至2個 2 [root@uk8s-m-01 study]# kubectl get pods
1.2 自動擴容機制
Kubernetes使用Horizontal Pod Autoscaler（HPA）的控制器實現基於CPU使用率進行自動Pod擴縮容的功能。HPA控制器基於Master的kube-controller-manager服務啟動參數–horizontal-pod-autoscaler-sync-period定義的探測周期（默認值為15s），周期性地監測目標Pod的資源性能指標，並與HPA資源對象中的擴縮容條件進行對比，在滿足條件時對Pod副本數量進行調整。
- HPA原理
Kubernetes中的某個Metrics Server（Heapster或自定義MetricsServer）持續採集所有Pod副本的指標數據。HPA控制器通過Metrics Server的API（Heapster的API或聚合API）獲取這些數據，基於用戶定義的擴縮容規則進行計算，得到目標Pod副本數量。
當目標Pod副本數量與當前副本數量不同時，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）發起scale操作，調整Pod的副本數量，完成擴縮容操作。
- HPA指標類型
Master的kube-controller-manager服務持續監測目標Pod的某種性能指標，以計算是否需要調整副本數量。目前Kubernetes支持的指標類型如下：
Pod資源使用率：Pod級別的性能指標，通常是一個比率值，例如CPU使用率。
Pod自定義指標：Pod級別的性能指標，通常是一個數值，例如接收的請求數量。
Object自定義指標或外部自定義指標：通常是一個數值，需要容器應用以某種方式提供，例如通過HTTP URL“/metrics”提供，或者使用外部服務提供的指標採集URL。
Metrics Server將採集到的Pod性能指標數據通過聚合API（Aggregated API） 如metrics.k8s.io、 custom.metrics.k8s.io和external.metrics.k8s.io提供給HPA控制器進行查詢。
- 擴縮容算法
Autoscaler控制器從聚合API獲取到Pod性能指標數據之後，基於下面的算法計算出目標Pod副本數量，與當前運行的Pod副本數量進行對比，決定是否需要進行擴縮容操作：
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
即當前副本數 x（當前指標值/期望的指標值），將結果向上取整。
釋義：以CPU請求數量為例，如果用戶設置的期望指標值為100m，當前實際使用的指標值為200m，則計算得到期望的Pod副本數量應為兩個（200/100=2）。如果設置的期望指標值為50m，計算結果為0.5，則向上取整值為1， 得到目標Pod副本數量應為1個。
注意：當計算結果與1非常接近時，可以設置一個容忍度讓系統不做擴縮容操作。容忍度通過kube-controller-manager服務的啟動參數–horizontalpod-autoscaler-tolerance進行設置，默認值為0.1（即10%），表示基於上述算法得到的結果在[-10%-+10%]區間內，即[0.9-1.1]，控制器都不會進行擴縮容操作。
也可以將期望指標值（desiredMetricValue）設置為指標的平均值類型，例如targetAverageValue或targetAverageUtilization，此時當前指標值（currentMetricValue） 的算法為所有Pod副本當前指標值的總和除以Pod副本數量得到的平均值。
此外，存在幾種Pod異常的如下情況：
- Pod正在被刪除（設置了刪除時間戳）：將不會計入目標Pod副本數量。
- Pod的當前指標值無法獲得：本次探測不會將這個Pod納入目標Pod副本數量，後續的探測會被重新納入計算範圍。
- 如果指標類型是CPU使用率，則對於正在啟動但是還未達到Ready狀態的Pod，也暫時不會納入目標副本數量範圍。
提示：可以通過kubecontroller-manager服務的啟動參數–horizontal-pod-autoscaler-initialreadiness-delay設置首次探測Pod是否Ready的延時時間，默認值為30s。
另一個啟動參數–horizontal-pod-autoscaler-cpuinitialization-period設置首次採集Pod的CPU使用率的延時時間。
當存在缺失指標的Pod時，系統將更保守地重新計算平均值。系統會假設這些Pod在需要縮容（Scale Down） 時消耗了期望指標值的100%，在需要擴容（Scale Up）時消耗了期望指標值的0%，這樣可以抑制潛在的擴縮容操作。
此外，如果存在未達到Ready狀態的Pod，並且系統原本會在不考慮缺失指標或NotReady的Pod情況下進行擴展，則系統仍然會保守地假設這些Pod消耗期望指標值的0%，從而進一步抑制擴容操作。如果在HorizontalPodAutoscaler中設置了多個指標，系統就會對每個指標都執行上面的算法，在全部結果中以期望副本數的最大值為最終結果。如果這些指標中的任意一個都無法轉換為期望的副本數（例如無法獲取指標的值），系統就會跳過擴縮容操作。
最後， 在HPA控制器執行擴縮容操作之前，系統會記錄擴縮容建議信息（Scale Recommendation）。控制器會在操作時間窗口（時間範圍可以配置）中考慮所有的建議信息，並從中選擇得分最高的建議。這個值可通過kube-controller-manager服務的啟動參數–horizontal-podautoscaler-downscale-stabilization-window進行配置，默認值為5min。這個配置可以讓系統更為平滑地進行縮容操作，從而消除短時間內指標值快速波動產生的影響。
1.3 HorizontalPodAutoscaler
Kubernetes將HorizontalPodAutoscaler資源對象提供給用戶來定義擴縮容的規則。
HorizontalPodAutoscaler資源對象處於Kubernetes的API組“autoscaling”中， 目前包括v1和v2兩個版本。 其中autoscaling/v1僅支持基於CPU使用率的自動擴縮容， autoscaling/v2則用於支持基於任意指標的自動擴縮容配置， 包括基於資源使用率、 Pod指標、 其他指標等類型的指標數據。
示例1：基於autoscaling/v1版本的HorizontalPodAutoscaler配置，僅可以設置CPU使用率。
1 [root@uk8s-m-01 study]# vi php-apache-autoscaling-v1.yaml 2 apiVersion: autoscaling/v1 3 kind: HorizontalPodAutoscaler 4 metadata: 5 name: php-apache 6 spec: 7 scaleTargetRef: 8 apiVersion: apps/v1 9 kind: Deployment 10 name: php-apache 11 minReplicas: 1 12 maxReplicas: 10 13 targetCPUUtilizationPercentage: 50
釋義：
scaleTargetRef：目標作用對象，可以是Deployment、ReplicationController或ReplicaSet。
targetCPUUtilizationPercentage：期望每個Pod的CPU使用率都為50%，該使用率基於Pod設置的CPU Request值進行計算，例如該值為200m，那麼系統將維持Pod的實際CPU使用值為100m。
minReplicas和maxReplicas：Pod副本數量的最小值和最大值，系統將在這個範圍內進行自動擴縮容操作， 並維持每個Pod的CPU使用率為50%。
為了使用autoscaling/v1版本的HorizontalPodAutoscaler，需要預先安裝Heapster組件或Metrics Server，用於採集Pod的CPU使用率。
示例2：基於autoscaling/v2beta2的HorizontalPodAutoscaler配置。
1 [root@uk8s-m-01 study]# vi php-apache-autoscaling-v2.yaml 2 apiVersion: autoscaling/v2beta2 3 kind: HorizontalPodAutoscaler 4 metadata: 5 name: php-apache 6 spec: 7 scaleTargetRef: 8 apiVersion: apps/v1 9 kind: Deployment 10 name: php-apache 11 minReplicas: 1 12 maxReplicas: 10 13 metrics: 14 - type: Resource 15 resource: 16 name: cpu 17 target: 18 type: Utilization 19 averageUtilization: 50
釋義：
scaleTargetRef：目標作用對象，可以是Deployment、ReplicationController或ReplicaSet。
minReplicas和maxReplicas：Pod副本數量的最小值和最大值，系統將在這個範圍內進行自動擴縮容操作， 並維持每個Pod的CPU使用率為50%。
metrics：目標指標值。在metrics中通過參數type定義指標的類型；通過參數target定義相應的指標目標值，系統將在指標數據達到目標值時（考慮容忍度的區間）觸發擴縮容操作。
- metrics中的type（指標類型）設置為以下幾種：
- Resource：基於資源的指標值，可以設置的資源為CPU和內存。
- Pods：基於Pod的指標，系統將對全部Pod副本的指標值進行平均值計算。
- Object：基於某種資源對象（如Ingress）的指標或應用系統的任意自定義指標。
Resource類型的指標可以設置CPU和內存。對於CPU使用率，在target參數中設置averageUtilization定義目標平均CPU使用率。對於內存資源，在target參數中設置AverageValue定義目標平均內存使用值。指標數據可以通過API“metrics.k8s.io”進行查詢，要求預先啟動Metrics Server服務。
Pods類型和Object類型都屬於自定義指標類型，指標的數據通常需要搭建自定義Metrics Server和監控工具進行採集和處理。指標數據可以通過API“custom.metrics.k8s.io”進行查詢，要求預先啟動自定義Metrics Server服務。
類型為Pods的指標數據來源於Pod對象本身， 其target指標類型只能使用AverageValue，示例：
1 metrics: 2 - type: Pods 3 pods: 4 metrics: 5 name: packets-per-second 6 target: 7 type: AverageValue 8 averageValue: 1k
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】
※為什麼 USB CONNECTOR 是電子產業重要的元件?
※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!
※想要讓你的商品成為最夯、最多人討論的話題?網頁設計公司讓你強力曝光
※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!
