背景
公司的容器雲平台需要新增應用的自動擴縮容的功能，以便能夠更加智能化的對應用進行管理。
Kubernetes官方提供了HPA（Horizontal Pod Autoscaling）資源對象。要讓我們部署的應用做到自動的水準的（水準指的是增減Pod副本數量）進行擴縮容，我們隻需要在Kubernetes叢集中建立HPA資源對象，然後讓該資源對象關聯某一需要進行自動擴縮容的應用即可。
HPA預設的是以Pod平均CPU使用率作為度量名額，也就是說，當應用Pod的平均CPU使用率高于設定的門檻值時，應用就會增加Pod的數量。CPU使用率的計算公式是：Pod目前CPU的使用量除以它的Pod Request（這個值是在部署
deployment時自己設定的）值。而平均CPU使用率指的就是所有Pod的CPU使用率的算術平均值。
Pod平均CPU使用率的計算需要知道每個Pod的CPU使用量，目前是通過查詢
Heapster擴充元件來得到這個值，是以需要安裝部署Heapster。
接下來我就将我們在Kubernetes叢集中部署Heapster的過程記錄下來，也會描述我們在部署過程中遇到的問題以及解決的方法，希望能夠幫助到也準備在Kubernetes叢集中部署Heapster的朋友。
Heapster成功部署之後，我們使用了性能測試工具對http應用做了壓力測試，以觀察HPA進行自動擴縮容時的實際效果。
部署過程
首先，我們在github中搜尋Heapster，會找到Kubernetes中的Heapster庫：
将這個庫clone到叢集的master節點中。
在Heapster目錄下運作指令kubectl create -f deploy/kube-config/standalone/Heapster-controller.yaml
理論上建立完成後會啟動三個資源對象，deployment、service、serviceaccount，此時Heapster應該就能夠為HPA提供CPU的使用量了。
此時為驗證Heapster是否可用，在叢集中部署一個HPA資源對象，關聯某個應用，并設定門檻值為90:
檢視這個HPA時我們可以看到，CURRENT的CPU使用率為，也就是說，HPA沒能從Heapster中取得CPU的使用量。
于是，我們用kubectl get pod –namespace=kube-system指令檢視Heapster的pod的運作情況，發現是拉取鏡像失敗的緣故。
打開部署Heapster的yaml檔案如下：
apiVersion: v1
kind: ServiceAccount
metadata:
name: Heapster namespace: kube-system
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: Heapster namespace: kube-system
spec:
replicas: 1 template:
metadata:
labels:
task: monitoring
k8s-app: Heapster
spec:
serviceAccountName: Heapster
containers: - name: Heapster
image: gcr.io/google_containers/Heapster-amd64:v1.4.0
imagePullPolicy: IfNotPresent
command: - /Heapster
- --source=kubernetes:https://kubernetes.default ---
apiVersion: v1
kind: Service
metadata:
labels:
task: monitoring
# For use as a Cluster add-on (https://github.com/kubernetes/kubernetes/tree/master/cluster/addons) # If you are NOT using this as an addon, you should comment out this line.
kubernetes.io/cluster-service: 'true'
kubernetes.io/name: Heapster
name: Heapster namespace: kube-system
spec:
ports: - port: 80
targetPort: 8082
selector:
k8s-app: Heapster 可以看到23行，鏡像是要從谷歌的gcr.io鏡像倉庫中拉取的，由于我們的叢集伺服器不能連通外網，是以鏡像當然就拉取失敗了。
此時，我們使用之前使用過的自己倉庫中的Heapster鏡像來替代此yaml檔案中使用的鏡像。
清除剛才部署失敗的資源對象後再次在Heapster目錄下使用指令：kubectl create -f deploy/kube-config/standalone/Heapster-controller.yaml
這個時候發現對應的資源對象都建立成功了，而且pod也成功運作了。
此時看HPA的情況如下：
此時問題沒有得到解決，雖然Heapster的pod運作起來了，但是HPA還是沒能取到CPU使用量的值。
現在的情況來看，此時還不能确定問題是在于Heapster安裝沒成功還是HPA沒能從Heapster中取得值。
是以，接下來就是要确定一下Heapster是否安裝成功了。
這個時候，我們想到去Heapster中的docs目錄下看看有沒有什麼debug的方法，也就是進入Heapster目錄下的docs中的debugging。
用curl指令對URL/api/v1/model/debug/allkeys 做取值，得到的結果如下：
然後再用kubectl describe hpa yce –namespace=yce指令來檢視HPA資源對象的詳情
Message中顯示，從Heapster擷取名額失敗。
此時結論就得出了，Heapster已經成功安裝，不過叢集無法從Heapster中擷取到監控資料。
好了，接下來我們決定再給Heapster換一個鏡像試試，有可能是我們的鏡像版本問題導緻與Kubernetes叢集不能協同工作。
在docker hub中搜尋到了版本為v1.2.0的Heapster鏡像，替換為此鏡像後再次建立資源對象。
建立成功後，驚喜出現了
可以看到，HPA已經可以從Heapster中取到值了。然後用kubectl top node指令檢視節點的名額，發現也可以取到值了。
對HPA關聯的應用做壓力測試
理論上Heapster已經安裝成功。為了驗證HPA是否可用，我們寫了一個簡單的http程式，名為helloworldhey。該程式就是做了一個自增整型變量1000次的循環。
将該程式打包成鏡像，部署對應的deployment和service資源對象，然後在叢集外部通過暴露的節點端口用性能測試工具ab對其進行壓力測試。可以看到結果如下：
可以看到，我這裡設定的門檻值為50%，也就是說，在平均CPU使用率超過50%時，HPA會對pod進行自動的擴容，也即是增加pod的數量，使增加後的pod總數量可以讓平均CPU使用率低于50%。可以看到此時的CPU使用率已經為110%，是以，理論上HPA應該自動的拉起2個pod來分擔CPU的使用量。看看pod的目前情況，結果如下：
可以看到此時共有三個pod，與預期的結果相同。
不過，可能有人會有疑問，為什麼最初建立的pod會重新開機多次？原因就在于Kubernetes在部署deployment時，每個pod都設定有requests與limits值，當該pod的CPU（或記憶體）使用量超過該limits值時，kubelet就會重新開機這個pod，由于在壓力測試的開始時刻隻有此一個pod，是以CPU使用量肯定是超過了這個limit值于是pod就被重新開機了。
至此，heapter就被部署成功且可以正常使用了。
本文轉自kubernetes中文社群-
在Kubernetes叢集中部署Heapster