k8s_deployment 以及灰度发布、滚动发布和蓝绿发布的零散笔记
2024-05-17 08:13:25
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<x<（具体看更新的粒度） | 视对服务可用度的需求 |
| 蓝绿发布 | 新旧版共存，靠切换流量完成更新 | 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=canaryDeploy的滚动发布
- 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 <none>
2 <none>[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 <none>
3 <none>k8s_deployment 以及灰度发布、滚动发布和蓝绿发布的零散笔记相关推荐
- K8S的灰度发布、滚动更新、蓝绿发布
K8S灰度发布.蓝绿发布.滚动更新 一.简介 1.1灰度发布(金丝雀发布) 金丝雀发布一般是先发1台机器,或者一个小比例,例如2%的服务器,主要做流量验证用,也称为金丝雀 (Canary) 测试,国内 ...
- 金丝雀发布、滚动更新、蓝绿发布到底有啥区别
根据 2017 年的 DevOps 发展报告,高效能组织和低效能组织在软件交付的效率上有数量级上的差异.技术组织的软件交付能力是一种综合能力,涉及众多环节,其中发布是尤为重要的环节. 作为技术人员,大 ...
- 使用k8s实现灰度发布，金丝雀，蓝绿发布
介绍# Ingress-Nginx 是一个K8S ingress工具,支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试. Nginx Annotations 支持以下 ...
- 蓝绿发布、滚动发布、灰度发布，有什么区别？这下明白了
欢迎关注方志朋的博客,回复"666"获面试宝典 在项目迭代的过程中,不可避免需要"上线".上线对应着部署,或者重新部署:部署对应着修改:修改则意味着风险.目前有 ...
- 蓝绿发布、滚动发布、灰度发布，有什么区别？
点击上方"朱小厮的博客",选择"设为星标" 后台回复"书",获取 后台回复"k8s",可领取k8s资料 在项目迭代的过程 ...
- 为何互联网大厂都在采用蓝绿发布、滚动发布、灰度发布？
在互联网软件的生产过程中有一环是必不可少的,那便是部署.发布.通过把代码部署在特定环境中,再对外向用户发布新功能.早期的时候互联网刚刚发展起来,涌入互联网的网民还比较少,服务器资源也比较昂贵.紧张,这 ...
- 蓝绿发布，灰度发布及滚动发布
[README] 本文转自:理解蓝绿发布.灰度发布和滚动发布_Jitwxs的博客-CSDN博客_蓝绿发布和灰度发布的区别目前绝大多数公司的业务系统都是集群化部署,那么在新版本上线时,保证平滑稳定,尽量 ...
- 掌门1对1微服务体系Solar第1弹：全链路灰度蓝绿发布智能化实践
掌门教育自2014年正式转型在线教育以来,秉承"让教育共享智能,让学习高效快乐"的宗旨和愿景,经历云计算.大数据.人工智能.AR/VR/MR以及现今最火的5G,一直坚持用科技赋能教 ...
- No.184# 蓝绿发布实践回顾
0 缘起 随着蓝绿发布项目落地进入试运行,也对蓝绿发布项目做个简要回顾. 早在2022年初的时候效能.交易和中间件的同学就如何提高发布效率做过讨论,蓝绿发布当时也被提出.由于彼时有更重要的事情去落地, ...
最新文章
- CF982 C Cut 'em all!【树/DFS/思维】
- CentOS 6.3下rsync服务器的安装与配置[转]
- 利用可视化软件navicat对mysql进行语句查询的使用（增删改查）
- 不懂 ZooKeeper？没关系，这一篇给你讲的明明白白
- netsh winsock reset什么意思_IOS14.2rc是什么意思？ios14.2rc怎么样？[多图]-手机资讯...
- Android的线程使用来更新UI----Thread、Handler、Looper、Time...
- 【易实战】SpringCloud Greenwich架构概览深度详解
- Android 权限大全
- Axure产品设计软件视频教程大全
- SICK CLV650-6000固定式扫码枪参数配置
- 北京大学 计算机辅助翻译专业,北京大学计算机辅助翻译专业招生介绍
- 教你用Python写连连看外挂(滑稽)
- 七夕节表白3d相册制作
- leetcode | 回文数
- 《与大象共舞》读书笔记
- Julia(一)--Julia变量
- 重温了经典电视剧《大时代》
- SQL的语法与分类，语法示例+图片，贼吉尔详细！！！
- Postgresql源码（66）insert on conflict语法介绍与内核执行流程解析
- zao AI换脸，说说自己对人脸识别的一些理解