1. 寫在前面

開始搭建一個k8s並不是多麼難的事情，但是要想把自己的應該部署到k8s中，
需要付出比較多的努力才行，特別是對於沒有接觸過容器的人來說。

對於有容器相關經驗的來講，部署一個應用相當簡單，不過，最好還是需要掌握一下
helm等這些工具，以使自己能達到事半功倍的效果。

綜合上述來說，當你打算在生產中使用k8s部署自己的服務時，你會發現實際上自己
在這方面還是有不少的盲點的，有一種“k8s其實也沒有多少功能的”的感覺。

其實，k8s是一個可擴充套件的架構，有許多外掛可以用來管理我們的應用。

2. 什麼是k8s外掛

簡言之，外掛的作用就是對k8s的功能進行一系列的擴充套件。例如：網路外掛：calico,
flannel, CoreDNS， k8s Dashboard。這些都是一些常見的、“必須的”外掛，因
為當我們使用k8s時，第一時間都會想到他們並且部署使用他們。

3. 與彈性伸縮相關的外掛

3.1 Cluster AutoScaler - CA

它可以按照叢集的使用率來擴/縮叢集中的節點。當叢集中存在Pending狀態的pod時
會自動執行scale up操作進行節點擴容；當叢集中有未使用的node時，會執行
scale down來減少節點的數量。

預設情況下閥值為0.5。可以通過--scale-down-utilication-threshold來設定。

具體示例：
假如你在aws上的叢集中有兩個虛擬機器例項組或自動擴/縮容的組，他們分別執行在
兩個不同的zone中(zone1和zone2)。你想要基於資源使用率來擴容叢集，但同時
也希望在這兩個zone中能夠有相同數量的node，為了避免人為的去設定每個zone
中的最大、最小值，你希望使用CA這外掛的能力能自動決定node的數量。

下面是一個例子，這個例子的作用是通過helm來部署CA以達到上面的效果

⚡ helm install --name autoscaler \
    --namespace kube-system \
    --set autoDiscovery.clusterName=k8s.test.akomljen.com \
    --set extraArgs.balance-similar-node-groups=true \
    --set awsRegion=eu-west-1 \
    --set rbac.create=true \
    --set rbac.pspEnabled=true \
    --set nodeSelector."node-role\.kubernetes\.io/master"="" \
    --set tolerations[0].effect=NoSchedule \
    --set tolerations[0].key=node-role.kubernetes.io/master \
    stable/cluster-autoscaler
 

詳情請參考

3.2 Horizontal Pod AutoScaler - HPA

它可以根據CPU的使用率、使用者自定義的metrics或應用級別提供的metrics來自動
擴/縮RC、RS、Deployment等控制器中的Pod的副本數。

在kubernetes中,HPA並不是什麼新奇的功能，但是近期由Banzai Cloud釋出的
HPA Operator可以極大
的簡化HPA的部署。

使用者使用上述operator時所需要做的就是在Deployment、StatefulSet等中宣告
HPA所需要的annotation即可，具體支援的annotaion列表請參考

其安裝過程比較簡單，在些不作介紹。

當上述operator安裝完成後，我們可以使用kubectl top pods從而方便的監控
pod中cpu、mem的使用情況。

需要注意的是，上述cpu、mem的使用情況是相對於spec.containers[].resources.requests
而言的，並不是指node上的所有的CPU。

3.3 Resizer

它是針對 metric server而設計一個外掛。當你在叢集中部署的pod越多時，你的metric
server所需要的資源就會越多。

Resizer以容器化方式部署在叢集中，用於監控Metric Server的deployment中的容器
並基於這個容器實現垂直伸縮。

3.4 Vertical Pod Autoscaler - VPA

要使用這個功能，需要為pod定義resources.limits和resources.requests。如果沒有
明確定義，那麼將會使用以下預設值：

resources.requests.cpu = 100m

requests是為kube-scheduler作為排程時的一個排程依據。

但是上述值的定義並不是一個容易的事情，往往需要由產品方進行合理的壓測後才能
給出。

如果使用VPA, 它就可以基於pod使用的資源動態的調整requests中的CPU和Memory
的值。

關於VPA有以下幾點需要說明一下：

• VPA不能與HPA同時使用
• 當pod的requests被改動後，pod將會被升級並重新啟動
• 叢集必須開啟MutationAdmissionWebhooks

4. 與排程相關的外掛

4.1 Descheduler

4.2 Rescheduler