目录
1.常见的发布方式
2.滚动发布
3.蓝绿发布
4.实现金丝雀发布(Canary Release)
5.声明式管理方法
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 test01kubectl 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.yamlkubectl 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=NodePortkubectl get -n xy101 deployments.apps myapp-v1 -o yaml > deploy.yamlvim deploy.yaml
修改9行 app: myapp-v2
98行 replicas: 1
92行 name: myapp-v2
115行 - image: soscscs/myapp:v2kubectl 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