灰度发布功能需求说明书

灰度发布功能需求范围说明书

项⽬概述

项⽬背景

随着公司业务的快速发展,微服务架构下的应⽤更新迭代频繁。为了降低新版本发布⻛险,提⾼系统稳定性,需要

实现灰度发布功能,允许特定⽤户或特定标记的请求访问新版本服务,逐步验证新版本功能。

项⽬⽬标

基于 Spring Cloud 微服务架构,实现全链路灰度发布功能,⽀持:

  1. 基于⽤户、请求标记的精准灰度路由
  2. ⽹关到后端服务、服务间调⽤的全链路灰度⼀致性
  3. 灰度规则动态配置和管理
  4. 灰度流量监控和统计

⽅案

在 KubeSphere 上部署你的 Spring Cloud 服务,应用保持 Spring Cloud 技术栈,但流量治理(如灰度发布)则由底层的 Istio 服务网格来负责。

协同工作原理

下面的流程图清晰地展示了 Spring Cloud 应用如何在 KubeSphere 上通过 Istio 实现灰度发布:
KubeSphere 灰度发布策略
蓝绿发布
金丝雀发布
流量镜像
Spring Cloud 应用
部署至 K8s

(保持原有框架)
通过 KubeSphere 治理
方案A:直接部署为工作负载
方案B:使用 Spring Cloud 扩展
由 Istio 服务网格接管流量
由 KubeSphere Spring Cloud 扩展管理
利用 Istio 实现

蓝绿/金丝雀/镜像发布
完成灰度发布

关键实施步骤与检查点

基于上述架构,你可以参照以下路径进行操作:

阶段 核心步骤 关键检查点与说明

  1. 环境准备 启用 KubeSphere 服务网格 (Istio) 和 Spring Cloud 扩展组件。 在管理后台确认组件状态为"已启用"。这是所有功能的基础。
  2. 应用部署 方案A(直接):将应用作为普通工作负载(Deployment)部署。 方案B(推荐):通过 Spring Cloud > 微服务菜单创建,便于统一管理。 确保Pod内容器端口协议(如HTTP)设置正确,这是Istio进行流量识别和管理的前提。
  3. 服务注册与发现 应用需集成Nacos客户端,并配置其服务端地址。Spring Cloud扩展会提供Nacos服务。 应用能正常注册到KubeSphere提供的Nacos,这是微服务间通信的保障。
  4. 注入Sidecar 为应用的命名空间或工作负载启用Istio Sidecar自动注入。 应用Pod内应有两个容器(业务容器 + istio-proxy),表明已接入服务网格。
  5. 配置灰度发布 1. 部署新版本(如v2)工作负载。 2. 在服务网格或灰度发布菜单中,选择策略并配置流量规则。 KubeSphere支持蓝绿发布、金丝雀发布和流量镜像三种主流策略。
策略选择与后续建议

你可以参考以下建议选择灰度策略:

· 验证新功能可用性:蓝绿发布更合适,切换迅速。

· 观察新版本稳定性:金丝雀发布(逐步放量)或流量镜像(无风险复制流量)是更谨慎的选择。

官方文档

https://docs.kubesphere.com.cn/v4.2.1/11-use-extensions/06-service-mesh

流量控制权的转移

通过对比三种部署方式来理解:

场景 服务发现 (找谁) 流量路径 (怎么去) 谁控制流量?

详细解释:流量如何被"劫持"

在启用了Istio服务网格的KubeSphere环境中,会发生以下关键变化:

  1. Sidecar注入:您的Spring Cloud应用Pod里,除了业务容器,会被自动注入一个istio-proxy容器。这个代理容器会接管Pod的所有出入站网络流量。
  2. 流量拦截:您的Spring Boot应用代码里,Feign或RestTemplate发出的请求,目的地虽然是service-a,但出网流量首先被istio-proxy拦截。
  3. 网格内路由:istio-proxy根据从Istio控制平面下发的规则(您在KubeSphere界面上配置的灰度规则),决定将流量转发到service-a的v1版本Pod,还是v2版本Pod。这个过程完全绕过了K8s Service的负载均衡。
  4. 服务发现的作用:此时,Nacos的作用更多是作为一个服务注册中心,保证应用启动和健康检查。在严格模式下,网格内的服务通信甚至可以不依赖Nacos的发现结果,而是直接使用Istio内置的服务发现。
对您的影响与建议

理解了这一点,您就能明白:

· 您无需修改业务代码:您的Spring Cloud服务仍然像往常一样从Nacos查询和注册服务。

· 真正实现灰度的是Istio:您在KubeSphere控制台上配置的"金丝雀发布"规则,会被转换为Istio的VirtualService和DestinationRule,由istio-proxy执行,从而做到精准的流量切分、故障注入等。

· Nacos部署在哪影响不大:无论是K8s内部还是外部Nacos,在服务网格模式下,对流量控制的影响很小。选择的关键在于运维便利性、网络连通性和性能:

· K8s内部Nacos:部署管理方便,与K8s生态结合好,但需注意其资源消耗和高可用配置。

· 外部独立Nacos:性能可能更稳定,资源独立,但需要确保K8s集群内Pod能稳定访问到它。

结论与行动路线

所以,回到您最初的目标------在KubeSphere上为Spring Cloud服务实现灰度发布,正确路径是启用并依赖其服务网格(Istio)能力,而不是纠结于让Spring Cloud或Nacos自己来实现复杂的流量拆分。

建议的操作步骤:

  1. 在KubeSphere中为您应用的命名空间 启用Istio Sidecar自动注入。
  2. 像往常一样部署您的Spring Cloud应用(连接现有的Nacos)。
  3. 在KubeSphere的服务网格或灰度发布功能页面,为您服务的两个版本(如v1和v2)创建灰度发布任务,并配置流量比例。

完成以上步骤后,您就能通过KubeSphere的界面直观地管理和监控灰度发布过程,而背后的复杂流量控制则由Istio透明地完成。

相关推荐
bukeyiwanshui2 小时前
20260626 k8sControllers介绍
云原生·容器·kubernetes
能有时光3 小时前
] K8s 核心组件使用指南
云原生·容器·kubernetes
云烟成雨TD4 小时前
Kubernetes 系列【13】控制器:可视化操作 Deployment
云原生·容器·kubernetes
运维老郭16 小时前
【K8s运维实战】Kubernetes临时存储卷实战:emptyDir核心用法与gitRepo弃用迁移指南
运维·云原生·kubernetes
gs801401 天前
记一次多 Agent 架构在单节点 K8s 触发的 PID 耗尽与 Pod 驱逐(Evicted)大摸排
容器·架构·kubernetes
bukeyiwanshui1 天前
20260701 k8s Metric Server
容器·贪心算法·kubernetes
Zhu7581 天前
在k8s集群部署ApacheHadoop单节点单数据副本
云原生·容器·kubernetes
摇滚侠1 天前
云原生 Java 架构师的第一课 K8s+Docker+KubeSphere+DevOps 51-60
java·云原生·kubernetes
bukeyiwanshui1 天前
20260703 K8s ECShop商城项目
云原生·容器·kubernetes