摘要：它實現了中的橫向自動擴容。目前只支持針對使用度進行動態擴容。這個就是真正控制擴容的，其結構如下其中的是一個的引用，定義了自動擴容的配置允許的最大實例數，最小實例數，以及使用配額。這也是為了避免出現頻繁的擴容縮容。

最新一版的kubernetes release中我們看到了一個令人欣喜的特性：Autoscaling。它實現了replicationcontroller中pod的橫向自動擴容。以下是摘自官方文檔的相關內容：

自動擴容將通過一個新的resource（就像之前的pod，service等等）實現。目前只支持針對cpu使用度進行動態擴容。未來的版本中，將會實現基于另一個resource：metrics(這是說未來監控數據將會有一個更統一的展示？)

1.Scale subresource
Scale subresource是一個虛擬的resource，用來記錄擴容進度。其主要結構如下：

// represents a scaling request for a resource.
type Scale struct {
    unversioned.TypeMeta
    api.ObjectMeta

    // defines the behavior of the scale.
    Spec ScaleSpec

    // current status of the scale.
    Status ScaleStatus
}

// describes the attributes of a scale subresource
type ScaleSpec struct {
    // desired number of instances for the scaled object.
    Replicas int `json:"replicas,omitempty"`
}

// represents the current status of a scale subresource.
type ScaleStatus struct {
    // actual number of observed instances of the scaled object.
    Replicas int `json:"replicas"`

    // label query over pods that should match the replicas count.
    Selector map[string]string `json:"selector,omitempty"`
}

其中ScaleSpec.Replicas表示我們預定的集群實例數目標。ScaleStatus.Replicas表示當前實例數，ScaleStatus.Selector是一個選擇器，選擇對應的pods。

2.HorizontalPodAutoscaler
這個就是真正控制擴容的resource，其結構如下：

// configuration of a horizontal pod autoscaler.
type HorizontalPodAutoscaler struct {
    unversioned.TypeMeta
    api.ObjectMeta

    // behavior of autoscaler.
    Spec HorizontalPodAutoscalerSpec

    // current information about the autoscaler.
    Status HorizontalPodAutoscalerStatus
}

// specification of a horizontal pod autoscaler.
type HorizontalPodAutoscalerSpec struct {
    // reference to Scale subresource; horizontal pod autoscaler will learn the current resource
    // consumption from its status,and will set the desired number of pods by modifying its spec.
    ScaleRef SubresourceReference
    // lower limit for the number of pods that can be set by the autoscaler, default 1.
    MinReplicas *int
    // upper limit for the number of pods that can be set by the autoscaler.
    // It cannot be smaller than MinReplicas.
    MaxReplicas int
    // target average CPU utilization (represented as a percentage of requested CPU) over all the pods;
    // if not specified it defaults to the target CPU utilization at 80% of the requested resources.
    CPUUtilization *CPUTargetUtilization
}

type CPUTargetUtilization struct {
    // fraction of the requested CPU that should be utilized/used,
    // e.g. 70 means that 70% of the requested CPU should be in use.
    TargetPercentage int
}

// current status of a horizontal pod autoscaler
type HorizontalPodAutoscalerStatus struct {
    // most recent generation observed by this autoscaler.
    ObservedGeneration *int64

    // last time the HorizontalPodAutoscaler scaled the number of pods;
    // used by the autoscaler to control how often the number of pods is changed.
    LastScaleTime *unversioned.Time

    // current number of replicas of pods managed by this autoscaler.
    CurrentReplicas int

    // desired number of replicas of pods managed by this autoscaler.
    DesiredReplicas int

    // current average CPU utilization over all pods, represented as a percentage of requested CPU,
    // e.g. 70 means that an average pod is using now 70% of its requested CPU.
    CurrentCPUUtilizationPercentage *int
}

其中的ScaleRef是一個Scale subresource的引用，MinReplicas, MaxReplicas and CPUUtilization定義了自動擴容的配置（允許的最大實例數，最小實例數，以及cpu使用配額）。

3.HorizontalPodAutoscalerList
用于記錄一個namespace下的所有HorizontalPodAutoscaler。本質上是一個結構數組。

官方文檔給出的并不是算法， 而是實現步驟，整個自動擴容的流程是：
1.通過podselector找到要擴容的集群
2.收集集群最近的cpu使用情況（CPU utilization）
3.對比在擴容條件里記錄的cpu限額（CPUUtilization）
4.調整實例數（必須要滿足不超過最大/最小實例數）
5.每隔30s做一次自動擴容的判斷（這個日后應該會成為一個擴容條件的參數）

CPU utilization的計算方法是用cpu usage（最近一分鐘的平均值，通過heapster可以直接獲取到）除以cpu request（這里cpu request就是我們在創建容器時制定的cpu使用核心數）得到一個平均值，這個平均值可以理解為：平均每個CPU核心的使用占比。未來k8s會開放一個api直接獲取heapster收集到的監控數據。

真正的算法是：

A.
TargetNumOfPods = ceil(sum(CurrentPodsCPUUtilization) / Target)
ceil()表示取大于或等于某數的最近一個整數
舉個栗子：
我們有一個集群實例數是3 pods。cpu限額，即Target是每個pod分配1.1核，當cpu的使用度CurrentPodsCPUUtilization為1.1,1.4，1.3時，要擴容成多少個呢？
ceil（（1.1+1.4+1.3）/1.1）= 4
所以擴容成四個實例。

B.
由于啟動實例時cpu的使用度會陡增，所以自動擴容會等待一段時間以收集準確的運行時監控數據。每次擴容/縮容后冷卻三分鐘才能再度進行擴容，而縮容則要等5分鐘后。這是因為自動擴容使用保守的方法，盡可能滿足pods業務的正常使用，所以擴容的優先級要大于縮容。

C.
當滿足：
avg(CurrentPodsConsumption) / Target >1.1 或 <0.9
時才會觸發進行擴容/縮容。這也是為了避免出現頻繁的擴容縮容。

為了方便使用，建議采用相對（relative）的度量標準（如 90%的cpu資源）而不是絕對的標準（如0.6個cpu核心）來描述擴容條件。否則，當用戶修改pods的請求資源時還需要去修改這些絕對值。比如：我們創建一個集群時，podtemplate中的resource里填入了cpu為1，即最多分配一個cpu核心給該pod，如果在擴容條件中采用絕對標準，我們必須填一個小于1的數，否則這個條件根本不會被觸發。而當我們要修改分配的資源為0.8個核心時，又必須要修改擴容條件以確保其小于0.8。這就很麻煩了。

為了方便使用，在kubectl的cmd命令中加入了 creating/updating/deleting/listing 命令用來操作HorizontalPodAutoscaler

未來可能會加入像kubectl autoscale這樣的命令，對一個已經在跑的集群實時進行動態擴容。