[转帖]Kubernetes的垂直和水平扩缩容的性能评估

kubernetes,垂直,水平,性能,评估 · 浏览次数 : 0

小编点评

**实验结果** * **垂直自动扩缩容** * 响应时间非常接近服务时间(0.175秒) * 决策的精确性提供资源的灵活性 * 有足够数量的 Pods 来处理请求 * **水平自动扩缩容** * 响应时间非常接近服务时间(0.175秒) * 决策的精确性提供资源的灵活性 * 更高效地执行自动扩缩容决策 **结论** * **水平自动扩缩容**展现更高的效率,其决策的精确性提供资源的灵活性,以及更快的 Web 应用响应时间。 * **垂直自动扩缩容**在资源申请决策上则更加保守,因为它依赖于随时间增加置信因子的对数。 **其他** * 实验使用Kubernetes的默认配置,因此修改参数可能会产生不同的结果。 * 实验脚本生成负载并使用压测工具控制负载,以及创建多个场景来分析自动扩缩容方式的行为。 * 在本次的实验参数和场景下,水平自动扩缩容展现了更高的效率,其决策的精确性提供资源的灵活性,以及更快的 Web 应用响应时间。

正文

https://www.cnblogs.com/charlieroro/p/17009778.html

 

译自:Performance evaluation of the autoscaling strategies vertical and horizontal using Kubernetes

可扩展的应用可能会采用水平或垂直扩缩容来动态调整云端资源。为了帮助选择最佳策略,本文主要对比了kubernetes中的水平和垂直扩缩容。通过对 Web 应用程序进行综合负载测量实验,结果表明水平扩缩容的效率更高,对负载变化的响应更快,且对应用程序响应时间的影响更小。

简介

云服务的负载可能会随时间变动,为了实现可扩展,需要依据特定的指标(如CPU)来采取自动扩容策略,以此来扩大应用的处理能力。为此,我们需要均衡应用的QoS和云基础设施的开销,即量入为出。

当前有两种扩缩容类型:水平,即服务的数目会视负载的情况增加或减少;垂直,即服务的资源(CPU或内存)会视负载的情况增加或减少。但即使有了这两种方法,也没有明确定义的标准来决定使用哪种方法。此外,在性能和成本效益方面,还缺乏与垂直自动扩缩容相关的分析,以及如何与水平自动扩缩容进行比较。

因此,为了评估这两种方法的性能,我们使用kubernetes做了一个测量实验,并借助了一个压测工具,该工具可以以一种受控的方式向一个"busy-wait"应用发送请求,并根据负载发生变化后自动扩缩容决策的时间、每个决策上请求的 CPU 的容量以及应用响应时间的影响来对这些机制进行评估。

Kubernetes的自动扩缩容策略

k8s是一个基于Borg的开源项目,聚焦容器编排,并允许在集群中运行容器应用,同时简化了不同环境(生产、开发等)的配置。总之,k8s提供了一组物理和虚拟机(节点),其中,master负责控制和给worker节点分配任务。在k8s中,pod是节点上最小的可分配单元,一个pod可以打包一个或多个容器,并定义执行规则。需要注意的是,要确保节点能够有足够的资源去运行对应的pod。

为了在k8s中创建一个对象,需要创建一个包含所需规格的配置文件。K8s的对象可以用于不同的目的,如监控、网络配置、扩缩容等。因此,需要根据不同的目的来选择不同的类型。此处使用的类型是:

  • horizontal pod autoscaler
  • vertical pod autoscaler

Horizontal Pod Autoscaler

水平自动扩缩容的目的是降低或增加集群中的Pods数目,以便有效地利用资源并满足应用的需求。这种扩缩容方式围绕某些指标,如CPU、内存、自定义指标或外部指标(基于Kubernetes外部的应用负载)。[2] [3]

为了使用水平扩缩容,需要创建一个HorizontalPodAutoscaler配置文件,并定义一个CPU百分比使用限制,如果Pod的利用率达到该限制,则会创建出更多的副本。HPA每15s(可变)会校验是否需要创建新的Pods。

HPA 背后的算法基于 HPA 所watch的所有Pods的当前利用率的平均值(Uₐ),期望利用率(U𝒹),以及当前副本数量(Uₐ),因此可以根据如下格式进行计算:

 

Nd=Na(Ua/Ud)��=��∗(��/��)

 

为了更好地理解上述格式,我们假设如下场景:

  1. 一个集群中有5个副本(Nₐ = 5),平均利用率为限制100 milicores或0.1 CPU-core(U𝒹 = 100)。
  2. 在一个负载峰值之后,所有pods的平均利用率上升到200m(U𝒹 = 200)。
  3. 应用公式,得到N𝒹 = 5 * (200 / 100) = 10,其中N𝒹 = 10,就是在保证平均利用率为100m且兼顾到阈值的理想Pods数。

通过以上例子,可以看到HPA会将副本数翻倍,而不是每次仅创建一个副本,这种方式使得HPA非常精准。

HPA有一个默认的延迟(5分钟),在负载降低时进行缩容。该时间仅在利用率低于定义的利用率限制时才会开始计算。

Vertical Pod Autoscaler

垂直扩缩容的目的是增加或降低现有Pods分配的资源(CPU或内存)。在Kubernetes中,它会修改Pod请求的资源容量。[4]

为了使用这种方式,需要创建一个VerticalPodAutoscaler类型的对象,并指定需要自动扩缩容的deployment。这种方式包含3个主要的组件:

  • Updater:充当哨兵,校验Pods是否有做够的资源,否则会使用期望的资源来重启这些Pods。
  • Admission controller:和updater配合,定义合适的pod request资源容量。
  • Recommender:watch资源,基于过去或当前利用率,提供建议来扩大或缩小内存或CPU。

当前VPA提供了3种类型的Recommender

  1. Target:推荐理想的内存和CPU容量
  2. Upper bound:推荐request资源的上限值,如果request大于此限值,考虑到置信因子,将会缩小Pod的规模
  3. Lower bound:推荐request资源的下限值,如果request低于此限制,考虑到置信因子,将会扩大Pod的规模

置信因子是一种使VPA 在自动扩缩容决策上更加保守的一种方法。这种方式会用到如下变量:当前Pod request CPU(Rₐ),下限(Bₗ)及其置信因子 (aₗ),和上限 (Bᵤ)及其置信因子(aᵤ)。

Rₐ > (Bᵤ * aᵤ)时,VPA会减少资源规模,其中置信因子aᵤ会随着 Pod 启动时间的增加而增加,并缓慢收敛到1。上限的置信因子的计算式为aᵤ = (1 + 1/Δₜ),其中Δₜ是Pod创建以来的天数。

另一方面,当Rₐ < (Bₗ * aₗ)时VPA会增加资源规模,其中置信因子aₗ会随着 Pod 启动时间的增加而增加,并缓慢收敛到1。下限的置信因子的计算式为aₗ = (1 + 0.001/Δₜ)^-2。这样,通过置信因子,VPA可以快速做出决策。

为了更好地理解,假设一个pod当前的request CPU为Rₐ = 100,当前下限为Bₗ = 150,启动以来的时间为5分钟,将其转换为天,得到Δₜ = 5 /60/24 = 0.003472。下限的置信因子为aₗ = (1 + 0.001/0.00347)^-2 = 0.6,因此,可以看到100 < 150 * 0.6 ⇒ 100 < 90,结论为false,此时不会增加Pod的容量。为了重新创建Pod,置信因子最少应该为aₗ = 0.67,换句话说,大约需要7分钟才会重建。

验证环境

为了生成并分析实验结果,需要创建一个测试环境,并定义某种方式来生成资源利用率来触发自动扩缩容策略,所有实验都实现了自动化,并保存和组织实验数据。环境的架构和组件如下图所示:

image
  • Eventos: 事件
  • Aplicação: 应用
  • Legenda: 副标题
  • Green: 分配负载
  • Blue: 采集集群信息
  • Red: 日志存储

容器编排环境使用的是Minikube,生成负载采用的工具是Hey Benchmark Tool,它是使用Go编写的压测工具,能够并发大量请求,此外,它还包含所有所需的参数:

  • 定义了请求执行的时长
  • 定义了并行的workers数目
  • 定义了worker发送的请求速率

为了在Minikube中生成负载,我们开发了一个node.js web应用,该应用会暴露一个REST,其会调用一个busy-wait 函数,使服务在一定毫秒时间段内的CPU-core的利用率达到100%,从下图中可以看出,该函数接收一个服务时间,并在时间结束前让CPU保持繁忙。

image

评估场景

考虑到垂直扩缩容至少需要一个监控的Pod,因此为了保持配置相似,需要为每个扩缩容策略配置2个初始Pods。此外,每个Pod初始request的CPU为0.15 CPU-cores,限制为1.5CPU-cores。

在所有评估的场景中,服务时间(endpoint处理一个请求的时间)为常数S = 0.175 秒。负载强度受发送的请求速率(λ)以及并发的客户端(每秒发送一个请求)控制。实验的每个场景分为9个阶段,每个阶段包含不同的负载,每个阶段的执行时间为2分钟,每种场景的总执行时间为18分钟。

为了让每个阶段达到期望的CPU利用率,根据队列理论的运算规律定义了请求速率。根据利用率规律,流量强度定义为ρ = λ ∗ S。例如,达到2 cores利用率(ρ = 2)的服务时间为S = 0.1, 此时每秒请求速率为λ = ρ / S = 2 / 0.1 = 20。但如果该请求速率超过40,那么等式不再平衡,因为此时的负载的确需要4个cores。[5]

image

实验的阶段流程

如上图所示,请求速率为λ = 2(需要ρ = 0.35 CPU-cores);λ = 4 (需要 ρ = 0.7 CPU-cores); λ = 6 (需要 ρ = 1.05 CPU-cores); 和 λ = 8 (需要 ρ = 1.4 CPU-cores),因此,这些情景假设综合了以下几点:

  1. 第一种场景中λ = [2, 2, 4, 6, 8, 6, 4, 2, 2],以一种非激进的方式逐步增加或减少负载
  2. 第二种场景中λ = [2, 2, 8, 8, 8, 2, 2, 2, 2],突然增加负载,并保持3个阶段,然后在剩余的阶段中降低降到最低值
  3. 第三种场景中λ = [2, 2, 8, 8, 2, 2, 2, 2, 2],与第二种类似,但高负载持续时间更少
  4. 第四种场景中λ = [2, 2, 8, 2, 8, 2, 8, 2, 2],使用多个峰值负载

当定义好这些场景之后,就可以使用脚本自动化执行。

在实验执行过程中,Kubernetes API会提供评估所需的关键数据:1)CPU使用情况;2)autoscaler推荐值;3)Pod Request的CPU数。每10秒对这些数据进行一次检索,并保存到日志文件中。因此,使用这些信息,可以判断每个Pod request的CPU随时间的变化情况。

同时,每次执行脚本生成负载(使用Hey工具)时,也会将应用的指标保存到日志文件中,为测试提供应用的行为数据。

结论

每种自动扩缩容策略下都会执行者四种实验场景。每种方式的初始Pods数为2,每个Pod的CPU-core为0.15,并会随时间被扩缩容器所修改。图1和图2展示了实验过程中每个Pod的request CPU。虚线表示在负载的每个阶段达到100% 利用率所需的 CPU 容量。

image

图1:垂直扩缩容中每个Pod request的CPU

可以看到,在VPA中,重新分配资源是有延迟的,大部分时间停留在 CPU 容量低于所需的情况下(虚线下面的彩色条)。场景1的负载是逐步增加的,其自动扩缩容决策的延迟相对要大,而场景2、3的负载变化比较突然,其延迟也相对较低。场景4的负载峰值较短,只有在阶段8才出现了资源的申请,此外还可以看到,在进行扩容时,VPA request的CPU要大于所需的CPU,在缩容时,VPA也更加保守。

此外,即使在最后5个低强度的负载的阶段中,VPA也没有进行缩容,此时申请的资源要大于所需的资源。这种延迟背后的原因是出于该机制的置信因子,它需要更多的时间来提升推荐的可信度。此外,在某些时候出现3个Pod的原因是,在调整Pod时,VPA会使用期望的资源容量来创建一个新的Pod,并在新的Pod就绪之后结束掉老的Pod。因此,置信因子可以多次减少重建 Pods 带来的开销。

image

图2:水平扩缩容中每个Pod request的CPU

大部分情况下,HPA都能对工作负载的变化作出有效的反应(尽管请求的 CPU 略高于所需的 CPU)。当负载上升时,其平均扩容决策时间为40秒。

只有在所有场景的第3阶段,以及在场景1的第4和第5阶段中,CPU停留在所需值以下的时间持续了大约1分钟。

HPA能够在5分钟的延迟后进行缩容,而VPA则不会缩容。在场景4中,HPA超量request 了CPU资源,这对于处理短时间的峰值来说这是正向的,但长远来看,有可能会给基础设施成本带来一定影响。

image

图3:垂直和水平扩缩容下的应用响应时间

图3展示比较了每个场景下的负载阶段对 Web 应用程序所做请求的响应时间。每个框的中间线代表中间值,而点和三角形是每个阶段响应时间的平均值。

在所有场景下下,水平自动扩缩容展示的响应时间非常接近于服务时间(0.175秒),在负载量增加的几个阶段中,只有平均值和第三四分位数略大。另一方面,在各种阶段中,由于调整Pod存在延迟,垂直自动扩缩容展示的响应时间要远大于服务时间(无论平均值和四分位数)。

可以这么说,在使用默认配置对这两种自动扩缩容策略进行评估的过程中表明,HPA是更有效的,它可以更快响应负载的变化,并且有足够数量的 Pods 来处理请求,而 VPA 受到了调整 Pods延迟的负面影响。

总结

本次工作通过测量实验分析了Kubernetes中水平和垂直自动扩缩容的性能。为此,需要某种方式来生成负载并使用压测工具控制负载,以及创建多个场景来分析自动扩缩容方式的行为,主要关注响应时间、Pods的CPU request指标,以及自动扩容时间时间的时间。

从本次的实验中可以看到,水平自动扩缩容相对不保守,但对资源的调整也相对更高效。需要注意的是,这种精度是由水平pod自动扩缩容器算法的客观性决定的,该算法将请求的资源保持在已定义的资源使用限制的平均值内。

相比之下,垂直自动扩缩容在资源申请决策上则更加保守,因为它依赖于随时间增加置信因子的对数。可以得出,在较长时间的实验中,可以生成更多的pod执行的历史数据,垂直自动扩缩容将更有效地执行自动扩缩容决策。

在本次的实验参数和场景下,水平自动扩缩容展现了更高的效率,其决策的精确性提供了资源的灵活性,以及更快的 Web 应用响应时间。需要注意的是,在本次时间结束之时,垂直自动扩缩容还处理beta阶段,仍然会接受日常更新,因此未来有可能会在效率上有所提升。此外,本次实验使用了Kubernetes的默认配置,因此修改参数可能会产生不同的结果。

[1] Borg: The Predecessor to Kubernetes: https://kubernetes.io/blog/2015/04/borg-predecessor-to-kubernetes/

[2] Gandhi, A., Dube, P., Karve, A. et al. Model-driven optimal resource scaling in cloud. Softw Syst Model 17, 509–526 (2018). https://doi.org/10.1007/s10270-017-0584-y

[3] Horizontal Pod Autoscaler: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

[4] C. Liu, M. Shie, Y. Lee, Y. Lin, and K. Lai. Vertical/horizontal resource scaling mechanism for federated clouds. In 2014 International Conference on Information Science Applications (ICISA), pages 1–4, 2014. doi: 10.1109/ICISA.2014.6847479

[5] Daniel A. Menasce, Lawrence W. Dowdy, and Virgilio A. F. Almeida. Performance by Design: Computer Capacity Planning By Example. Prentice Hall PTR, USA, 2004. ISBN 0130906735.

本文来自博客园,作者:charlieroro,转载请注明原文链接:https://www.cnblogs.com/charlieroro/p/17009778.html

与[转帖]Kubernetes的垂直和水平扩缩容的性能评估相似的内容:

[转帖]Kubernetes的垂直和水平扩缩容的性能评估

https://www.cnblogs.com/charlieroro/p/17009778.html 译自:Performance evaluation of the autoscaling strategies vertical and horizontal using Kubernetes 可

[转帖]Kubernetes的Nginx Ingress 0.20之前的版本,upstream的keep-alive不生效

https://www.cnblogs.com/lizexiong/p/15358923.html 1说明 Kubernetes使用nginx-ingress-controller代理到集群内服务的请求,nginx所在的机器上上有大量的time-wait连接。 抓包发现nginx发起的到upstre

[转帖]Kubernetes-15:一文详解Pod、Node调度规则(亲和性、污点、容忍、固定节点)

https://www.cnblogs.com/v-fan/p/13609124.html Kubernetes Pod调度说明 简介 Scheduler 是 Kubernetes 的调度器,主要任务是把定义的Pod分配到集群的节点上,听起来非常简单,但要考虑需要方面的问题: 公平:如何保证每个节点

[转帖]Kubernetes-18:Dashboard安装及使用

https://www.cnblogs.com/v-fan/p/13950268.html Helm安装Dashboard 简介 Dashboard 是 kubernetes 的图形化管理工具,可直观的看到k8s中各个类型控制器的当前运行情况,以及Pod的日志,另外也可直接在 dashboard 中

[转帖]Kubernetes中的nodePort,targetPort,port的区别和意义(转)

原文https://blog.csdn.net/u013760355/article/details/70162242 https://blog.csdn.net/xinghun_4/article/details/50492041 1. nodePort 外部机器可访问的端口。 比如一个Web应用

[转帖]kubernetes Tcp流量可视化

https://www.cnblogs.com/charlieroro/p/16771739.html 使用k8spacket和grafana的node graph插件可以查看kubernetes pod的TCP相关信息,如connection、bytes、和duration。下面是接收和响应的字节

[转帖]kubernetes Tcp流量可视化

https://www.cnblogs.com/charlieroro/p/16771739.html 使用k8spacket和grafana的node graph插件可以查看kubernetes pod的TCP相关信息,如connection、bytes、和duration。下面是接收和响应的字节

[转帖]kubernetes限制pod的cpu和内存

http://www.5ityx.com/cate100/45070.html kubernetes限制pod的cpu和内存 1、在创建容器的配置文件中指定 spec: containers: - image: gcr.io/google_containers/serve_hostname imag

[转帖]k8spacket 和 Grafana 对 kubernetes 的 TCP 数据包流量可视化

https://devpress.csdn.net/k8s/62ff4fe47e66823466193b95.html 你知道你不看的时候你的k8s集群在做什么吗?谁与他建立 TCP 通信?他调用了谁,例如,来自第三方库? 使用k8spacket和Grafana,您可以可视化集群中的 TCP 流量。

[转帖]Kubernetes部署Minio集群存储的选择,使用DirectPV CSI作为分布式存储的最佳实践

Kubernetes部署Minio集群存储的选择,使用DirectPV CSI作为分布式存储的最佳实践 个人理解浅谈 1. 关于在kubernetes上部署分布式存储服务,K8s存储的选择 非云环境部署K8s Pod时存储的选择 在非云环境部署Kubernets时,一般采用的都是本地的直连式存储和文