一、前言

　　前兩章有的介紹docker與Kubernetes。docker是專案執行的容器，Kubernetes則是隨著微服務架構的演變docker容器增多而進行其編排的重要工具。Kubernetes不僅可以對容器進行檢測狀態，還能對其自動擴容縮容。下面就來介紹介紹Kubernetes是如何自動的擴容縮容的。

二、Kubernetes彈性伸縮簡介

　　手動的擴縮容是通過kubectl scale命令或者修改deployment的replicas數量來控制Pod的擴縮容。當然前一章有說過可以自己開發客戶端傳送請求到APIServer中。但是這稍微會麻煩點。而Kubernetes自帶的功能使得其從兩個維度上支援自動的彈性伸縮：

　　Cluster AutoScale：處理Kubernetes叢集中Node節點伸縮，缺點在於嚴重依賴Iaas廠商提供的雲主機服務和資源監控服務。

　　HPA：處理Pod副本集的自動彈性伸縮，使用的是監控服務採集到的資源監控指標資料。

三、HPA簡介

　　HPA是通過週期性檢查Deployment（可以理解為微服務架構中的一個服務。是在Master節點中的物件。下面可以控制多個Pod）控制的目標Pod的相關監控指標的變化情況來確定是否需要針對性地調整目標Pod的副本數。通常應用的擴縮容都是由CPU或記憶體的使用率實現的。

　　HPA可以通過Kubernetes自帶的監控系統heapster來獲取到CPU的使用率。但是從Kubernetes1.8開始，資源使用指標改為通過metrics api獲取，所以需要注意自己的Kubernetes版本。而從1.8開始，Kubernetes也將資源分為了下面兩種

　　core metrics（核心指標）：採集每個節點上kubelet公開的summary api中的指標資訊，通常只包含CPU，記憶體使用率資訊

　　custom metrics（自定義指標）：允許使用者從外部的監控系統當中採集自定義的指標，如應用的QPS等指標。

四、直接使用HPA進行自動擴縮容（Kubernetes版本<1.8）

　　可直接定義HPA物件

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  maxReplicas: 10
  minReplicas: 4
  scaleTargetRef:
    kind: Deployment
    name: nginx-demo
  targetCPUUtilizationPercentage: 90

　　從上面配置可以看出HPA控制了一個nginx-demo的Deployment裡的4個Pod副本，當這個Pod的CPUUtilizationPercentage也就是Pod自身的CPU利用率為90%就會進行擴容，最大不超過10個，最小值不會低於4個

　　注：CPUUtilizationPercentage 是一個計算平均值，即目標 Pod 所有副本自身的 CPU 利用率的平均值。一個 Pod 自身的 CPU 利用率是該Pod當前的 CPU 的使用量除以它的 Pod Request 的值，比如定義一個 Pod 的 Pod Request 為0.4，而當前的 Pod 的CPU 使用量為 0.2，則它的 CPU 使用率為 50%。所以如果目標Pod沒有定義Pod Request的值，是無法使用CPUUtilizationPercentage來進行擴縮容的。

　　當然使用簡單的命令也可以直接建立等價的HPA物件

kubectl autoscale deployment php-apache --cpu-percent=90 --min=4 --max=10

五、通過metrics-server來實現擴縮容

　　1、安裝metrics-server　　

　　metrics-server程式碼倉庫地址： https://github.com/kubernetes-incubator/metrics-server。下載並且安裝後

# 配置command

編輯metrics-server-deployment.yaml，配置如下內容：
...
      containers:
      - name: metrics-server
        image: hub.dz11.com/library/metrics-server-amd64:v0.3.6
        command:
        - /metrics-server
        - --kubelet-insecure-tls
        - --kubelet-preferred-address-types=InternalIP
        imagePullPolicy: Always
...
kubectl apply -f ./

　　在metrics-server-deployment.yaml中新增一個command，需要加入兩個kubelet配置項，使得metrics-server能夠通過kubelet採集資料指標。上述操作會在kube-system中啟動一個名稱字首為metrics-server的pods以提供實時資料採集。

　　通過如下命令驗證安裝是否成功

# 在apiservice中可以看到多了一個介面
kubectl get apiservice
...
v1beta1.metrics.k8s.io                  2020-02-09T03:14:46Z
...

# 通過訪問metrics.k8s.io介面，如能正常訪問代表安裝成功

kubectl get --raw "/apis/metrics.k8s.io/v1beta1" | jq .        
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "nodes",
      "singularName": "",
      "namespaced": false,
      "kind": "NodeMetrics",
      "verbs": [
        "get",
        "list"
      ]
    },
    {
      "name": "pods",
      "singularName": "",
      "namespaced": true,
      "kind": "PodMetrics",
      "verbs": [
        "get",
        "list"
      ]
    }
  ]
}

　　然後再執行下面兩條命令：

#獲取node的指標
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes" | jq .
#獲取pod的指標
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/pods" | jq .

　　確保當前兩個命令能正確獲得指標

　　2、建立HPA物件

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: Java
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: serviceA
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 90
  - type: Resource
    resource:
      name: memory
      targetAverageValue: 200Mi

　　當serviceA的所有副本的CPU使用率值超過request限制的90%或者memory的使用率超過200Mi時會觸發自動動態擴容行為。而Pod數在2-10之間浮動。

六、總結

　　通過手工執行 kubectl scale 命令或者通過修改deployment的replicas數量，可以實現 Pod 擴容或縮容從而間接實現我們docker的擴容縮容。但如果僅止於此，顯然不符合 Google 對 Kubernetes 的定位目標 —— 自動化、智慧化。在 Google 看來，分散式系統要能夠根據當前負載的變化情況自動觸發水平擴充套件或縮容的行為。所以HPA就是這樣誕生了。而HPA也給我們提供了動態的擴縮容，讓我們服務更加具有彈