1.前言

在kubernetes中，Pod是最基礎的排程單位，多個pod 可以組成一個集合，這個集合向外提供服務。這時候，我們需要以下兩種情形需要關注：

1）集合中的Pod可能會由於某種原因Fail，這時候需要某種機制能夠建立新的Pod以確保有足夠數量的Pod在執行。

2）Pod 的個數由訪問請求決定。即當前例項個數不足以滿足訪問請求時，需要增加例項個數，反之，需要通過某種策略減少例項數。

如果人工來實時監控例項的執行狀態，手動啟動新的pod以替代fail的pod，監控例項的負載情況，手動建立或者刪除pod，這個工作繁瑣且工作量大，好在kubernetes已經有相應的機制來應對這種變化。

2.概要

宣告： 這裡的介紹主要基於kubernetes官網的內容，您可以選擇

kubernetes 官網 閱讀更加詳細內容。

1）關於RelicationController 和 RelicaSet

簡單來說，這兩者的主要作用都是確保有指定的數量的Pod例項在執行，區別在於後者是前者的升級版。他們都會檢測Pod的個數，一旦某個pod fail，則啟動新的Pod，當然如果數量過多（fail的pod復活），則需要刪除某些例項。

這裡目前有兩種常見的使用場景。第一，通過一個RC（或RS）部署一個Pod，這種情形下，一個Pod fail，RS 會主動建立新的Pod來替換舊的Pod，反之，會刪除多餘的Pod，這也是一種高可用的方案。第二種，通過RS部署多個Pod，這種情形下，一旦某個Pod fail 掉，RS同樣會建立新的Pod來彌補，以確保總是有相同數目的pod在提供服務，不至於由於pod fail，應用的服務水平下降。

下面是一個RC的yaml定義檔案：

apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
 

這裡的replicas即需要維持的Pod個數，值得一提的是，這個個數是可以改變的，只需要修改這個檔案，然後執行替換操作即可，然後RS就會按照新的數量維護Pod個數。

這裡的template即Pod的定義，這個與建立單個pod的定義是一致的，事實上，這個配置會傳遞下去，通過這個配置建立pod。

在建立RS後，Pod 與 RS 是關聯到一起的。那麼如果刪除這個RS，Pod是否會存在呢? 預設是會刪除的，但是可以傳入引數加以控制。

You can delete a replication controller without affecting any of its pods.
Using kubectl, specify the --cascade=false option to kubectl delete.

最後，需要指出的是，RS 建立新的pod 依然會通過排程器來做排程，一旦排程失敗，則無法完成這個過程，新建立的pod一直處於pending狀態，直到有合適的Node供排程器排程。另外還有一種極特殊的情形，即建立RS的時候，在定義中指定了nodeName，這時候就不會經過排程器，這時候一旦這個Pod失敗，那麼RS不會通過排程器尋找合適的Node，依然會在當前的Pod上嘗試建立Pod，當然結果是Fail，於是很快會出現很多Fail狀態的Pod，這樣死迴圈下去，將會導致資源耗盡。

2）Horizontal Pod Autoscaling

關於HPA，官方解釋如下：

With Horizontal Pod Autoscaling, Kubernetes automatically scales the number of pods in a replication controller, deployment or replica set based on 
observed CPU utilization (or, with alpha support, on some other, application-provided metrics)

相信這個已經解釋非常清楚了，根據CPU的使用率來決定是否需要增加或減少例項。

插一句：據社群官方文件，社群正在積極尋求更多的方面考慮（如記憶體、I/O）與CPU一起決定增加或減少例項。官方已經給出了設計文件，這個設計文件涉及到相關的概念，演算法等各個方面：https://github.com/kubernetes/kubernetes/blob/master/docs/design/horizontal-pod-autoscaler.md

這張圖來自Kubernetes官方，形象地概括了通過HPA如何實現Auto Scale。這裡涉及到Deployment，我們後面再討論。HPA 最重要的使用場景在於Rolling Update。在虛擬化的時代，通常是多個虛擬機器組成的叢集，取出某個例項進行升級，然後放回叢集，再升級另一個，直到叢集中的所有例項升級完成才結束。我們的Pod與虛擬化中的虛擬機器比較類似，那麼HPA是如何升級的呢？

HPA會建立一個新的RS,原來的RS裡面會減少一個Pod，新的RS會增加一個Pod，這樣逐個Pod進行升級，直到所有的Pod都從原來的RS下升級到新的RS下，升級圓滿結束。

3.總結

Kubernetes 有很多有意思的特性值得去發掘，社群也有很多有意思的事情值得去做，希望大家多瞭解kubernetes，一起完善kubernetes，讓這個社群更強大。