k8s_deployment 以及灰度发布、滚动发布和蓝绿发布的零散笔记
deployment 可以简写为deploy
Deployment 相比与replicaSet 多出一些功能设定。
Deployment VS replicaSet
PS: 对比版本 1.18.0
| 项目 | Fields | Deployment | replicaSet |
|---|---|---|---|
| apiVersion | apps/v1 | apps/v1 | |
| metadata | 两者一致 | 两者一致 | |
| kind | Deployment | replicaSet | |
| spec | minReadySeconds | √ | √ |
| paused | √ | ||
| progressDeadlineSeconds | √ | ||
| replicas | √ | √ | |
| revisionHistoryLimit | √ | ||
| selector | √ | √ | |
| strategy | √ | ||
| template | √ | √ |
测试随笔
[root@test2 ~]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-deploy 2/2 2 2 23s
[root@test2 ~]# kubectl get rs
NAME DESIRED CURRENT READY AGE
myapp-deploy-65fb6c8459 2 2 2 33s
[root@test2 ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
myapp-deploy-65fb6c8459-8ncqg 1/1 Running 0 44s
myapp-deploy-65fb6c8459-sx72t 1/1 Running 0 44s
[root@test ~]# kubectl patch deploy/myapp-deploy -p '{"spec":{"replicas::5}}'
Error from server (BadRequest): unexpected EOF #看清格式
[root@test ~]# kubectl patch deploy/myapp-deploy -p '{"deploy":{"strategy":{"rollingUpdate":{"maxSurge":1,"maxUnavailiable":1}}}}'
deployment.apps/myapp-deploy patched (no change) #为甚么会有no change ？ 用patch就是死活不更新。请各位评论告知我原因，谢谢
Deploy中重要的字段 spec.strategy
- type : Can be “Recreate” or “RollingUpdate”. Default is RollingUpdate.滚动发布
- rollingUpdate: 仅在type为RollingUpdate时有效
- rollingUpdate.maxSurge 最大可超期望的节点数，百分比 10% 或者绝对数值 5
- rollingUpdate.maxUnavailable 最大不可用节点数，百分比或者绝对数值
灰度发布、滚动发布和蓝绿发布
**假设replicaSet=10 maxSurge &maxUnavailable不能同时为0 **
| 类型 | 描述 | maxSurge | maxUnavailable |
|---|---|---|---|
| 灰度发布 | 又名金丝雀发布。先极个别更新，通过后再一次全部更新 | 1或10% | 视对服务可用度的需求 |
| 滚动发布 | （部分更新，投入使用）* 直到全部更新完成 | 1| 视对服务可用度的需求 |
|
| 蓝绿发布 | 新旧版共存，靠切换流量完成更新 | 10 | 0 |
知识有限，欢迎评论指正，感谢。
Deploy的灰度发布初体验
- maxSurge=1 maxUnavailable=0 rs=5
[root@test2 ~]# kubectl set image deploy myapp-deploy myapp=ikubernetes/myapp:v2 && kubectl rollout pause deploy myapp-deploy
deployment.apps/myapp-deploy image updated
deployment.apps/myapp-deploy paused
[root@test ~]# kubectl get pods -w
NAME READY STATUS RESTARTS AGE
myapp-deploy-65fb6c8459-4gwnl 1/1 Running 0 12m
myapp-deploy-65fb6c8459-4jkw9 1/1 Running 0 12m
myapp-deploy-65fb6c8459-mrcqz 1/1 Running 0 12m
myapp-deploy-65fb6c8459-pqfxd 1/1 Running 0 12m
myapp-deploy-65fb6c8459-z9psx 1/1 Running 0 12m
myapp-deploy-559ff5c66-vm6hl 0/1 Pending 0 0s
myapp-deploy-559ff5c66-vm6hl 0/1 Pending 0 0s
myapp-deploy-559ff5c66-vm6hl 0/1 ContainerCreating 0 0s
myapp-deploy-559ff5c66-vm6hl 1/1 Running 0 1s
[root@test2 ~]# kubectl rollout resume deploy myapp-deploy #测试ok 继续更新
deployment.apps/myapp-deploy resumed
[root@test2 ~]# kubectl get rs -o wide #更新完成后可以看到两版rs
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
myapp-deploy-559ff5c66 5 5 5 7m28s myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=559ff5c66,release=canary
myapp-deploy-65fb6c8459 0 0 0 25m myapp ikubernetes/myapp:v1 app=myapp,pod-template-hash=65fb6c8459,release=canary
Deploy的滚动发布
- maxSurge=3 maxUnavailable=0 rs=5
- 其余与命令与灰度发布一致。 此例就是新版pod创建到maxSurge数值，然后停3个旧的。这样就是第一批的更新。
[root@test2 ~]# kubectl get rs -o wide -w
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
myapp-deploy-559ff5c66 5 5 5 77s myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=559ff5c66,release=canary
myapp-deploy-65fb6c8459 0 0 0 11m myapp ikubernetes/myapp:v1 app=myapp,pod-template-hash=65fb6c8459,release=canary
#以上是原来的2个rs，命令执行以后，v3版的rs出现（下面这行）
myapp-deploy-6b9865d969 3 0 0 0s myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
#没太明白为啥还要打印一行，可能是在停v2 rs中的pod? 请大神评论指教，感谢
myapp-deploy-6b9865d969 3 0 0 0s myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
#3个新版pod被创建，陆续变成ready状态
myapp-deploy-6b9865d969 3 3 0 0s myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-6b9865d969 3 3 1 2s myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-6b9865d969 3 3 2 2s myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-6b9865d969 3 3 3 2s myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
第二批？？？这算是手动更新？？ 恢复然后再暂停？ 从结果看是的
[root@test ~]# kubectl rollout resume deploy/myapp-deploy && kubectl rollout pause deploy/myapp-deploy
deployment.apps/myapp-deploy resumed
deployment.apps/myapp-deploy paused
[root@test ~]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
myapp-deploy 8/5 6 8 30m
#另外一台 kubectl get rs -o wide -w 新增的内容
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
#rs v2期望节点变成2个, 后续需要减少2个
myapp-deploy-559ff5c66 2 5 5 13m myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=559ff5c66,release=canary
#rs v3期望节点变成5个，后续需要增加2个
myapp-deploy-6b9865d969 5 3 3 12m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
#rs v2 运行的pod变成 2个
myapp-deploy-559ff5c66 2 5 5 13m myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=559ff5c66,release=canary
myapp-deploy-559ff5c66 2 2 2 13m myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=559ff5c66,release=canary
#rs v3 期望变成6， 随后v3的pod增至6 并且逐步变成ready状态，为什么是6？ 就因为maxSurge=3, 可以任性咯？ 结果对就好，无所谓了
myapp-deploy-6b9865d969 5 3 3 12m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-6b9865d969 6 3 3 12m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-6b9865d969 6 5 3 12m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-6b9865d969 6 5 3 12m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-6b9865d969 6 6 3 12m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-6b9865d969 6 6 4 12m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-6b9865d969 6 6 5 12m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-6b9865d969 6 6 6 12m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
第三次运行与第二次相同的命令， 也可以不再加上pause
NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR
#rs v3 期望=5 ， 减少1pod ； v2 期望变成0，停止剩余pod
myapp-deploy-6b9865d969 5 6 6 20m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-559ff5c66 0 2 2 21m myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=559ff5c66,release=canary
myapp-deploy-6b9865d969 5 6 6 20m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
myapp-deploy-559ff5c66 0 2 2 21m myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=559ff5c66,release=canary
myapp-deploy-559ff5c66 0 0 0 21m myapp ikubernetes/myapp:v2 app=myapp,pod-template-hash=559ff5c66,release=canary
myapp-deploy-6b9865d969 5 5 5 20m myapp ikubernetes/myapp:v3 app=myapp,pod-template-hash=6b9865d969,release=canary
Deploy的蓝绿发布
- maxSurge=5 maxUnavailable=0 rs=5
- 不赘述了
Deploy 退版初体验
[root@test2 ~]# kubectl rollout history deploy/myapp-deploy #检查历史版本
deployment.apps/myapp-deploy
REVISION CHANGE-CAUSE
1
2
[root@test2 ~]# kubectl rollout undo deploy/myapp-deploy # 退版，默认退回上一版，也可指定revision的值
deployment.apps/myapp-deploy rolled back
[root@test2 ~]# kubectl rollout history deploy/myapp-deploy #检查历史版本，版1消失
deployment.apps/myapp-deploy
REVISION CHANGE-CAUSE
2
3