灰度发布功能需求说明书

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

项⽬概述

项⽬背景

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

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

项⽬⽬标

基于 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透明地完成。

相关推荐
liux352813 小时前
基于kubeadm部署Kubernetes 1.26.4 集群指南
云原生·容器·kubernetes
小章UPUP17 小时前
Kubernetes (K8s) 与 Podman 的比较
容器·kubernetes·podman
农民工老王20 小时前
K8s 1.31 私有化部署实战:从 Calico 崩溃到 NFS 挂载失败的排坑全记录
云原生·kubernetes
广州中轴线20 小时前
OpenStack on Kubernetes 生产部署实战(十四)
kubernetes·智能路由器·openstack
人间打气筒(Ada)2 天前
k8s:CNI网络插件flannel与calico
linux·云原生·容器·kubernetes·云计算·k8s
江畔何人初2 天前
pod的内部结构
linux·运维·云原生·容器·kubernetes
苦逼IT运维2 天前
从 0 到 1 理解 Kubernetes:一次“破坏式”学习实践(一)
linux·学习·docker·容器·kubernetes
腾讯云开发者2 天前
言出法随 -- Chaterm如何通过ASR精准操作K8S
云原生·容器·kubernetes
伟大的大威2 天前
NVIDIA DGX Spark (ARM64/Blackwell) Kubernetes 集群 + GPU Operator 完整部署指南
大数据·spark·kubernetes