KubernetesAutoscaling是怎么工作的
今天就跟大家聊聊有关Kubernetes Autoscaling是怎么工作的，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
创新互联基于成都重庆香港及美国等地区分布式IDC机房数据中心构建的电信大带宽，联通大带宽，移动大带宽，多线BGP大带宽租用,是为众多客户提供专业BGP机房服务器托管报价，主机托管价格性价比高，为金融证券行业服务器托管，ai人工智能服务器托管提供bgp线路100M独享，G口带宽及机柜租用的专业成都idc公司。
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。
Horizontal 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的使用门槛。
除此之外，Kubernetes本身是一个容器编排工具，并不提供管理流程，而Rainbond提供现成的管理流程，包括DevOps、自动化运维、微服务架构和应用市场等，可以开箱即用。
看完上述内容，你们对Kubernetes Autoscaling是怎么工作的有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。
标题名称：KubernetesAutoscaling是怎么工作的
分享路径：http://cdiso.cn/article/pehjee.html
