kubernetes---扩/缩容插件及调度器插件

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
的值。