一、安装Pod网络插件calico**（CNI）**
1.1 k8s 组网方案对比
Kubernetes 中，最常见的两种网络方案就是：
Flannel和Calico。
它们的目标是一样的：不管Pod在不在同一台机器上，都要能通信
但实现方式完全不同：
Flannel：走 隧道（Overlay）
Calico：走 路由（Underlay）
1.2 flannel****方案 适合小型网络 简单 没有大的高并发
三种模式
1、UDP
2、VXLAN
3、Host-gw
需要在每个节点上把发向容器的数据包进行封装后，再用隧道将封装后的数据包发送到运行着目标Pod的node节点上。目标node节点再负责去掉封装，将去除封装的数据包发送到目标Pod上。数据通信性能则大受影响。
---------- 部署 flannel ----------
K8S 中 Pod 网络通信：
●Pod 内容器与容器之间的通信
在同一个 Pod 内的容器（Pod 内的容器是不会跨宿主机的）共享同一个网络命名空间，相当于它们在同一台机器上一样，可以用 localhost 地址访问彼此的端口。
●同一个 Node 内 Pod 之间的通信
每个 Pod 都有一个真实的全局 IP 地址，同一个 Node 内的不同 Pod 之间可以直接采用对方 Pod 的 IP地址进行通信，Pod1 与 Pod2 都是通过 Veth（隧道） 连接到同一个 docker0/cni0 网桥，网段相同，所以它们之间可以直接通信。
●不同 Node 上 Pod 之间的通信
Pod 地址与 docker0 在同一网段，docker0 网段与宿主机网卡是两个不同的网段，且不同 Node 之间的通信只能通过宿主机的物理网卡进行。
要想实现不同 Node 上 Pod 之间的通信，就必须想办法通过主机的物理网卡 IP 地址进行寻址和通信。因此要满足两个条件：Pod 的 IP 不能冲突；将 Pod 的 IP 和所在的 Node 的 IP 关联起来，通过这个关联让不同 Node 上 Pod 之间直接通过内网 IP 地址通信。
Overlay Network：
叠加网络，在二层或者三层基础网络上叠加的一种虚拟网络技术模式，该网络中的主机通过虚拟链路隧道连接起来。
通过Overlay技术（可以理解成隧道技术），在原始报文外再包一层四层协议（UDP协议），通过主机网络进行路由转发。这种方式性能有一定损耗，主要体现在对原始报文的修改。目前Overlay主要采用 VXLAN。
xie1 VNI xie1
VXLAN：
将源数据包封装到UDP中，并使用基础网络的IP/MAC作为外层报文头进行封装，然后在以太网上传输，到达目的地后由隧道端点解封装并将数据发送给目标地址。
Flannel:
Flannel 的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟 IP 地址。
Flannel 是 Overlay 网络的一种，也是将 TCP 源数据包封装在另一种网络包里面进行路由转发和通信，目前支持 UDP、VXLAN、Host-gw 3种数据转发方式。
#Flannel UDP 模式的工作原理：
数据从主机 A 上 Pod 的源容器中发出后，经由所在主机的 docker0/cni0 网络接口转发到flannel0 接口，flanneld 服务监听在 flannel0 虚拟网卡的另外一端。
Flannel 通过 Etcd 服务维护了一张节点间的路由表。源主机 A 的 flanneld 服务将原本的数据内容封装到 UDP 报文中， 根据自己的路由表通过物理网卡投递给目的节点主机 B 的 flanneld 服务，数据到达以后被解包，然后直接进入目的节点的 flannel0 接口， 之后被转发到目的主机的 docker0/cni0 网桥，最后就像本机容器通信一样由 docker0/cni0 转发到目标容器。
#ETCD 之 Flannel 提供说明:
存储管理Flannel可分配的IP地址段资源
监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表
由于 UDP 模式是在用户态做转发，会多一次报文隧道封装，因此性能上会比在内核态做转发的 VXLAN 模式差。
#VXLAN 模式：
VXLAN 模式使用比较简单，flannel 会在各节点生成一个 flannel.1 的 VXLAN 网卡（VTEP设备，负责 VXLAN 封装和解封装）。
VXLAN 模式下作是由内核进行的。flannel 不转发数据，仅动态设置 ARP 表和 MAC 表项。
UDP 模式的 flannel0 网卡是三层转发，使用 flannel0 时在物理网络之上构建三层网络，属于 ip in udp ；VXLAN封包与解包的工作模式是二层实现，overlay 是数据帧，属于 mac in udp 。
网络范围：
VLAN：适用于同一物理网络内的分段。
VXLAN：适用于跨多个物理网络和数据中心的分段。
扩展性：
VLAN：数量有限（通常最多 4096 个 VLAN）。
VXLAN：可以支持多达 16,777,216 个虚拟网络。
实现方式：
VLAN：依赖于二层交换机。
VXLAN：利用三层 IP 网络，使用 UDP 进行封装和传输。
#Flannel VXLAN 模式跨主机的工作原理：
① 数据帧从主机 A 上 Pod 的源容器中发出后，经由所在主机的 docker0/cni0 网络接口转发到 flannel.1 接口
② flannel.1 收到数据帧后添加 VXLAN 头部，封装在 UDP 报文中
③ 主机 A 通过物理网卡发送封包到主机 B 的物理网卡中
④ 主机 B 的物理网卡再通过 VXLAN 默认端口 4789 转发到 flannel.1 接口进行解封装
⑤ 解封装以后，内核将数据帧发送到 cni0，最后由 cni0 发送到桥接到此接口的容器 B 中。
1.3 calico方案 路由 适合大型网路架构 复杂的架构
Calico不使用隧道或NAT来实现转发，而是把Host当作Internet中的路由器，使用BGP同步路由，并使用 iptables来做安全访问策略，完成跨Host转发。
采用直接路由的方式，这种方式性能损耗最低，不需要修改报文数据，但是如果网络比较复杂场景下，路由表会很复杂，对运维同事提出了较高的要求。
#Calico 主要由三个部分组成：
Calico CNI插件：主要负责与kubernetes对接，供kubelet调用使用。
Felix：负责维护宿主机上的路由规则、FIB转发信息库等。
BIRD：负责分发路由规则，类似路由器。
Confd：配置管理组件。
#Calico 工作原理：
Calico 是通过路由表来维护每个 pod 的通信。Calico 的 CNI 插件会为每个容器设置一个 veth pair 设备， 然后把另一端接入到宿主机网络空间，由于没有网桥，CNI 插件还需要在宿主机上为每个容器的veth pair 设备配置一条路由规则， 用于接收传入的 IP 包。
有了这样的 veth pair 设备以后，容器发出的 IP 包就会通过 veth pair 设备到达宿主机，然后宿主机根据路由规则的下一跳地址， 发送给正确的网关，然后到达目标宿主机，再到达目标容器。
这些路由规则都是 Felix 维护配置的，而路由信息则是 Calico BIRD 组件基于 BGP 分发而来。
calico 实际上是将集群里所有的节点都当做边界路由器来处理，他们一起组成了一个全互联的网络，彼此之间通过 BGP 交换路由， 这些节点我们叫做 BGP Peer。
目前比较常用的CNI网络组件是flannel和calico，flannel的功能比较简单，不具备复杂的网络策略配置能力，calico是比较出色的网络管理插件，但具备复杂网络配置能力的同时，往往意味着本身的配置比较复杂，所以相对而言，比较小而简单的集群使用flannel，考虑到日后扩容，未来网络可能需要加入更多设备，配置更多网络策略，则使用calico更好。
1.4 calico****安装
kubectl apply -f https://docs.tigera.io/archive/v3.24/manifests/calico.yaml
[root@master01 opt]#wget
https://docs.tigera.io/archive/v3.25/manifests/calico.yaml #获取yaml文件
[root@master01 opt]#vim calico.yaml #修改文件
......
4601 - name: CALICO_IPV4POOL_CIDR #取消注释
4602 value: "10.244.0.0/16" #取消注释，并将ip地址修改为与初始化集群时--pod-network-cidr指定的IP地址一致
4551 - name: CALICO_IPV4POOL_CIDR
4552 value: "10.244.0.0/16"
[root@master01 opt]#kubectl apply -f calico.yaml
#如果不行需要手动导入
[root@node01 opt]# nerdctl -n k8s.io image load -i dashboard-v2.7.0.tar
[root@node01 opt]# nerdctl -n k8s.io image load -i metrics-scraper-v1.0.8.tar1.5 Flannel 和 Calico 总结
|--------|-------------|------------|
| 对比 | Flannel | Calico |
| 网络模式 | Overlay | 路由 |
| 是否封装 | 是 | 否 |
| 性能 | 一般 | 高 |
| 复杂度 | 低 | 高 |
| 适合场景 | 小集群 | 生产/大集群 |
二、 Kubernetes****操作管理概述
1）管理操作分为两大类陈述和声明
2）k8s 基础信息查看（命令）增删改查
3）项目生命周期 创建 发布 更新 回滚 删除 所有命令和过程
4）主要发布过程 金丝雀发布 蓝绿发布 滚动发布
2.1****管理操作分类
Kubernetes 的管理操作分为两大类：
陈述式（命令式）管理方法
声明式（配置清单式）管理方法
2.1.1****陈述式资源管理方法
**1）**基本原理
-
Kubernetes 集群资源管理的唯一入口是通过调用 apiserver的接口。
-
kubectl是官方 CLI 命令行工具，用于与 apiserver 通信，将用户命令转化为 apiserver 能识别的请求，实现集群资源管理。
-
查看 kubectl 命令大全：
kubectl --help
中文文档参考：http://docs.kubernetes.org.cn/683.html
4. 对资源的"增、删、查"操作较方便，但"改"操作相对复杂。
**2）**基础信息查看命令
（1）版本与集群信息
kubectl version # 查看版本信息
kubectl api-resources # 查看资源对象简写
kubectl cluster-info # 查看集群信息
（2）命令自动补全与日志查看
source <(kubectl completion bash) # 启用kubectl自动补全
journalctl -u kubelet -f # 查看node节点日志
3） 基本资源查看命令
kubectl get <resource> [-o wide|json|yaml] [-n namespace]-n 指定命名空间
-o 指定输出格式
--all-namespaces ：显示所有命名空间
--show-labels ：显示所有标签
-l app=nginx ：筛选指定标签的资源
示例：
kubectl get componentstatuses # 查看 master 节点状态
kubectl get namespace # 查看命名空间
kubectl get all -n default # 查看default命名空间的所有资源
**4）**命名空间操作
kubectl create ns app # 创建命名空间
kubectl delete namespace app # 删除命名空间5）创建Deployment**（副本控制器）**
kubectl create deployment nginx-wl --image=nginx -n kube-public
kubectl create deployment
kubectl run 自主式的pod 静态
###描述某个资源的详细信息
kubectl describe deployment nginx-wl -n kube-public
kubectl describe pod nginx-wl-d47f99cb6-hv6gz -n kube-public
kubectl get pods -n kube-public
6） 登录容器与删除 Pod
[root@master ~]# kubectl exec -it nginx-web-5bf45d88df-r8svq bash -n kube-public # 登录容器
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
root@nginx-web-5bf45d88df-r8svq:/#
root@nginx-web-5bf45d88df-r8svq:/#
root@nginx-web-5bf45d88df-r8svq:/# ls
bin dev docker-entrypoint.sh home lib64 mnt proc run srv tmp var
boot docker-entrypoint.d etc lib media opt root sbin sys usr
root@nginx-web-5bf45d88df-r8svq:/# exit
exit
[root@master ~]# kubectl get pods -n kube-public
NAME READY STATUS RESTARTS AGE
nginx-web-5bf45d88df-r8svq 1/1 Running 0 10m
[root@master ~]# kubectl delete pod nginx-web-5bf45d88df-r8svq -n kube-public # 删除pod
pod "nginx-web-5bf45d88df-r8svq" deleted
#若pod无法删除，总是处于terminate状态，则要强行删除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
#grace-period表示过渡存活期，默认30s，在删除pod之前允许POD慢慢终止其上的容器进程，从而优雅退出，0表示立即终止pod**7）**扩缩容与删除
kubectl scale deployment nginx-wl --replicas=2 -n kube-public
kubectl scale deployment nginx-wl --replicas=1 -n kube-public
kubectl delete deployment nginx-wl -n kube-public
2.1.2****声明式资源管理方法
**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**3）**修改资源配置清单并应用
离线修改：
修改yaml文件，并用 kubectl apply -f xxxx.yaml 文件使之生效
注意：当apply不生效时，先使用delete清除资源，再apply创建资源
kubectl get service nginx -o yaml > nginx-svc.yaml
vim nginx-svc.yaml #修改port: 8080
kubectl delete -f nginx-svc.yaml
kubectl apply -f nginx-svc.yaml
kubectl get svc
在线修改：
直接使用 kubectl edit service nginx 在线编辑资源配置清单并保存退出即时生效（如port: 888）
PS：此修改方式不会对yaml文件内容修改**4）**在线修改
直接使用 kubectl edit service nginx 在线编辑资源配置清单并保存退出即时生效（如port: 888）
PS：此修改方式不会对yaml文件内容修改注：此方式直接生效，但不会修改本地 YAML 文件。
**5）**删除资源配置清单
陈述式删除：
kubectl delete service nginx声明式删除：
kubectl delete -f nginx-svc.yaml2.1.3****总结
Kubernetes 提供了两种管理方式：陈述式管理和声明式管理。其中，陈述式适用于简单的命令执行，声明式则更加灵活和可扩展。无论是通过命令行的方式还是通过配置文件管理，Kubernetes 都能帮助管理员有效地管理集群资源，支持滚动更新、回滚、金丝雀发布等多种发布策略，确保应用的稳定性和高可用性。
2.2 项目生命周期管理
项目的生命周期包括：
**创建 →发布→更新→回滚→**删除
2.2.1****创建阶段（kubectl create）
●创建并运行一个或多个容器镜像。
●创建一个deployment 或job 来管理容器。
kubectl create --help
//启动 nginx 实例，暴露容器端口 80，设置副本数 3
[root@master ~]# kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
deployment.apps/nginx created
[root@master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-d9d8cf5c7-4wt89 1/1 Running 0 32s
nginx-d9d8cf5c7-5t7vn 1/1 Running 0 32s
nginx-d9d8cf5c7-wn82k 1/1 Running 0 32s
[root@master ~]# kubectl get all
NAME READY STATUS RESTARTS AGE
pod/nginx-d9d8cf5c7-4wt89 1/1 Running 0 46s
pod/nginx-d9d8cf5c7-5t7vn 1/1 Running 0 46s
pod/nginx-d9d8cf5c7-wn82k 1/1 Running 0 46s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 34h
service/nginx NodePort 10.96.28.143 <none> 80:30037/TCP 34h
service/nginx-server NodePort 10.96.121.105 <none> 80:30032/TCP 28h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx 3/3 3 3 46s
NAME DESIRED CURRENT READY AGE
replicaset.apps/nginx-d9d8cf5c7 3 3 3 46s
[root@master ~]#2.2.2****发布阶段（kubectl expose）
将资源暴露为 Service
kubectl expose --help
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort
①Service类型：
|--------------|-------------------------|
| 类型 | 说明 |
| ClusterIP | 集群内部访问（默认） |
| NodePort | 集群外部访问，端口范围 30000-32767 |
| LoadBalancer | 云平台负载均衡 |
| externalName | 映射到外部域名 |
② 扩展端口类型
●port
port 是 k8s 集群内部访问service的端口，即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到service
●nodePort
nodePort 是外部访问 k8s 集群中 service 的端口，通过 nodeIP: nodePort 可以从外部访问到某个service。
●targetPort
targetPort 是 Pod 的端口，从 port 或 nodePort 来的流量经过 kube-proxy 反向代理负载均衡转发到后端 Pod 的 targetPort 上，最后进入容器。
●containerPort
containerPort 是 Pod 内部容器的端口，targetPort 映射到 containerPort。
③ 查看网络状态与服务端口
#查看pod网络状态详细信息和 Service暴露的端口
kubectl get pods,svc -o wide
##查看关联后端的节点
kubectl get endpoints
#查看 service 的描述信息
kubectl describe svc nginx
④ 负载均衡查看（节点上）
#在 node01 节点上操作，查看负载均衡端口
yum install ipvsadm -y
[root@node01 ~]# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
......
TCP 192.168.10.20:31862 rr
-> 10.244.1.30:80 Masq 1 0 0
-> 10.244.1.31:80 Masq 1 0 0
-> 10.244.2.25:80 Masq 1 0 0
......
TCP 10.96.28.143:80 rr
-> 10.244.1.30:80 Masq 1 0 0
-> 10.244.1.31:80 Masq 1 0 0
-> 10.244.2.25:80 Masq 1 0 0
......
curl 10.96.28.143
curl 192.168.10.20:31862
###在master01操作 查看访问日志
kubectl logs nginx-d9d8cf5c7-4wt89
kubectl logs nginx-d9d8cf5c7-5t7vn
kubectl logs nginx-d9d8cf5c7-wn82k
2.2.3****更新阶段（kubectl set）
修改容器镜像：
●更改现有应用资源一些信息。
kubectl set --help
//获取修改模板
kubectl set image --help
//查看当前 nginx 的版本号
curl -I http://192.168.10.20:31862
curl -I http://192.168.10.21:31862
##将nginx 版本更新为 1.15 版本
kubectl set image deployment/nginx nginx=nginx:1.15
kubectl get pods -w #/处于动态监听 pod 状态，由于使用的是滚动更新方式，所以会先生成一个新
的pod，然后删除一个旧的pod，往后依次类推
kubectl get pods -o wide #再看更新好后的 Pod 的 ip 会改变
2.2.4****回滚阶段（kubectl rollout）
##对资源进行回滚管理
kubectl rollout --help
//查看历史版本
kubectl rollout history deployment/nginx
//执行回滚到上一个版本
kubectl rollout undo deployment/nginx
//执行回滚到指定版本
kubectl rollout undo deployment/nginx --to-revision=1
//检查回滚状态
kubectl rollout status deployment/nginx
2.2.5****删除阶段（kubectl delete）
//删除副本控制器
kubectl delete deployment/nginx
//删除service
kubectl delete svc/nginx-service
kubectl get all
2.3****发布策略
2.3.1 金丝雀发布（Canary Release）
Deployment控制器支持自定义控制更新过程中的滚动节奏，如"暂停(pause)"或"继续(resume)"更新操作。
例如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。
步骤：
（1）更新deployment的版本，并配置暂停deployment
kubectl set image deployment/nginx nginx=nginx:1.14 && kubectl rollout pause deployment/nginx
kubectl rollout status deployment/nginx #观察更新状态
（2）监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
kubectl get pods -w
curl 10.96.28.143
curl 192.168.10.20:31862
（3）确保更新的pod没问题了，继续更新
kubectl rollout resume deployment/nginx
（4）查看最后的更新情况
kubectl get pods -w
curl 10.96.28.143
curl 192.168.10.20:318622.3.2 滚动发布
核心结论 ：滚动发布是一种渐进式替换 旧版本实例的部署策略，通过分批更新、新旧共存、健康检查 实现零停机升级 ，核心靠maxSurge与maxUnavailable控制更新节奏，适合无状态服务的常规迭代.
以 Kubernetes Deployment 为例，完整滚动发布流程如下：
① 触发更新
用户通过
kubectl apply、kubectl set image或修改 Deployment 配置文件触发更新API Server 检测到 Pod 模板变更，通知 Deployment 控制器协调状态
② 创建新 ReplicaSet
Deployment 控制器创建新的 ReplicaSet (RS)，用于管理新版本 Pod
新 RS 初始副本数为 0，旧 RS 保持原有副本数
③ 渐进式实例替换 (核心步骤)
扩容新版本 ：新 RS 按
maxSurge配置创建新版本 Pod健康检查：等待新 Pod 通过就绪探针 (Readiness Probe)，确认可正常接收流量
缩容旧版本 ：旧 RS 按
maxUnavailable配置终止旧版本 Pod流量切换：Service 自动将流量路由到所有健康 Pod (新旧版本共存)
循环执行：重复步骤 1-4，直到所有旧 Pod 被替换，新 RS 达到期望副本数Kubernetes
④ 完成与清理
旧 RS 保留 (默认保留 10 个历史版本)，用于快速回滚
可通过
kubectl rollout status deployment/<name>查看更新进度
2.3.3 蓝绿发布
核心结论 ：蓝绿发布是一种全量环境切换 的部署策略，通过搭建两套完全相同的生产环境（蓝环境 = 旧版本、绿环境 = 新版本），在绿环境验证通过后，利用负载均衡器一次性切换全部流量，实现零停机、无版本混合的平滑升级，适合对兼容性要求高或需快速回滚的重大版本更新。
以典型的 Web 服务蓝绿发布为例，完整流程如下：
① 初始状态：蓝环境对外服务
蓝环境部署旧版本应用 (v1)，负载均衡器将所有外部流量路由到蓝环境。
绿环境处于空闲状态，或与蓝环境保持相同的旧版本，用于后续部署新版本。
数据层（数据库、缓存）为蓝绿环境共享，或已配置双向同步机制。
② 部署新版本到绿环境
在绿环境中部署新版本应用 (v2)，部署过程不影响蓝环境的正常服务。
部署完成后，启动绿环境的应用实例，确保实例正常启动且依赖服务（数据库、中间件）连接正常。
③ 绿环境全量验证（核心步骤）
这一步是蓝绿发布的关键，需验证新版本的稳定性和正确性，避免上线故障：
内部功能测试：通过内网访问绿环境，验证新版本的功能是否符合预期，修复发现的 Bug。
性能与压力测试：模拟生产级流量压测绿环境，确认响应速度、并发能力、资源占用等指标达标。
健康检查：通过就绪探针、心跳检测等机制，确认绿环境所有实例均处于健康状态。
数据一致性验证：检查绿环境与数据层的交互是否正常，数据读写是否符合预期，无脏数据或数据丢失。
④ 原子化流量切换
当绿环境验证通过后，操作负载均衡器，将所有外部流量从蓝环境切换到绿环境。
切换操作是瞬间完成的（原子性），切换后所有用户请求都会被路由到绿环境的新版本应用。
切换后持续监控绿环境的流量、错误率、响应时间等指标，确认服务稳定。
⑤ 收尾与环境清理
蓝环境降级备用：流量切换后，蓝环境的旧版本应用不会立即下线，而是作为备用环境保留一段时间（如 1-2 天），用于应急回滚。
数据层同步调整：若数据层为单向同步（蓝→绿），切换后可调整为绿→蓝同步，确保蓝环境数据不落后。
最终清理：当绿环境稳定运行且无需回滚时，可下线蓝环境的旧版本应用，释放资源用于下一次发布。
回滚流程
蓝绿发布的最大优势是回滚成本极低，若新版本出现故障，回滚流程如下：
监控发现绿环境（新版本）出现异常（如错误率飙升、服务不可用）。
操作负载均衡器，将流量从绿环境切回蓝环境，切换过程瞬间完成，用户几乎无感知。
流量切回后，下线绿环境的新版本应用，排查故障原因，修复后重新部署验证。
2.3.4 发布策略的对比
|----------|------------------------------------|-------------------|
| 发布策略 | 特点 | 适用场景 |
| 蓝绿发布 | 零停机，秒级回滚，资源消耗翻倍 | 核心业务、对可用性要求极高的服务 |
| 滚动更新 | 逐步替换 Pod，资源消耗低，无回滚能力（只能重新部署旧版本） | 一般业务、对可用性要求中等的服务 |
| 金丝雀发布 | 先将少量流量切到新版本，验证无误后逐步扩大比例，资源消耗低，回滚灵活 | 新版本风险较高、需要灰度验证的服务 |