# 纯理论学习,可能对解决问题有那么一丝丝的帮助
#比例缩放是滚动更新策略的一种机制。主动触发
官方的解释如下:
当自动缩放器缩放处于上线进程(仍在进行中或暂停)中的 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
#这种命令输出结果是代表是有异常的,需要排除问题