目录
步骤一:先基于deployment控制器创建pod,然后发布
一、常见的发布方式
- 蓝绿发布:两套环境交替升级,旧版本保留一定时间便于回滚
特点:对用户无感,是最安全的发布方式,需要两套系统,对资源要求比较高,成本高
- 灰度发布:根据比例将老版本升级,例如80%用户访问是老版本,20%用户访问是新版本
特点:对自动要求比较高,对比起来系统更加稳定发布,如果遇到问题可以减少影响范围
- 滚动发布:按批次停止老版本实例,启动新版本实例。
特点:节约资源,用户无感,但是部署和回滚的速度慢
三种方式均可以做到平滑式升级,在升级过程中服务仍然保持服务的连续性,升级对外界是无感知的。那生产上选择哪种部署方法最合适呢?这取决于哪种方法最适合你的业务和技术需求。
如果你们运维自动化能力储备不够,肯定是越简单越好,建议蓝绿发布如果业务对用户依赖很强,建议灰度发布。如果是K8S平台,滚动更新是现成的方案,建议先直接使用。
二、详解kubectl陈述式方式做灰度发布(金丝雀发布)
金丝雀发布(Canary Release)
Deployment控制器支持自定义控制更新过程中的滚动节奏,如"暂停(pause)"或"继续(resume)"更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程,此时,仅存在一部分新版本的应用,主体部分还是旧的版本。然后,再筛选一小部分的用户请求路由到新版本的Pod应用,继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新,否则立即回滚更新操作。这就是所谓的金丝雀发布。
步骤一:先基于deployment控制器创建pod,然后发布
kubectl -n testapp create deployment deploy-nginx --image=soscscs/myapp:v1 --port=80 --replicas=3
//创建pod
kubectl -n testapp expose deployment deploy-nginx --name svc-nginx --type NodePort --port=9090 --target-port=80
//首次发布
curl 10.96.241.117:9090
//基于clusterip访问
curl 192.168.20.15:32295
//基于nodeip:nodeport访问
步骤二:基于命令行灰度发布
kubectl -n testapp set image deployment deploy-nginx myapp=soscscs/myapp:v2 && kubectl -n testapp rollout pause deployment deploy-nginx
//灰度发布,更新版本为v2,然后停止回滚
//因为deployment的默认回滚策略是滚动更新,那么停止就会在第一波更新的时候 停止回滚
//监控更新的过程,可以看到已经新增了一个资源,但是并未按照预期的状态去删除一个旧的资源,就是因为使用了pause暂停命令
kubectl -n testapp get pod -o wide -w
步骤三:测试等到版本稳定以后,再完成继续发布
kubectl -n testapp expose pod deploy-nginx-7cb95f9469-x8rp2 --name svc-nginx-v2
//基于更新的pod创建一个默认的clusterip类型的svc
kubectl -n testapp expose pod deploy-nginx-7cb95f9469-x8rp2 --name svc-nginx-nodeport-v2 --type NodePort --port=7070 --target-port=80
//基于更新的pod创建一个默认的nodeport类型的svc
//查看最后的更新情况
kubectl -n testapp get pod -o wide -w
kubectl -n testapp rollout resume deployment deploy-nginx
//等待版本稳定的时候 继续更新
三、滚动发布详解
关于滚动发布的参数
deployment控制器更新Pod的方式是 RollingUpdate(滚动更新)
RollingUpdateStrategy(滚动更新策略): 25% max unavailable, 25% max surge
- Replicas: 3 desired 控制器的期望副本数
- **25% max surge 滚动更新时允许创建的最大副本数或比例,向上取整。**值调的越大,副本更新速度越快。
- 25% max unavailable 滚动更新时允许销毁的最大副本数或比例,向下取整。值越小,越能保证服务稳定,更新越平滑;
图解 滚动发布的过程
假设期望副本数是3,那么滚动更新时能够创建的副本数是 3 * 25% = 0.75 再向上取整为 1,能够销毁的副本数向下取整为 0
假设期望副本数是10,10 * 25% = 2.5 向上取整为 3 向上取整为 2
整个滚动更新过程中Pod副本数始终处在 (10-2)<= Pod副本数 <= (10+3)之间