kubernetes 降本增效标准指南｜理解弹性，应用弹性

弹性伸缩在云计算领域的简述

弹性伸缩又称自动伸缩，是云计算场景下一种常见的方法，弹性伸缩能够根据服务器上的负载、按必定的规则、进行弹性的扩缩容服务器。
弹性伸缩在不一样场景下的含义：

• 对于服务运行在自建机房的公司，弹性伸缩一般意味着容许一些服务器在低负载时进入睡眠状态，从而节省电费（以及用于冷却机器的水费和水费）。
• 对于使用在托管在云上的机房的公司而言，自动扩展可能意味着更低的费用，由于大多数云提供商都基于总使用量而不是最大容量进行收费。
• 即便对于不能在任何给定时间减小运行或支付的总计算能力的公司，它们也能够在低流量时下降服务器的负载。
• 弹性伸缩解决方案还能够用来替换异常状态的实例，从而在必定程度上防止硬件，网络和应用程序故障。
• 在生产工做负载常常变化且不可预测的状况下，弹性伸缩能够提供更长的正常运行时间和更高的可用性。

引用自：https://zh.wikipedia.org/wiki/%E5%BC%B9%E6%80%A7%E4%BC%B8%E7%BC%A9

弹性伸缩的三大关键要素

1. 基于什么特征和属性

弹性伸缩，顾名思义某种机制可以让某些对象进行弹性的扩容和缩容。在云计算和容器相关领域也有较多的关于弹性伸缩的能力，有基于系统负载进行弹性扩缩容的，有基于业务日志进行弹性扩缩容的，也有基于资源预申请进行弹性扩缩容的。最经常使用的主要有如下记录：

1. 基于系统负载指标扩缩容对象

• 使用场景：当您的应用程序承担更多负载时，每每须要更多的 CPU 和内存资源，这时您能够设置一个 CPU 和内存利用率的指标，系统会自动设置副本数以动态承担不一样的负载状况，防止资源利用率太低的资源浪费或负载太高时应用程序没法承担。
• 限制：有时应用的负载变高但 CPU 和内存的利用率并无很高，这时基于系统负载指标扩缩容是无效的。而且具体使用哪种系统负载指标，以及利用率的阈值设定都是比较须要经验的。

2. 基于业务日志扩缩容对象

• 使用场景：业务的日志有专门记录和存储，而且能够经过日志分析获得当前应用的实际负载状况，这时能够根据业务的日志自动扩缩容。
• 限制：须要拥有日志存储和分析工具；日志信息量广泛很大，基于日志的弹性扩缩容易误判、漏判。

3. 基于资源请求扩缩容对象

• 使用场景：当有些应用不适合水平扩缩容时，此时能够经过调整对资源的请求量来实现扩缩容。相较方式1是扩容副本数实现水平扩缩容，此时扩容的是容器对资源的请求量，属于垂直扩缩容。
• 限制：当前这种方式须要重建容器，可能会引起服务的中断；而且垂直扩容依赖当前容器运行的节点容量大小，若是节点自己没有剩余资源，也没法实现垂直扩容。

4. 基于事件扩缩容对象

• 使用场景：例如当您的业务须要处理 Kafka 消息队列中的任务时，Kafka 中每多一条 topic，须要生成一个新的副原本处理这个 topic；或者数据库每多一条任务数据，会自动生成一个新的副原本承载这个任务。
• 限制：彻底依赖事件的触发，但事件自己处理时长有长有段，负载程度有高有低，彻底相同的副本没法灵活应对。
  固然还能够用其余的特征和属性进行扩缩容对象，这里也未所有枚举，具体业务使用弹性伸缩，按需选择不一样的特征和属性，特征和属性则是弹性伸缩的基础。

2. 根据什么策略

基于上述的特征和属性得到了数据以后，那么就须要必定的策略和判断规则。 总结来讲就是：

1. 上述的特征和属性在什么状况和边界下或进行扩容、扩多少、扩什么对象、怎么个扩法？
2. 上述的特征和属性在什么状况和边界下或进行缩容、缩多少、缩什么对象、怎么个缩法？

举个 kubernetes Cluster AutoScaler 的例子：
在腾讯云容器服务里节点的缩容策略：

1. CA（Cluster Autoscaler）监测到利用率（取 CPU 利用率和 MEM 利用率的最大值）低于设定的节点。计算利用率时，能够设置 Daemonset 类型不计入 Pod 占用资源。

2. CA 判断集群的状态是否能够触发缩容，须要知足以下要求：

   • 节点空闲时长要求（默认10分钟）。
   • 集群扩容缓冲时间要求（默认10分钟）。

3. CA 判断该节点是否符合缩容条件。您能够按需设置如下不缩容条件（知足条件的节点不会被 CA 缩容）：

   • 含有本地存储的节点。
   • 含有 Kube-system namespace 下非 DaemonSet 管理的 Pod 的节点。说明：

4. CA 驱逐节点上的 Pod 后释放/关机节点（不会处理包年包月节点）。

   • 彻底空闲节点可并发缩容（可设置最大并发缩容数）。
   • 非彻底空闲节点逐个缩容。
     

上述就是 Kubernetes 对节点缩容的处理逻辑，也就是弹性伸缩三大关键要素的扩缩容策略部分。总结来讲，策略是决定弹性伸缩相关的能力是否足够匹配业务场景的最关键的部分。

3. 弹缩什么对象

弹性伸缩在云服务商上的服务对象每每就是服务器的数量，还有更多弹性伸缩的对象如：云服务器的资源配置（CPU/内存）、还能够是承载用户业务的 Kubernetes 里的 Pod、还能够是其余企业所须要使用的云产品，业务只要有按需使用云资源的诉求，随用随取的资源皆可成为弹性伸缩的对象。 云上弹性伸缩的本质和目的：就是对弹性伸缩对象的按需付费。

弹性跟云计算成本的关系

弹性伸缩能够下降哪些成本

腾讯云云原生团队后续计划推出云原生白皮书， 其中将会介绍来着 1000+ 企业在成本方面的经验总结， 总体分红了三个部分：理解成本->控制成本->优化成本。利用云的弹性伸缩是企业优化成本的三大方法之一。

一、弹性伸缩可下降 IT 设备成本

经过《降本增效｜容器化计算资源利用率现象剖析》中的调研分析，充分利用弹性伸缩能力，是提升资源利用率，下降资源成本的关键点之一，对比未使用弹性伸缩的状况下总体资源利用率可以提升20%、30%以上。
腾讯云原生团队提出了容器化资源利用率成熟度模型中的 level2 就是业务利用容器和云的弹性伸缩能力，结合 Kubernetes 的 HPA、VPA、CA 等能力，高峰扩容、空闲缩容，极大提升资源利用率。

二、弹性伸缩可提供运维效率、下降人员投入成本

未使用弹性伸缩的状况下，运维人员可能会碰到如下场景：
● 业务突增或 CC 攻击致使机器数量不足，以至您的服务无响应
● 按高峰访问量预估资源，而平时访问量不多达到高峰，形成投入资源浪费
● 人工守护及频繁处理容量告警，须要屡次手动变动

采用弹性伸缩，配置自动化后，既能够释放人员对资源的手动变动的投入成本， 还可让业务的稳定性进一步提升。

引用自：https://cloud.tencent.com/doc...

弹性伸缩影响成本关键点

一、弹性伸缩影响 IT 资源成本的关键点

1. 1 灵敏度

灵敏度能够用从触发扩缩容到实际将对象扩缩容完成的时间来衡量，时间越短、灵敏度越高。
灵敏度的提高对业务来讲不只仅是影响时间差的 IT 资源成本，还可能对业务某些场景起到关键性的做用。
灵敏度能够从 HPA 扩容速度、CluterAutoscler 扩容速度、业务扩容方式多维度进行提高。
灵敏度是腾讯云容器系列产品弹性伸缩功能的关键考核指标，从基础层重点考量弹性伸缩的速度，以节点扩展效率为例，TKE 经过节点池扩节点的时间实际测试数据以下：

测试方案：

1. 建立一个 TKE 集群，分别扩展50、100、200节点
2. 记录批量扩展从启动到完成初始化的时间
3. 释放新建立的节点
4. 重复测试5次，记录每一次批量扩展时间

批量添加50节点：

-	第1次	第2次	第3次	第4次	第5次
耗时	3分 16秒	3分 33秒	3分 59秒	4分 5秒3	3分 13秒

批量添加100节点批量添加200节点：

-	第1次	第2次	第3次	第4次	第5次
耗时	4分 55秒	5分 07秒	5分 02秒	5分 11秒	5分 10秒

固然从业务实际须要触发扩缩容到业务负载 Ready，在 Kubernetes 服务层面不只仅是节点的扩容一个部分，还涉及 Pod 的 HPA、监控或日志指标的采集分析效率等，腾讯云容器服务系列产品也将持续围绕提升弹性伸缩灵敏度建设弹性伸缩产品能力。

1.2 精确度

精确度在弹性伸缩领域主要意味着：在准确的时间进行扩缩容、扩缩数量准确、扩缩的对象属性精确（如云服务器的机型），精确度越高一样意味着越贴合业务，扩容不会扩得过大而致使成本的浪费，也不会扩的太小致使没有解决业务问题，一样缩容不缩的过多致使业务故障、不会缩的过下而形成资源浪费。
精确度跟扩缩容的策略和算法息息相关。
在 Kubenretes 服务上的精确度同灵敏度同样，也分散在各个弹性扩缩容的组件上，以 HPA 来举例，精确度主要的仍是其默认的扩缩容算法做表明，详情可参阅 Kubernetes 官网：
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

默认的 HPA 扩容策略，可以知足绝大数场景，但业务的场景更多，所以也出现了匹配业务熟悉具有更高精确度的对 Pod 进行扩缩容的组件如：
● 业务属性跟时间相关，经过 CronHPA (腾讯容器服务为 HPC 功能) 来控制更精确的扩缩容时间。
● 基于事件的自动扩缩容 KEDA ，经过替换指标的数据源来匹配业务的诉求如离线计算的场景。
● ......
相信社区后续在 Pod 级别的扩缩容上也还会出现愈来愈丰富的组件，以适配业务的多样的场景来提升弹性伸缩的精确度。

二、弹性伸缩影响运维成本的关键点

2.1 自动化程度

自动化的程度若是要经过一个可衡量的数值来参考，能够考虑选择运维或开发在IT资源管理上投入的时间，时间越少，自动化程度越高， 投入的时间越少，也意外着投入的人力成本越低。这里的时间还能够继续拆分到投入扩缩容 IT 资源的时间和对 IT 资源资源维护的时间如故障替换等。
想要提升弹性伸缩的自动化程度，理解弹性的基本工做原理是最基础的要求。下文也会详细展开 Kubenetes 服务下的几个基本的弹性伸缩组件的工做原理。
在理解弹性伸缩工做原理的基础上，企业每每会结合自身的运维平台，将弹性伸缩集成进去，成为运维系统的一部分，以结合业务的诉求。所以自动化也要求云服务商对弹性伸缩的可配置性、API 的易用性也有较高的要求，如若各位读者有使用腾讯云容器服务相关的弹性伸缩 API，欢迎各位给产品提供优质的建议。

2. 2 可观测性

之因此将弹性伸缩的可观测性单独做为一个影响运维成本的关键点，是由于当前 Kubernetes 的弹性伸缩的自动化还不能达到彻底脱离运维人员的状态，良好的可观测性能让负责 IT 管理的人员减小心智负担，让业务的运行更加透明。同时也让自动化没法处理的工做可以有更快人员介入处理。
可观测性包含对弹性伸缩对象的盘点和管理、弹性伸缩对象基本的系统指标、运行状态的监控、以及故障告警等等。
云厂商的产品包括腾讯云容器系列的产品都会提供一些基本的可观测性的产品能力，也能够采用社区的 Grafana 等仪表盘工具构建企业本身的可观测性平台。

是否全部业务都适用弹性伸缩

业务的扩容相对来说是一件低风险的事情，最大的影响是支出可能会增多，但对业务自己来讲是一件安全的事情。可是弹性伸缩不只有扩容，也有缩容。业务被缩容以后，针对下次的突发流量是否能快速扩容？特别是若是剩余资源被别的业务抢占，或云上的资源售罄的状况下，临时再扩容是一件风险比较大的事情。
业务的应用之间存在依赖关系时，一个应用扩缩容后，另外一个应用是否也该扩缩容？是否会有连锁反应？这些都是可能致使系统故障的风险点。
上面提到的弹性伸缩基于的特征和属性、策略、对象都有不少种，任何一种方式均可以弹性伸缩，到底哪个才是最好最适合的扩容方式？每每须要很是强的技术积累和经验，很难自动化。
使用弹性不当，致使帐单爆涨的案例比比皆是。要理解弹性伸缩工做的原理、才能更准确的使用弹性伸缩，下降业务成本，提升业务稳定性。建议使用 Kubernetes 弹性伸缩能力以前先详细阅读 Kubernetes 弹性伸缩相关官方文档或 Git 文档。

· ClusterAutoScaler: https://github.com/kubernetes...

· HPA: https://kubernetes.io/docs/ta...

· VPA：https://github.com/kubernetes...

Kubernetes 弹性领域仍存在的问题

灵敏度存在的问题

弹性伸缩须要监控到“变化”（这个变化指的是上面提到的弹性伸缩的特征和属性），才能根据提早制定的“策略”，对要操做的“对象”进行弹性伸缩。可是从实际业务流量的变高，到负载量“变化”，再到监控组件监控到负载量变化，到最后引起弹性扩缩容发生每每须要较长的时间。

此外，为了保证 Pod 高的 QoS，防止重要 Pod 被 Kubernetes 的调度器驱逐，用户会将容器设置相同的 Request 和 Limit，此时用户实际的资源使用率最多只有 100%。假设用户使用 HPA，且阈值设置为 90%，则每次扩容，副本数最多只能扩容到如今的 1/0.9=1.11 倍。假若此时流量忽然增大到必须使用如今两倍的资源量，即两倍的副本数，则须要扩容 8 次才能承载两倍的流量：（1（1.18）= 2.14），很明显这个扩容步骤过多，周期过长。

时间窗口的设置，当前 HPA 控制器中针对扩容和缩容分别有一个时间窗口，即在该窗口内会尽可能保证 HPA 扩缩容的目标副本数处于稳定的状态，其中扩容是3分钟，而缩容是5分钟。若时间窗口设置得较小，则副本数可能频繁变化致使集群状态不稳定；若时间窗口设置得较大，则扩缩容反应时间太慢，没法有效应对突发流量。

影响精确度的问题

扩容是有可能失败的，这对流量突发场景多是致命的，例如：云上的资源是有可能售罄的，此时没法扩容。

当前 Cluster Autoscaler 的节点扩缩容主要依赖 Pod 的 Pending 状况，数据过于单一，精度有待提升。而且 Pod 的 Pending 只查看已分配的资源请求和限制，而不是实际的资源使用状况，对业务方来讲，过分配置 Pod 是常见的作法，这些都影响着弹性伸缩的精度。

一个集群中存在多个规格的 CVM，扩容和缩容应优先处理哪一种规格的 CVM，例如：缩容大规格节点容易引起容器从新调度后的争抢饥饿，缩容小规格节点有可能致使集群最后仅剩下大规格节点。

自动化程度的问题

当前的弹性伸缩的各类方法还不够自动化，虽然最后能实现自动的弹性扩缩容，可是它仍是创建在前期大量的手工配置上面，这些配置须要很强的业务经验和积累，以及对 Kubernetes 各类弹性伸缩的深入理解。

以 HPA 为例，目前 TKE 已经支持了五大类共 30 个不一样的指标，了解更多详细内容请参见 TKE 自动伸缩指标说明，此外，TKE 还提供了使用自定义指标进行弹性伸缩的方法。这么多的指标该如何选择？那种指标才是最合适本身业务的指标？指标的数值设置成多少合适？副本数的变化范围该如何设置？这里都是影响弹性伸缩的关键因素。

可观测性的问题

什么时间由于什么事情形成了什么样的弹性扩缩容结果，这对现有的监控系统来讲，还须要作较多努力。由于现有的监控系统一般都是监控某一项指标，它能够监控副本数的变化，能够监控弹性伸缩对象的变化，也能够监控资源使用率的状况，甚至能够监控事件/日志等信息，可是把它们有机的结合在一块儿，互联互通倒是一件相对来说较为困难的事情，当前弹性伸缩的可观测性方面还须要人工聚合和分析多方面的监控数据，须要高度定制化，对运维人员来讲依旧是一件比较繁琐的事情。

其它问题

一、弹性维度

当前 HPA 监控的是 Pod 的指标，可是有些 Pod 里存在多个容器，主业务容器高负载的状况下，若是此时 sidecar 容器低负载，而且此 Pod 下全部容器的平均资源利用率低于引起扩容的阈值时，也没法引起扩容，配置的弹性伸缩无效。维度方面还有一个高维度的问题：一样以 HPA 为例，做用对象是 Pod 级别，但产品一般是以应用为中心，HPA 的弹性伸缩缺乏“联动效应”，例如一个 Pod 的扩缩容是否能够自动引起同一个应用下其它 Pod 的扩缩容？

二、驱逐选择

一个 Pod 资源利用率很低，若它的资源被弹性收缩后，资源被别的负载侵占，此时若是这个 Pod 负载忽然变高，但节点又没有剩余可用资源，是该驱逐该 Pod 仍是驱逐别的 Pod？

腾讯云容器服务弹性伸缩愿景介绍

咱们致力于依托腾讯云原生团队提供的各类弹性伸缩服务，帮助客户实现自动化的资源管理，减小人力维护成本以及资源浪费，提高弹性伸缩灵敏度、精确度、自动化、可观测性。具体可参照的 Kubernetes 降本增效标准指南系列的上一篇文章《资源利用率提高工具大全》。

欢迎广大读者试用而且提出您宝贵的建议。