K8s 比例缩放(Proportional scaling)
纯理论学习,可能对解决问题有那么一丝丝的帮助比例缩放是滚动更新策略的一种机制。主动触发官方的解释如下:当自动缩放器缩放处于上线进程(仍在进行中或暂停)中的 RollingUpdate Deployment 时, Deployment 控制器会平衡现有的活跃状态的 ReplicaSet(含 Pod 的 ReplicaSet)中的额外副本, 以降低风险。这称为比例缩放(Proportional Sca
# 纯理论学习,可能对解决问题有那么一丝丝的帮助
#比例缩放是滚动更新策略的一种机制。主动触发
官方的解释如下:
当自动缩放器缩放处于上线进程(仍在进行中或暂停)中的 RollingUpdate Deployment 时, Deployment 控制器会平衡现有的活跃状态的 ReplicaSet(含 Pod 的 ReplicaSet)中的额外副本, 以降低风险。这称为 比例缩放(Proportional Scaling)。
目录
为什么要有比例缩放?
滚动更新的Deployment 支持同时运行应用程序的多个版本,当自动缩放器处于部署新版本的过程(进行中或暂停,为什么暂停,可能是失败或者手动暂停了)。决定每次扩容几个,关停几个RepolicaSet,降低风险。那么到底扩几个和关几个的?以什么比例作为依据?
使用场景?
-
正常更新场景
学习以下参数
RollingUpdateStrategy: 25% max unavailable, 25% max surge
max unavailable:更新过程中不可用数量比例
max surge:最大冗余,除当前数量外还可增加最大比例(最多125%)Events:中Message的输出
先看下面这一段输出:RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx:1.16.1
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailable
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-new (3/3 replicas created)
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
xx xx xx xx Scaledup replica set nginx-deployment-old to 3 #旧的要更新3个xx xx xx xx Scaledup replica set nginx-xx-new to 1 #因为参数“25% max surge”,首先生成只生成1个新的,总的运行数是4
xx xx xx xx Scaleddown replica set nginx-XX-old to 2 #又因为参数25% max unavailable,旧的减少一个,数值减少到2,总的运行数是3
xx xx xx xx Scaledup replica set nginx-XX-new to 2 #新的扩容到2个
xx xx xx xx Scaleddown replica set nginx-XX-old to 1 #旧的减少到1个
xx xx xx xx Scaledup replicaset nginx-XX-new to 3 #新的扩容到3个
xx xx xx xx Scaleddown replica set nginx-XXold to 0 #按此进行,直至完成从Events:的messages信息输出中,可以看出更新是按照比例进行的。
-
Deployment被暂停的场景
因为RollingUpdate 的 Deployment 支持同时运行应用程序的多个版本的能力(我在这里复制粘贴了官方的示例)
例如,你正在运行一个 10 个副本的 Deployment,其 maxSurge=3,maxUnavailable=2。
确保 Deployment 的这 10 个副本都在运行。
kubectl get deploy
输出类似于:
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 10 10 10 10 50s
更新 Deployment 使用新镜像,碰巧该镜像无法从集群内部解析。
kubectl set image deployment/nginx-deployment nginx=nginx:sometag
输出类似于:
deployment.apps/nginx-deployment image updated
镜像更新使用 ReplicaSet
nginx-deployment-1989198191
启动新的上线过程, 但由于上面提到的maxUnavailable
要求,该进程被阻塞了。检查上线状态:kubectl get rs
输出类似于:
NAME DESIRED CURRENT READY AGE nginx-deployment-1989198191 5 5 0 9s nginx-deployment-618515232 8 8 8 1m
#New nginx-deployment-1989198191 为什么DESIRED、CURRENT的值是5
#因为maxSurge=3,nginx-deployment-1989198191更新第一步生成3个,这样总数就是13个。
#再根据maxUnavailables=2,nginx-deployment-618515232减去2个,总数11个
#nginx-deployment-1989198191第二步更新只能扩容2个,保证总数是13个。
为什么更新到第二步就不更新了,我也没想明白,可能我这个推论就是错误的,以后有时间再研究一下
#Deployment可以确保所创建pod数量比期望值高(默认情况,最多多出125%)
#Old nginx-deployment-618515232 为什么DESIRED、CURRENT、READY的值变成8了,因为maxUnavailables=2。#10个运行中的减去2个最大不可运行的
- 然后,出现了新的 Deployment 扩缩请求。自动缩放器将 Deployment 副本增加到 15。 Deployment 控制器需要决定在何处添加 5 个新副本。如果未使用比例缩放,所有 5 个副本 都将添加到新的 ReplicaSet 中。使用比例缩放时,可以将额外的副本分布到所有 ReplicaSet。 较大比例的副本会被添加到拥有最多副本的 ReplicaSet,而较低比例的副本会进入到 副本较少的 ReplicaSet。所有剩下的副本都会添加到副本最多的 ReplicaSet。 具有零副本的 ReplicaSet 不会被扩容。
#Eg:比例计算
#nginx-deployment-1989198191 的比例为 5 / (5 + 8) ≈ 0.385,追加的个数 5*0.385 ≈ 2
#nginx-deployment-618515232 的比例为 8 / (5 + 8) ≈ 0.615,追加的个数 5*0.615 ≈ 3在上面的示例中,3 个副本被添加到旧 ReplicaSet 中,2 个副本被添加到新 ReplicaSet。 假定新的副本都很健康,上线过程最终应将所有副本迁移到新的 ReplicaSet 中。 要确认这一点,请运行:
kubectl get deploy
输出类似于:
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 15 18 7 8 7m
#这种命令输出结果是代表是有异常的,需要排除问题
上线状态确认了副本是如何被添加到每个 ReplicaSet 的。
kubectl get rs
输出类似于:
NAME DESIRED CURRENT READY AGE nginx-deployment-1989198191 7 7 0 7m nginx-deployment-618515232 11 11 11 7m
#这种命令输出结果是代表是有异常的,需要排除问题
更多推荐
所有评论(0)