目录
[4.实现金丝雀发布（Canary Release）](#4.实现金丝雀发布（Canary Release）)
1.常见的发布方式
蓝绿发布:两套环境交替升级，旧版本保留一定时间便于回滚
优点：用户无感知，部署和回滚速度较快；缺点：浪费资源成本较高
滚动发布:按批次停止老版本实例，启动新版本实例。
优点：节约资源；缺点：部署和回滚速度较慢
灰度发布(金丝雀发布):根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问是新版本
优点：保证整体系统稳定性，如果出现问题影响范围较小；缺点：自动化要求较高
2.滚动发布
滚动升级方式：
kubectl create -n xy101 deployment test01 --image=soscscs/myapp:v1 --port=80 --replicas=3
kubectl expose -n xy101 deployment test01 --name=svc-test1 --type=NodePort --port=8080 --target-port=80
#创建资源和service
kubectl describe -n xy101 deployments.apps test01
kubectl set image -n xy101 deployment test01 myapp=soscscs/myapp:v2
3.蓝绿发布
蓝绿升级方式：
通过切换负载均衡的流量来实现业务的切换
kubectl create -n xy101 deployment test1-v1 --image=soscscs/myapp:v1 --port=80 --replicas=3
kubectl expose -n xy101 deployment test1-v1 --name=svc-test1 --port=8080 --target-port=80 --type=NodePort
kubectl create -n xy101 deployment test1-v2 --image=soscscs/myapp:v2 --port=80 --replicas=3
deployment.apps/test1-v2 created
kubectl set -n xy101 selector svc svc-test1 'app=test1-v2'
kubectl describe -n xy101 svc svc-test1
kubectl set -n xy101 selector svc svc-test1 'app=test1-v1'
kubectl describe -n xy101 svc svc-test1 
4.实现金丝雀发布（Canary Release）
Deployment控制器支持自定义控制更新过程中的滚动节奏，如"暂停(pause)"或"继续(resume)"更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。
kubectl create -n xy101 deployment myapp-v1 --image=soscscs/myapp:v1 --port=80 --replicas=3
kubectl expose -n xy101 deployment myapp-v --name=svc-myapp --port=8080 --target-port=80 --type=NodePort
kubectl set image -n xy101 deployment myapp-v1 myapp=soscscs/myapp:v2 && kubectl rollout pause deployment myapp-v1 -n xy101 #kubectl rollout pause deployment myapp-v1 -n xy101 执行完前面的就暂停
kubectl get -n xy101 pods -o wide -w #监控状态
kubectl rollout status -n xy101 deployment myapp-v1 #观察更新状态
kubectl rollout resume -n xy101 deployment myapp-v1 && kubectl rollout pause -n xy101 deployment myapp-v1 #确保更新的pod没问题了，继续更新，还是指定更新一个如何暂停
kubectl rollout resume -n xy101 deployment myapp-v1 #确保更新的pod没问题了，继续更新，会一次性都更新结束
5.声明式管理方法
1.适合于对资源的修改操作
2.声明式资源管理方法依赖于资源配置清单文件对资源进行管理
资源配置清单文件有两种格式：yaml（人性化，易读），json（易于api接口解析）
3.对资源的管理，是通过事先定义在统一资源配置清单内，再通过陈述式命令应用到k8s集群里
4.语法格式：kubectl create/apply/delete -f xxxx.yaml（apply的作用创建并更新）
查看资源配置清单
kubectl get 资源类型 资源名称 -o yaml
解释资源配置清单
kubectl explain 资源名称.字段名称声明式修改资源配置清单并应用的两种方式：
离线修改：
cd -
mkdir day3
kubectl get -n xy101 svc svc-myapp -o yaml > svc.yaml
ls
vim svc.yaml #删除多余内容只保存下图展示
kubectl get -n xy101 svc
vim svc.yaml
#直接对导出的yaml文件进行修改
kubectl apply -f svc.yaml #进行更新操作，但是此时会报错，无法修改，因为该service资源不是通过该svc.yaml文件创建的因此无法更新会报错。
我们需要进行操作，将原先的service进行删除然后在进行更新
可以使用kubectl delete -n xy101 svc svc-myapp进行删除；也可以通过kubectl delete -f svc.yaml该命令直接删除，因为svc.yaml配置文件中已经定义了该资源的各种参数，直接指定这个文件删除即可
kubectl delete -f svc.yaml && kubectl apply -f svc.yaml #删除并更新
kubectl get -n xy101 svc 
vim svc.yaml
kubectl apply -f svc.yaml #此时这个service文件是通过这个yaml文件创建的，因此可以直接使用该命令进行更新操作
在线修改：
直接使用 kubectl edit service 资源名称 在线编辑资源配置清单并保存退出即时生效
PS：此修改方式不会对yaml文件内容修改
#但是此种方法并不是所有字段都能进行修改，若遇到 不能修改的字段，则直接选择离线模式进行修改
kubectl edit -n xy101 svc svc-myapp
进行修改，保存
通过声明式修改方式实现金丝雀发布(通过控制副本数实现)
重新创建资源、service
kubectl create -n xy101 deployment myapp-v1 --image=soscscs/myapp:v1 --port=80 --replicas=3
kubectl expose -n xy101 deployment myapp-v1 --name=svc-myapp --port=80 --target-port=80 --type=NodePort
kubectl get -n xy101 deployments.apps myapp-v1 -o yaml > deploy.yaml
vim deploy.yaml
修改9行 app: myapp-v2
98行 replicas: 1
92行 name: myapp-v2
115行 - image: soscscs/myapp:v2
kubectl apply -f deploy.yaml
kubectl get -n xy101 all
kubectl scale -n xy101 deployment myapp-v1 --replicas=2 && kubectl scale -n xy101 deployment myapp-v2 --replicas=2 #通过减少v1的副本数，增加v2的副本数，实现，执行后无问题在继续下一步
kubectl get -n xy101 all
kubectl scale -n xy101 deployment myapp-v1 --replicas=0 && kubectl scale -n xy101 deployment myapp-v2 --replicas=3
kubectl get -n xy101 all