Kubernetes Autoscaling是如何工做的？

Kubernetes Autoscaling是如何工做的？这是最近咱们常常被问到的一个问题。

因此本文将从Kubernetes Autoscaling功能的工做原理以及缩放集群时能够提供的优点等方面进行解释。

什么是Autoscaling

想象用水龙头向2个水桶里装水，咱们要确保水在装满第一个水桶的80%时，开始注入第二个水桶。解决方法很简单，只要在适当的位置在两个水桶间装置管道链接便可。而当咱们想要扩大装水量，咱们只须要用这种办法增长水桶便可。

一样的道理放在咱们的应用或者服务上，云计算的弹性伸缩功能可让咱们从手动调节物理服务器/虚拟机之中解放出来。那么把“水桶装水”和“应用消耗计算资源”相比较——

• 水桶 - 缩放单位 - 解释咱们缩放什么的问题
• 80%标记 - 缩放的度量和触发器 - 解释咱们何时缩放的问题
• 管道 - 实现缩放的操做 - 解释咱们怎样进行缩放的问题

咱们缩放什么？

在Kubernetes集群环境中，做为用户咱们通常会缩放两个东西：

Pods - 对于某个应用，假设咱们运行X个副本（replica），当请求超过X个Pods的处理量，咱们就须要扩展应用。而为了使这一过程无缝工做，咱们的Nodes应该由足够的可用资源，以便成功调度并执行这些额外的Pads；

Nodes - 全部Nodes的总容量表明咱们的集群容量。若是工做负载需求超过该容量，咱们就须要为集群增长节点，以确保有效调度和执行工做负载。若是Pods不断扩展，那么可能会出现节点可用资源即将耗尽的状况，咱们不得不添加更多节点来增长集群级别可用的总体资源；

何时缩放？

通常状况下，咱们会连续测量某个度量，当度量超过阈值时，经过缩放某个资源来对其进行操做。例如，咱们可能须要测量Pod的平均CPU消耗，而后在CPU消耗超过80％时触发缩放操做。

可是一个度量标准不适合全部用例，对于不一样类型的应用程序，度量标准可能会有所不一样——对于消息队列，处于等待状态的消息数量可能会被做为度量标准；对于内存密集型应用程序，内存消耗做为指标可能会更合适。若是咱们有一个业务应用，该应用每秒可处理给定容量窗格约1000个事务，那么咱们可能就会选用这个指标，并在Pods达到850以上时进行扩展。

以上咱们只考虑了扩展部分，可是当工做负载使用率降低时，应该有一种方法能够适度缩减，而不会中断正在处理的现有请求。

怎样进行缩放？

对于Pods，只需更改replication中副本的数量就能够了；而对于Nodes，咱们须要有办法调用云计算服务商的API，建立一个新实例并将其做为集群的一部分。

Kubernetes Autoscaling

基于以上理解，咱们来看看Kubernetes Autoscaling的具体实现和技术——

Cluster Autoscaler

Cluster Autoscaler（集群自动缩放器）用于动态缩放集群（Nodes），它的做用是持续监控Pods，一旦发现Pods没法被schedule，则基于PodConditoin进行扩展。这种方式比查看集群中即诶单的CPU百分比要有效不少。因为Nodes建立须要一分钟或更长时间（取决于云计算服务商等因素），所以Pods可能须要一些时间才能被Schedule。

在群集内，咱们可能有多个Nodes Pool，例如用于计费应用的Nodes Pool和用于机器学习工做负载的另外一个Nodes Pool。Cluster Autoscaler提供各类标记和方法来调整Nodes缩放行为，更多详情请查看https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md。

对于缩小（Scale down），Cluster Autoscaler会查看Nodes的平均利用率并参考其余相关因素，例如若是Pods（Pod disruption Budget）运行在没法从新调度的Node上，那么该Node没法从集群中移除。Custer Autoscaler提供了一种正常终止Nodes的方法，通常能够在10分钟内从新定位Pods。

Horizo​​ntal Pod Autoscaler（HPA）

HPA是一个控制循环，用于监视和缩放部署中的Pods。这能够经过建立引用部署/reolication controller的HPA object来完成。 咱们能够定义部署按比例调整的阈值及规模上下限。HPA最先版本GA（autoscaling/v1）仅支持CPU做为可监控的度量标准。当前版本HPA处于测试阶段（autoscaling/v2beta1）支持内存和其余自定义指标。一旦建立了HPA object而且它可以查询该窗格的指标，就能够看到它报告了详细信息：

$ kubectl get hpa
NAME               REFERENCE                     TARGETS  MINPODS MAXPODS REPLICAS AGE
helloetst-ownay28d Deployment/helloetst-ownay28d 8% / 60% 1       4       1        23h

咱们能够经过为Controller Manager添加Flags来对水平Pod Autoscaler进行一些调整：

• 利用Flags-horizontal-pod-autoscaler-sync-period肯定hPa对于Pods组指标的监控频率。默认的周期为30秒。
• 两次扩展操做之间的默认间隔为3分钟，能够Flags来控制-horizontal-pod-autoscaler-upscale-delay
• 两个缩小操做之间的默认间隔为5分钟，一样能够经过Flags来控制-horizontal-pod-autoscaler-downscale-delay

指标和云提供商

为了衡量指标，服务器应该在启用Kubernetes自定义指标（https://github.com/kubernetes/metrics）的同时，启用Heapster或启用API aggregation。API metrics server是Kubernetes1.9版本以上的首选方法。对于配置Nodes，咱们应该在群集中启用并配置适当的cloud provider，更多详情查看https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/。

一些插件

还有一些很不错的插件，好比——

• Vertical pod autoscaler https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
• addon-resizer https://github.com/kubernetes/autoscaler/tree/master/addon-resizer

总而言之，下次再遇到有人问“Kubernetes Autoscaling是如何工做的”？但愿这篇短文能对你们的解释有所帮助。

又到了广告时间

Kubernetes提出的一系列概念抽象，很是符合理想的分布式调度系统。但大量高难度技术概念，同时也造成了一条陡峭的学习曲线，直接拉高了Kubernetes的使用门槛。

好雨云开源PaaS Rainbond则将这些技术概念包装成为“Production-Ready”的应用，能够做为一个Kubernetes面板，开发者不须要特殊学习便可使用。包括本文中的弹性伸缩，Rainbond支持用户进行水平伸缩和垂直伸缩：）

除此以外，Kubernetes自己是一个容器编排工具，并不提供管理流程，而Rainbond提供现成的管理流程，包括DevOps、自动化运维、微服务架构和应用市场等，能够开箱即用。

进一步了解：https://www.goodrain.com/scene/k8s-docker

Rainbond Github：https://github.com/goodrain/rainbond