k8s弹性伸缩概念以及测试用例

k8s弹性伸缩概念以及测试用例

本文原文出处:https://juejin.im/post/5c82367ff265da2d85330d4f

弹性伸缩式k8s中的一大亮点功能,当负载大的时候,你可以对应用进行扩容,提升pod的副本数来应对大量的流量,当负载小的时候可以对应用进行缩容,以避免资源浪费。也可以让应用自动的进行扩容和缩容,这一功能有用。例如当微博出现了一个话题时,这个时候人们都去访问,此时他的服务器将无法处理大量的流量访问,这个时候就需要扩容,而当这个话题不在新鲜时,人们的访问流量也就是降下来了,那么就需要对服务器进行缩容处理,来自动适应流量需求。

scale命令:扩容或缩容 Deployment、ReplicaSet、Replication Controller或 Job 中Pod数量

# 语法
kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)
# 将名为foo中的pod副本数设置为3。
kubectl scale --replicas=3 rs/foo
kubectl scale deploy/nginx --replicas=30
# 将由“foo.yaml”配置文件中指定的资源对象和名称标识的Pod资源副本设为3
kubectl scale --replicas=3 -f foo.yaml
# 如果当前副本数为2,则将其扩展至3。
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql
# 设置多个RC中Pod副本数量
kubectl scale --replicas=5 rc/foo rc/bar rc/baz

k8s提供了scale和autoscale来进行扩容和缩容。


现在对go-deployment进行扩容,结果如图

当访问量减少了就进行缩容

现在我不想手动的进行扩容和缩容了,我想实现让它当访问流量大的时候自动扩容,当访问流量小的时候自动缩容。这个时候autoscale出现了,利用他我们就可以实现自动扩容和缩容。

# 语法
kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]
# 使用 Deployment “foo”设定,使用默认的自动伸缩策略,指定目标CPU使用率,使其Pod数量在2到10之间
kubectl autoscale deployment foo --min=2 --max=10
# 使用RC“foo”设定,使其Pod的数量介于1和5之间,CPU使用率维持在80%
kubectl autoscale rc foo --max=5 --cpu-percent=80

到目前为止,k8s一共提供了2个不同维度的AutoScaler。如下图:

k8s把弹性伸缩分为两类:

  • 资源维度:保障集群资源池大小满足整体规划,当集群内的资源不足以支撑产出新的pod时,就会触发边界进行扩容
  • 应用维度:保障应用的负载处在预期的容量规划内

对应两种伸缩策略:

  • 水平伸缩

    • 集群维度:自动调整资源池规模(新增/删除Worker节点)
    • Pod维度:自动调整Pod的副本集数量
  • 垂直伸缩
    • 集群维度:不支持
    • Pod维度:自动调整应用的资源分配(增大/减少pod的cpu、内存占用)

其中最为成熟也是最为常用的伸缩策略就是HPA(水平Pod伸缩),所以下面以它为例来重点分析,官方文档在此:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

缩容扩容的基本流程为三大步骤:

1.采集监控指标

2.聚合监控指标,判断是否需要执行缩扩容

3.执行缩容扩容操作

HPA水平缩容扩容架构图

HPA的监控指标

根据官方文档的描述,HPA是使用巡检(Control Loop)的机制来采集Pod资源使用情况的,默认采集间隔为15s,可以通过Controller Manager(Master节点上的一个进程)的--horizontal-pod-autoscaler-sync-period参数来手动控制。

目前HPA默认采集指标的实现是Heapster,它主要采集CPU的使用率;beta版本也支持自定义的监控指标采集,但尚不稳定,不推荐使用

因此可以简单认为,HPA就是通过CPU的使用率作为监控指标的。

聚合算法

采集到CPU指标后,k8s通过下面的公式来判断需要扩容多少个pod

desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]

ceil表示向上取整,举个实际例子,假设某个服务运行了4个Pod,当前的CPU使用率为50%,预期的CPU使用率为25%,那么满足预期的实际Pod数量就是4 * (50% / 25%) = 8个,即需要将Pod容量扩大一倍,增加4个Pod来满足需求。

当然上述的指标并不是绝对精确的,首先,k8s会尽可能的让指标往期望值靠近,而不是完全相等,其次HPA设置了一个容忍度(tolerance)的概念,允许指标在一定范围内偏离期望值,默认是0.1,这就意味着如果你设置调度策略为CPU预期使用率 = 50%,实际的调度策略会是小于45%或者大于55%进行缩扩容,HPA会尽力把指标控制在这个范围内(容忍度可以通过--horizontal-pod-autoscaler-tolerance来调整)

需要注意的是:

  • 一是k8s做出决策的间隔,它不会连续地执行扩缩容动作,而是存在一定的cd,目前扩容动作的cd为3分钟,缩容则为5分钟
  • 二是k8s针对扩容做了一个最大限制,每次扩容的pod数量不会大于当前副本数量的2倍。

原文地址:https://www.cnblogs.com/jasonboren/p/11493347.html

时间: 2024-11-08 18:14:43

k8s弹性伸缩概念以及测试用例的相关文章

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

传统弹性伸缩的困境 弹性伸缩是Kubernetes中被大家关注的一大亮点,在讨论相关的组件和实现方案之前.首先想先给大家扩充下弹性伸缩的边界与定义,传统意义上来讲,弹性伸缩主要解决的问题是容量规划与实际负载的矛盾. 如上图所示,蓝色的水位线表示集群的容量随着负载的提高不断的增长,红色的曲线表示集群的实际的负载真实的变化.而弹性伸缩要解决的就是当实际负载出现激增,而容量规划没有来得及反应的场景. 常规的弹性伸缩是基于阈值的,通过设置一个资源缓冲水位来保障资源的充盈,通常15%-30%左右的资源预留

Kubernetes高级进阶之多维度弹性伸缩

**基于Kubernetes的多维度的弹性伸缩** 目录:2.1 传统弹性伸缩的困境2.2 kubernetes 弹性伸缩布局2.3 Node 自动扩容/缩容2.4 pod自动扩容/缩容 (HPA)2.5 基于CPU指标缩放2.6 基于prometheus自定义指标缩放 2.1 传统伸缩的困境从传统意义上,弹性伸缩主要解决的问题是容量规划与实际负载的矛盾蓝色水位线表示集群资源容量随着负载的增加不断扩容,红色曲线表示集群资源实际负载变化.弹性伸缩就是要解决当实际负载增加,而集群资源容量没来得及反应

深入玩转K8S之智能化的业务弹性伸缩和滚动更新操作

在上篇我们讲到了较为傻瓜初级的弹性伸缩和滚动更新,那么接下来我们来看看较为高级的智能的滚动更新.本节的知识点呢是K8S的liveness和readiness探测,也就是说利用健康检查来做更为智能化的弹性扩容和滚动更新. 那为什么说是比较智能化呢,因为在实际生产环境中会遇到这样那样的问题,比如:容器里面应用挂了或者说新启动的容器里面应用还没有就绪等等,所以说就需要进行探测来检验容器是否满足需求. 那么一般的检测分为几种,比如:进程检测.业务检测. 进程检测呢很好理解,也就是说通过检测容器进程来验证

Serverless 与容器决战在即?有了弹性伸缩就不一样了

作者 | 阿里云容器技术专家 莫源?本文整理自莫源于 8 月 31 日?K8s & cloudnative meetup 深圳场的演讲内容.关注"阿里巴巴云原生"公众号,回复关键词 "资料" ,即可获得 2019 全年 meetup 活动 PPT 合集及 K8s 最全知识图谱. 导读:Serverless 和 Autoscaling 是近些年来广大开发者非常关心的内容.有人说 Serverless 是容器 2.0,终有一天容器会和 Serverless 进行

DCOS中监控和弹性伸缩方案经验

监控的选型 我们的DCOS 主要是面向2种业务形态:互联网应用,NFV组件和相关的数据库.2种不同的业务虽然说都是跑在容器内部,但是其实需要监控的信息和指标都是各不相同.因此在选择监控方案的时候我们更多的考虑了多样性和可定制化方案,同时最重要的是反应速度和自动化的因素 我们的方案需要有告警和自动的弹性伸缩功能来保证业务的可靠性和健壮性. 去年有幸听取了Brian Christner对于容器监控的讲解,所以对他当时提出的cAdvisor+Prometheus+InfluxDB+Grafana 的方

基于Raft构建弹性伸缩的存储系统的一些实践

基于Raft构建弹性伸缩的存储系统的一些实践 原创 2016-07-18 黄东旭 聊聊架构 最近几年来,越来越多的文章介绍了 Raft 或者 Paxos 这样的分布式一致性算法,但主要集中在算法细节和日志同步方面的应用,但是呢,这些算法的潜力并不仅限于此,基于这样的分布式一致性算法构建一个完整的可弹性伸缩的高可用的大规模存储系统,是一个很新的课题,我结合我们这一年多以来在 TiKV 这样一个大规模分布式数据库的实践上谈谈其中的一些设计和挑战. 本次分享的主要内容是如何使用 Raft 来构建一个可

Kubernetes 弹性伸缩全场景解析(三) - HPA 实践手册

在上一篇文章中,给大家介绍和剖析了 HPA 的实现原理以及演进的思路与历程.本文我们将会为大家讲解如何使用 HPA 以及一些需要注意的细节. autoscaling/v1 实践 v1 的模板可能是大家平时见到最多的也是最简单的,v1 版本的 HPA 只支持一种指标 ——  CPU.传统意义上,弹性伸缩最少也会支持 CPU 与 Memory 两种指标,为什么在 Kubernetes 中只放开了 CPU 呢?其实最早的 HPA 是计划同时支持这两种指标的,但是实际的开发测试中发现:内存不是一个非常好

《云计算架构技术与实践》连载15:2.3.2~2.3.6 弹性伸缩、高性能、用户体验、高安全、高可靠

版权全部,未经华为书面许可,请勿转载或转发. 2.3.2 弹性伸缩 弹性伸缩要求以同样架构,支撑从最少几个计算与存储节点.到最大10万甚至是100万级的计算与存储节点集群规模,且保证数据中心容量扩展过程中的业务连续性及业务服务不中断,或中断时延最短. 这里的弹性伸缩扩展能力应该体如今: l  管理节点弹性伸缩能力. l  数据中心资源的弹性伸缩能力: l  所承载云租户业务的计算集群弹性伸缩能力: l  承载用户数据信息及系统卷镜像的存储集群的弹性伸缩能力 l  连接计算与存储集群资源的网络弹性

京东618:Docker扛大旗,弹性伸缩成重点

转载:http://www.infoq.com/cn/news/2015/06/jd-618-docker?utm_source=infoq&utm_medium=popular_widget&utm_campaign=popular_content_list&utm_content=homepage 不知不觉中,年中的618和年终的11.11已经成为中国电商的两大促销日,当然,这两天也是一年中系统访问压力最大的两天.对于京东而言,618更是这一年中最大的一次考试,考点是系统的扩展