【kubernetes】关于k8s集群的资源发布方式（灰度/滚动发布）

目录

一、常见的发布方式

二、详解kubectl陈述式方式做灰度发布（金丝雀发布）

步骤一：先基于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）之间