文档章节

Kubernetes 弹性伸缩全场景解析 (一):概念延伸与组件布局

阿里云官方博客
 阿里云官方博客
发布于 07/18 15:07
字数 2634
阅读 432
收藏 6

传统弹性伸缩的困境

弹性伸缩是 Kubernetes 中被大家关注的一大亮点,在讨论相关的组件和实现方案之前。首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划与实际负载的矛盾。

如上图所示,蓝色的水位线表示集群的容量随着负载的提高不断的增长,红色的曲线表示集群的实际的负载真实的变化。而弹性伸缩要解决的就是当实际负载出现激增,而容量规划没有来得及反应的场景。

常规的弹性伸缩是基于阈值的,通过设置一个资源缓冲水位来保障资源的充盈,通常 15%-30% 左右的资源预留是比较常见的选择。换言之就是通过一个具备缓冲能力的资源池用资源的冗余换取集群的可用。

这种方式表面上看是没有什么问题的,确实在很多的解决方案或者开源组件中也是按照这种方式进行实现的,但是当我们深入的思考这种实现方案的时候会发现,这种方式存在如下三个经典问题。

1. 百分比碎片难题

在一个 Kubernetes 集群中,通常不只包含一种规格的机器,针对不同的场景、不同的需求,机器的配置、容量可能会有非常大的差异,那么集群伸缩时的百分比就具备非常大的迷惑性。假设我们的集群中存在 4C8G 的机器与 16C32G 的机器两种不同规格,对于 10% 的资源预留,这两种规格是所代表的意义是完全不同的。


特别是在缩容的场景下,通常为了保证缩容后的集群不处在震荡状态,我们会一个节点一个节点或者二分法来缩容节点,那么如何根据百分比来判断当前节点是处在缩容状态就尤为重要,此时如果大规格机器有较低的利用率被判断缩容,那么很有可能会造成节点缩容后,容器重新调度后的争抢饥饿。如果添加判断条件,优先缩容小配置的节点,则有可能造成缩容后资源的大量冗余,最终集群中可能会只剩下所有的巨石节点。

2. 容量的规划炸弹

还记得在没有使用容器前,是如何做容量规划的吗?一般会按照应用来进行机器的分配,例如,应用 A 需要 2 台 4C8G 的机器,应用 B 需要 4 台 8C16G 的机器,应用 A 的机器与应用 B 的机器是独立的,相互不干扰。到了容器的场景中,大部分的开发者无需关心底层的资源了,那么这个时候容量规划哪里去了呢?

在 Kubernetes 中是通过 Request 和 Limit 的方式进行设置,Request 表示资源的申请值,Limit 表示资源的限制值。既然 Request 和 Limit 才是容量规划的对等概念,那么这就代表着资源的实际计算规则要根据 Request 和 Limit 才更加准确。而对于每个节点预留资源阈值而言,很有可能会造成小节点的预留无法满足调度,大节点的预留又调度不完的场景。

3. 资源利用率困境

集群的资源利用率是否可以真的代表当前的集群状态呢?当一个 Pod 的资源利用率很低的时候,不代表就可以侵占它所申请的资源。在大部分的生产集群中,资源利用率都不会保持在一个非常高的水位,但从调度来讲,资源的调度水位应该保持在一个比较高的水位。这样才能既保证集群的稳定可用,又不过于浪费资源。

如果没有设置 Request 与 Limit,而集群的整体资源利用率很高这意味着什么?这表示所有的 Pod 都在被以真实负载为单元进行调度,相互之间存在非常严重的争抢,而且简单的加入节点也丝毫无法解决问题,因为对于一个已调度的 Pod 而言,除了手动调度与驱逐之外没有任何方式可以将这个 Pod 从高负载的节点中移走。那如果我们设置了 Request 与 Limit 而节点的资源利用率又非常高的时候说明了什么呢?很可惜这在大部分的场景下都是不可能的,因为不同的应用不同的负载在不同的时刻资源的利用率也会有所差异,大概率的情况是集群还没有触发设置的阈值就已经无法调度 Pod 了。

弹性伸缩概念的延伸

既然基于资源利用率的弹性伸缩有上述已知的三个问题,有什么办法可以来解决呢?随着应用类型的多样性发展,不同类型的应用的资源要求也存在越来越大的差异。弹性伸缩的概念和意义也在变化,传统理解上弹性伸缩是为了解决容量规划和在线负载的矛盾,而现在是资源成本与可用性之间的博弈。如果将常见的应用进行规约分类,可以分为如下四种不同类型:

1. 在线任务类型

比较常见的是网站、API 服务、微服务等常见的互联网业务型应用,这种应用的特点是对常规资源消耗较高,比如 CPU、内存、网络 IO、磁盘 IO 等,对于业务中断容忍性差。

2. 离线任务类型

例如大数据离线计算、边缘计算等,这种应用的特点是对可靠性的要求较低,也没有明确的时效性要求,更多的关注点是成本如何降低。

3. 定时任务类型

定时运行一些批量计算任务是这种应用的比较常见形态,成本节约与调度能力是重点关注的部分。

4. 特殊任务类型

例如闲时计算的场景、IOT 类业务、网格计算、超算等,这类场景对于资源利用率都有比较高的要求。

单纯的基于资源利用率的弹性伸缩大部分是用来解决第一种类型的应用而产生的,对于其他三种类型的应用并不是很合适,那么 Kubernetes 是如何解决这个问题的呢?

Kubernetes 的弹性伸缩布局

Kubernetes 将弹性伸缩的本质进行了抽象,如果抛开实现的方式,对于不同应用的弹性伸缩而言,该如何统一模型呢? Kubernetes 的设计思路是将弹性伸缩划分为保障应用负载处在容量规划之内与保障资源池大小满足整体容量规划两个层面。简单理解,当需要弹性伸缩时,优先变化的应该是负载的容量规划,当集群的资源池无法满足负载的容量规划时,再调整资源池的水位保证可用性。而两者相结合的方式是无法调度的 Pod 来实现的,这样开发者就可以在集群资源水位较低的时候使用 HPA、VPA 等处理容量规划的组件实现实时极致的弹性,资源不足的时候通过 Cluster-Autoscaler 进行集群资源水位的调整,重新调度,实现伸缩的补偿。两者相互解耦又相互结合,实现极致的弹性。

在 Kubernetes 的生态中,在多个维度、多个层次提供了不同的组件来满足不同的伸缩场景。如果我们从伸缩对象与伸缩方向两个方面来解读 Kubernetes 的弹性伸缩的话,可以得到如下的弹性伸缩矩阵。

  • cluster-autoscaler: kubernetes 社区中负责节点水平伸缩的组件,目前处在 GA 阶段 (General Availability, 即正式发布的版本)。
  • HPA: kubernetes 社区中负责 Pod 水平伸缩的组件,是所有伸缩组件中历史最悠久的,目前支持 autoscaling/v1、 autoscaling/v2beta1 与 autoscaling/v2beta2, 其中 autoscaling/v1 只支持 CPU 一种伸缩指标,在 autoscaling/v2beta1 中增加支持 custom metrics,在 autoscaling/v2beta2 中增加支持 external metrics。
  • cluster-proportional-autoscaler: 根据集群的节点数目,水平调整 Pod 数目的组件,目前处在 GA 阶段。
  • vetical-pod-autoscaler: 根据 Pod 的资源利用率、历史数据、异常事件,来动态调整负载的 Request 值的组件,主要关注在有状态服务、单体应用的资源伸缩场景,目前处在 beta 阶段。
  • addon-resizer: 根据集群中节点的数目,纵向调整负载的 Request 的组件,目前处在 beta 阶段。

在这五个组件中, cluster-autoscaler、 HPA、 cluster-proportional-autoscaler 是目前比较稳定的组件,建议有相关需求的开发者进行选用。

对于百分之八十以上的场景,我们建议客户通过 HPA 结合 cluster-autoscaler 的方式进行集群的弹性伸缩管理, HPA 负责负载的容量规划管理而 cluster-autoscaler 负责资源池的扩容与缩容。

最后

在本文中,和大家主要讨论的是在云原生时代下弹性伸缩概念的延伸,以及 Kubernetes 社区是如何通过解耦的方式通过多个转职的组件实现了两个维度的弹性伸缩,在本系列后面的文章中会为一一解析每个弹性伸缩组件的相关原理与用法。

原文链接
本文为云栖社区原创内容,未经允许不得转载。

© 著作权归作者所有

阿里云官方博客
粉丝 186
博文 1871
码字总数 4586630
作品 0
杭州
程序员
私信 提问
Kubernetes弹性伸缩全场景解读(二) - HPA的原理与演进

前言 在上一篇文章中,我们介绍了在Kubernetes在处理弹性伸缩时的设计理念以及相关组件的布局,在今天这篇文章中,会为大家介绍在Kubernetes中弹性伸缩最常用的组件HPA(Horizontal Pod Auto...

Mr_zebra
2018/11/30
46
0
Kubernetes 弹性伸缩全场景解析 (四)- 让核心组件充满弹性

前言 在本系列的前三篇中,我们介绍了弹性伸缩的整体布局以及HPA的一些原理,HPA的部分还遗留了一些内容需要进行详细解析。在准备这部分内容的期间,会穿插几篇弹性伸缩组件的最佳实践。今天...

zhaowei121
01/29
20
0
云原生应用 Kubernetes 监控与弹性实践

在刚刚结束的云原生领域顶会 KubeCon + CloudNativeCon + Open Source Summit(简称 KubeCon) 上,阿里云为全球用户分享阿里巴巴超大规模云原生落地实践、国内首个开放云原生应用中心 Cloud ...

阿里巴巴云原生
07/01
0
0
容器服务kubernetes弹性伸缩高级用法

前言 近期,阿里云容器服务kubernetes发布了cluster-autoscaler的支持,开发者可以通过页面简单快捷的配置节点的弹性伸缩,支持普通实例、GPU实例以及竞价实例帮助开发者实现架构弹性和运营成...

阿里云云栖社区
2018/09/19
0
0
阿里云ACP认证考试3000道题库全真模拟考试练习

阿里云ACP认证(Alibaba Cloud Certified Professional,ACP)是面向使用阿里云产品的架构、开发、运维类人员的专业技术认证。获得了阿里云ACP认证后,表示你已经掌握了阿里云的大部分产品知识...

chensuns
08/02
0
0

没有更多内容

加载失败,请刷新页面

加载更多

Executor线程池原理与源码解读

线程池为线程生命周期的开销和资源不足问题提供了解决方 案。通过对多个任务重用线程,线程创建的开销被分摊到了多个任务上。 线程实现方式 Thread、Runnable、Callable //实现Runnable接口的...

小强的进阶之路
昨天
6
0
maven 环境隔离

解决问题 即 在 resource 文件夹下面 ,新增对应的资源配置文件夹,对应 开发,测试,生产的不同的配置内容 <resources> <resource> <directory>src/main/resources.${deplo......

之渊
昨天
8
0
详解箭头函数和普通函数的区别以及箭头函数的注意事项、不适用场景

箭头函数是ES6的API,相信很多人都知道,因为其语法上相对于普通函数更简洁,深受大家的喜爱。就是这种我们日常开发中一直在使用的API,大部分同学却对它的了解程度还是不够深... 普通函数和...

OBKoro1
昨天
7
0
轻量级 HTTP(s) 代理 TinyProxy

CentOS 下安装 TinyProxy yum install -y tinyproxy 启动、停止、重启 # 启动service tinyproxy start# 停止service tinyproxy stop# 重启service tinyproxy restart 相关配置 默认...

Anoyi
昨天
2
0
Linux创建yum仓库

第一步、搞定自己的光盘 #创建文件夹 mkdir -p /media/cdrom #挂载光盘 mount /dev/cdrom /media/cdrom #编辑配置文件使其永久生效 vim /etc/fstab 第二步,编辑yun源 vim /ect yum.repos.d...

究极小怪兽zzz
昨天
6
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部