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

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

本文原文出处:http://www.javashuo.com/article/p-bodjlnrv-ek.htmlmysql

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

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来进行扩容和缩容。sql

如今对go-deployment进行扩容,结果如图shell

当访问量减小了就进行缩容 如今我不想手动的进行扩容和缩容了,我想实现让它当访问流量大的时候自动扩容,当访问流量小的时候自动缩容。这个时候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把弹性伸缩分为两类:app

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

对应两种伸缩策略:oop

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

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

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

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倍。
相关文章
相关标签/搜索