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