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/ ... AQ.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/con ... ders/

一些插件

还有一些很不错的插件,比如——


总而言之,下次再遇到有人问“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

0 个评论

要回复文章请先登录注册