目录

1.常见的发布方式

2.实现蓝绿发布

3.实现金丝雀发布（Canary Release）

4.声明式管理方法

---

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

蓝绿升级方式：
通过切花负载均衡的流量来实现业务的切换

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 

3.实现金丝雀发布（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没问题了，继续更新，会一次性都更新结束

4.声明式管理方法

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