Kubernetes 弹性伸缩全场景解读(二)- HPA 的原理与演进

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
可观测可视化 Grafana 版,10个用户账号 1个月
简介: 前言在上一篇文章 Kubernetes 弹性伸缩全场景解析 (一):概念延伸与组件布局中,我们介绍了在 Kubernetes 在处理弹性伸缩时的设计理念以及相关组件的布局,在今天这篇文章中,会为大家介绍在 Kubernetes 中弹性伸缩最常用的组件 HPA(Horizontal Pod Autoscaler)。

前言

在上一篇文章 Kubernetes 弹性伸缩全场景解析 (一):概念延伸与组件布局中,我们介绍了在 Kubernetes 在处理弹性伸缩时的设计理念以及相关组件的布局,在今天这篇文章中,会为大家介绍在 Kubernetes 中弹性伸缩最常用的组件 HPA(Horizontal Pod Autoscaler)。HPA 是通过计算 Pod 的实际工作负载进行重新容量规划的组件,在资源池符合满足条件的前提下,HPA 可以很好的实现弹性伸缩的模型。HPA 到目前为止,已经演进了三个大版本,本文将会为大家详细解析 HPA 底层的原理以及在 Kubernetes 中弹性伸缩概念的演变历程。

HPA 基本原理

HPA 是根据实际工作负载水平伸缩容器数目的组件,从中可以提炼出两个非常重要的关键字:负载数目。我们可以用一个非常简单的数学公式进行归纳:


下面举一个实际例子进行上述公式的阐述。
假设存在一个叫 A 的 Deployment,包含3个 Pod,每个副本的 Request 值是 1 核,当前 3 个 Pod 的 CPU 利用率分别是 60%、70% 与 80%,此时我们设置 HPA 阈值为 50%,最小副本为 3,最大副本为 10。接下来我们将上述的数据带入公式中:

  • 总的 Pod 的利用率是 60%+70%+80% = 210%;
  • 当前的 Target 是 3;
  • 算式的结果是 70%,大于50%阈值,因此当前的 Target 数目过小,需要进行扩容;
  • 重新设置 Target 值为 5,此时算式的结果为 42% 低于 50%,判断还需要扩容两个容器;
  • 此时 HPA 设置 Replicas 为 5,进行 Pod 的水平扩容。

经过上面的推演,可以协助开发者快速理解 HPA 最核心的原理,不过上面的推演结果和实际情况下是有所出入的,如果开发者进行试验的话,会发现 Replicas 最终的结果是 6 而不是 5。这是由于 HPA 中一些细节的处理导致的,主要包含如下三个主要的方面:

  1. 噪声处理

通过上面的公式可以发现,Target 的数目很大程度上会影响最终的结果,而在 Kubernetes 中,无论是变更或者升级,都更倾向于使用 Recreate 而不是 Restart 的方式进行处理。这就导致了在 Deployment 的生命周期中,可能会出现某一个时间,Target 会由于计算了 Starting 或者 Stopping 的 Pod 而变得很大。这就会给 HPA 的计算带来非常大的噪声,在 HPA Controller 的计算中,如果发现当前的对象存在 Starting 或者 Stopping 的 Pod 会直接跳过当前的计算周期,等待状态都变为 Running 再进行计算。

  1. 冷却周期

在弹性伸缩中,冷却周期是不能逃避的一个话题,很多时候我们期望快速弹出与快速回收,而另一方面,我们又不希望集群震荡,所以一个弹性伸缩活动冷却周期的具体数值是多少,一直被开发者所挑战。在 HPA 中,默认的扩容冷却周期是 3 分钟,缩容冷却周期是 5 分钟。

  1. 边界值计算

我们回到刚才的计算公式,第一次我们算出需要弹出的容器数目是 5,此时扩容后整体的负载是 42%,但是我们似乎忽略了一个问题:一个全新的 Pod 启动会不会自己就占用了部分资源?此外,8% 的缓冲区是否就能够缓解整体的负载情况?要知道当一次弹性扩容完成后,下一次扩容要最少等待 3 分钟才可以继续扩容。为了解决这些问题,HPA 引入了边界值 △,目前在计算边界条件时,会自动加入 10% 的缓冲,这也是为什么在刚才的例子中最终的计算结果为 6 的原因。

HPA 的演进历程

在了解了 HPA 的基本原理后,我们来聊一下 HPA 的演进历程,目前 HPA 已经支持了 autoscaling/v1autoscaling/v1beta1 和 autoscaling/v1beta2 三个大版本。大部分的开发者目前比较熟悉的是autoscaling/v1 的版本,这个版本的特点是只支持 CPU 一个指标的弹性伸缩,大致的 yaml 内容如下:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

接下来我们再来看一下 v2beta1 与 v2beta2 的 yaml,会发现里面支持的 metrics 类型增加了很多,结构也复杂了很多。

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        kind: AverageUtilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      targetAverageValue: 1k
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: extensions/v1beta1
        kind: Ingress
        name: main-route
      target:
        kind: Value
        value: 10k
---
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

而这些变化的产生不得不提的是 Kubernetes 社区中对监控与监控指标的认识与转变。在 Kubernetes 中,有两个核心的监控组件 Heapster 与 Metrics Server。Heapster 是早期 Kubernetes 社区中唯一的监控组件,它所包含的功能很强大,通过采集 kubelet 提供的 metrics 接口,并支持监控数据的离线与归档。

大致的架构图如上:source 的部分是不同的数据来源,主要是 kubelet 的 common api 与后来提供的 summary api;processor 的作用是将采集的数据进行处理,分别在 namespace 级别、cluster 级别进行聚合,并创建新的聚合类型的监控数据;sink 的作用是数据离线与归档,常见的归档方式包括 influxdb、kafka 等等。Heapster 组件在相当长时间成为了 Kubernetes 社区中监控数据的唯一来源,也因此有非常多的和监控相关的组件通过 Heapster 的链路进行监控数据的消费。但是后来,Kubernetes 社区发现了 Heapster 存在非常严重的几个问题:

  • 强大繁多的 Sink 由不同的 Maintainer 进行维护,50% 以上的 Heapster Issues 都是关于 Sink 无法使用的,而由于 Maintainer 的活跃度不同造成 Heapster 社区有大量的 issues 无法解决;
  • 对于开发者而言,监控数据的类型已经不再是 CPU、Memory 这么简单的几个指标项了,越来越多的开发者需要应用内或者接入层的监控指标,例如 ingress 的 QPS、应用的在线活跃人数等等。而这些指标的获取是 Heapster 无法实现的;
  • Prometheus 的成熟让 Heapster 的生存空间不断被挤压,自从 Prometheus 被 CNCF 收录为孵化项目,Heapster 的不可替代地位被正式移除。

社区经过反思后,决定将监控的指标边界进行划分,分为 Resource、Custom 和 External 三种不同的 Metrics,而 Heapster(Metrics Server) 的定位就只关心 Resource 这一种指标类型。为了解决代码维护性的问题,Metrics Server 对 Heapster 进行了裁剪,裁剪后的架构如下:

去掉了 Sink 的机制,并将调用方式改为标准的 API 注册的方式,这样的好处是既精简了核心代码的逻辑又提供了替代的可能,也就是说此时 Metrics Server 也是可以替代的,只要实现了相同的 API 接口,并注册到 API Server 上,就可以替代 Metrics Server。
 
接下来我们解析一下三种不同的 Metrics 与使用的场景:

API 注释
Resource metrics.k8s.io Pod的资源指标,计算的时要除以Pod数目再对比阈值进行判断
Custom custom.metrics.k8s.io Object: CRD等对象的监控指标,直接计算指标比对阈值
Pods : 每个Pod的自定义指标,计算时要除以Pods的数目
External external.metrics.k8s.io External:集群指标的监控指标,通常由云厂商实现

其中 autoscaling/v2beta1 支持 Resource 与 Custom 两种指标,而 autoscaling/v2beta2 中增加了 External 的指标的支持。

最后

HPA 目前已经进入了 GA 阶段,在大体的功能上面不会进行过多的变化,目前社区的主要发力点在如何配置化的调整细节参数、丰富监控 adapter 的实现等等。在本文中,我们在概念上给大家介绍了 HPA 的一些原理以及发展的趋势,在下一篇文章中,我们会为大家讲解如何开启 v2beta1 与 v2beta2 的。

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
10天前
|
运维 Kubernetes Cloud Native
探索Kubernetes的大二层网络:原理、优势与挑战🚀
在云原生领域,Kubernetes (K8s) 已经成为容器编排的事实标准☁️📦。为了支撑其灵活的服务发现和负载均衡🔍🔄,K8s采用了大二层网络的设计理念🕸️。本文将深入探讨大二层网络的工作原理、带来的好处✨,以及面临的挑战和解决方案❗🛠️。
探索Kubernetes的大二层网络:原理、优势与挑战🚀
|
6月前
|
存储 Kubernetes 监控
基于Kubernetes的电商平台部署:实现高可用、弹性伸缩与容器化管理
基于Kubernetes的电商平台部署:实现高可用、弹性伸缩与容器化管理
|
6月前
|
存储 Kubernetes 负载均衡
【Kubernetes系统原理、核心资源、Pod原理与创建及生命周期管理、Job、Cronjob、Statefulset、Service负载均衡Ingress】
【Kubernetes系统原理、核心资源、Pod原理与创建及生命周期管理、Job、Cronjob、Statefulset、Service负载均衡Ingress】
355 2
|
5月前
|
Kubernetes 负载均衡 数据中心
史上最全干货!Kubernetes 原理+实战总结(全文6万字,90张图,100个知识点)(下)
史上最全干货!Kubernetes 原理+实战总结(全文6万字,90张图,100个知识点)
261 0
|
5月前
|
Kubernetes 应用服务中间件 nginx
史上最全干货!Kubernetes 原理+实战总结(全文6万字,90张图,100个知识点)(上)
史上最全干货!Kubernetes 原理+实战总结(全文6万字,90张图,100个知识点)
16565 23
|
4月前
|
存储 Kubernetes Docker
Kubernetes学习笔记-Part.03 Kubernetes原理
Part.01 Kubernets与docker Part.02 Docker版本 Part.03 Kubernetes原理 Part.04 资源规划 Part.05 基础环境准备 Part.06 Docker安装 Part.07 Harbor搭建 Part.08 K8s环境安装 Part.09 K8s集群构建 Part.10 容器回退
63 0
Kubernetes学习笔记-Part.03 Kubernetes原理
|
4月前
|
Kubernetes 监控 网络协议
k8s教程(service篇)-概念和原理(下)
k8s教程(service篇)-概念和原理(下)
67 0
k8s教程(service篇)-概念和原理(下)
|
4月前
|
Kubernetes 负载均衡 网络协议
k8s教程(service篇)-概念和原理(中)
k8s教程(service篇)-概念和原理
60 0
|
4月前
|
Kubernetes 负载均衡 Linux
k8s教程(service篇)-概念和原理(上)
k8s教程(service篇)-概念和原理(上)
66 0
|
4月前
|
运维 Kubernetes 调度
k8s 自身原理之高可用
k8s 自身原理之高可用

相关产品

  • 容器服务Kubernetes版