目录

一   应用发布策略

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