金丝雀发布（灰度发布）介绍 及 声明式管理方法简介
目录
一 应用发布策略
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