目录
一 应用发布策略
1,滚动发布(k8s默认)
2,蓝绿发布
3,金丝雀发布
二 金丝雀发布(Canary Release) (灰度发布)
1,金丝雀发布图解
2, 金丝雀发布部署过程
2,1 准备命名空间和 pod
2.2 更新deployment的版本,并配置暂停deployment
2.3 pod隔离
2.31 将旧版本nginx 与 之前的svc 绑定
2.32 将新版本nginx 与 新的svc 绑定
2.4 测试pod 隔离是否成功
2.5 恢复更新,查看更新状态
2.6 查看更新完成最后状态
三 声明式管理方法
1, 基本介绍
2, 命令介绍
一 应用发布策略
1,滚动发布(k8s默认)
即(一个一个去更新)
2,蓝绿发布
一套业务,两个版本
维护两个相同的生产环境(蓝环境和绿环境)。新版本首先部署到非活跃环境(比如蓝环境),完成部署并验证无误后,通过切换路由或负载均衡器配置,将流量从旧环境(绿环境)无缝转移到新环境。
3,金丝雀发布
逐步将新版本部署到一部分用户或服务器上,监控性能和错误率。如果一切正常,逐渐扩大新版本的覆盖范围,直至完全替换旧版本。
二 金丝雀发布(Canary Release) (灰度发布)
1,金丝雀发布图解
如图,某服务当前版本为 v1,现在新版本 v2 要上线。为确保流量在服务升级过程中平稳无损,采用金丝雀发布方案,逐步将流量从老版本迁移至新版本。
2, 金丝雀发布部署过程
2,1 准备命名空间和 pod
kubectl create ns wyq
# 创建nskubectl create deployment nginx01 --image=nginx:1.14 --port=80 --replicas=4 -n wyq
# 用deployment 控制器创建4个podkubectl expose deployment nginx01 --port=80 --target-port=80 --name=nginx01 --type=NodePort -n wyq
# 对外暴露
查看 准备环境
他们都是由 同一个叫nginx01 的deployment 控制器创造出来的。
所以标签都是一样的
2.2 更新deployment的版本,并配置暂停deployment
kubectl set image deployment nginx01 nginx=nginx:1.20.1 -n wyq && kubectl rollout pause deployment nginx01 -n wyq
更新deployment的版本
kubectl set image
#用于更新 Kubernetes 资源(如 Deployment、StatefulSet 等)中的容器镜像。
deployment nginx01
#指定要更新的 Deployment 的名称为 nginx01
nginx=nginx:1.20.2
#指定要更新的容器名称为 nginx,并将其镜像设置为 nginx:1.20.2。
-n wyq
#指定命名空间为 wyq
暂停更新
kubectl rollout pause deployment nginx01 -n wyq
#这个命令用于暂停wyq 命名空间中的 nginx01 Deployment 的滚动更新。
kubectl rollout pause
#用于暂停 Kubernetes Deployment 的滚动更新。
deployment nginx01
#指定要暂停滚动的 Deployment 的名称为 nginx01
-n wyq
#指定命名空间为 wyq
查看此时的状态
可以看到pod 由4个变成了6个 由于新生成的pod 不是原来deployment 产生的,所以标签不一致
可以看到流量会分配到 新旧版本的nginx 上
2.3 pod隔离
流量控制:为了实现金丝雀发布,需要控制流量,使得只有一小部分用户或流量能够访问到新版本的应用程序。
使用Service的selector和labels来选择性地路由流量到不同的Deployment。可以创建一个新的Service,其selector只匹配新版本的Pods,然后将一小部分流量路由到这个Service。
说白了就是 创建一个新的svc 暴露端口,并将新版本的nginx和 新的svc绑定,将老版本的nginx和 老的svc绑定 。 这样就能做到 pod 隔离,相当于把旧版的Pod与新版本的Pod实例进行了分割,而后再通过关注新版本的性能和稳定性,来确保新版本能够正常运行。在确定新版本的pod实例能够正常使用,且没有漏洞时,再恢复更新
2.31 将旧版本nginx 与 之前的svc 绑定
删除原来的svc ,用yaml 文件生成新的svc (nginx01) 绑定旧版本的nginx
apiVersion: v1
kind: Service
metadata:namespace: wyqlabels:app: nginx01name: nginx01
spec:ports:- port: 80protocol: TCPtargetPort: 80nodePort: 32428selector:pod-template-hash: 695cdcd7c8type: NodePort
指定nodePort: 32428 (注意这个端口要和之前的一样!方便客户访问)
重点:
selector: #键值对标签选择器,用于确定哪些Pod应该被包含在Service的后端集合中
pod-template-hash: "695cdcd7c8" #这里填 旧版本nginx 的标签
执行yaml 文件 生成svc
2.32 将新版本nginx 与 新的svc 绑定
用yaml 文件生成新的svc (nginx02) 绑定新版本的nginx
apiVersion: v1
kind: Service
metadata:namespace: wyqlabels:app: nginx01name: nginx02
spec:ports:- port: 80protocol: TCPtargetPort: 80nodePort: 31244selector:pod-template-hash: 6fc9f9b648type: NodePort
执行yaml 文件 生成svc (nginx02) 绑定新版本nginx
查看现在的环境
完成上述操作,相当于把旧版的Pod与新版本的Pod实例进行了分割,而后再通过关注新版本的性能和稳定性,来确保新版本能够正常运行。在确定新版本的pod实例能够正常使用,且没有漏洞时,再恢复更新
2.4 测试pod 隔离是否成功
访问旧版本的32428 端口 流向只会去向旧版本
访问旧版本的31244 端口 流向只会去向新版本
2.5 恢复更新,查看更新状态
恢复更新
kubectl rollout resume deployment nginx01 -n wyq
查看更新状态
kubectl rollout status deployment nginx01 -n wyq
2.6 查看更新完成最后状态
更新完毕
所有流向都会走向新的 svc
旧的service最好不要删除,当新版本出现问题,需要回滚时,旧版的pod还是会关联在旧的service当中
3, 常见错误注意事项
此方法是错误的! 这只是加标签,像商品上贴备注一样,做不到 将pod 隔离
三 声明式管理方法
1, 基本介绍
1.适合于对资源的修改操作
2.声明式资源管理方法依赖于资源配置清单文件对资源进行管理
资源配置清单文件有两种格式:yaml(人性化,易读),json(易于api接口解析)
3.对资源的管理,是通过事先定义在统一资源配置清单内,再通过陈述式命令应用到k8s集群里
4.语法格式:kubectl create/apply/delete -f xxxx.yaml
2, 命令介绍
查看资源配置清单
kubectl get deployment nginx -o yaml
解释资源配置清单
kubectl explain deployment.metadata
kubectl get service nginx -o yaml
kubectl explain service.metadata
修改资源配置清单并应用
离线修改:
修改yaml文件,并用 kubectl apply -f xxxx.yaml 文件使之生效
注意:当apply不生效时,先使用delete清除资源,再apply创建资源
在线修改
直接使用 kubectl edit service nginx 在线编辑资源配置清单并保存退出即时生效(如port: 888)
PS:此修改方式不会对yaml文件内容修改
删除资源配置清单
陈述式删除:
kubectl delete service nginx
声明式删除:
kubectl delete -f nginx-svc.yaml