27. 云原生流量治理之kubesphere灰度发布

云原生专栏大纲

文章目录

  • 灰度发布介绍
  • 灰度发布策略
  • KubeSphere中恢复发布策略
      • 蓝绿部署
      • 金丝雀发布
      • 流量镜像
  • 灰度发布实战
    • 部署自制应用
    • 金丝雀发布
      • 创建金丝雀发布任务
      • 测试金丝雀发布情况
    • 蓝绿部署
      • 创建蓝绿部署
      • 测试蓝绿部署情况
    • 流量镜像
      • 创建流量进行任务
      • 测试流量镜像情况
  • 灰度发布真实案例分析

灰度发布介绍

灰度发布(Gray Release)是一种软件发布策略,用于逐步将新版本的软件或功能引入到生产环境中,以减少潜在的风险和影响范围。与传统的全量发布方式相比,灰度发布可以在一小部分用户或服务器上进行测试和验证,然后逐步扩大范围,直到全部用户或服务器都使用新版本。
灰度发布的核心思想是控制发布的范围和比例,以确保新版本在生产环境中的稳定性和可靠性。它可以帮助开发团队在实际用户环境中验证新功能、修复潜在问题,并收集反馈,从而更好地掌握软件的运行情况。
以下是灰度发布的一般流程:

  1. 划分发布群体:将用户或服务器划分为不同的群体,例如按照地理位置、用户类型、用户行为等进行划分。这些群体可以是随机选择的一小部分用户,也可以是特定的服务器集群。
  2. 发布新版本:将新版本的软件或功能部署到选定的发布群体中。这可以通过部署到特定的服务器或将新功能在应用程序中启用来实现。
  3. 验证和监控:在发布群体中验证新版本的稳定性和性能。监控关键指标,包括错误率、性能指标、用户反馈等,以确保新版本的质量。
  4. 逐步扩大范围:如果新版本通过了验证,可以逐步扩大发布范围,将其应用于更多的用户或服务器。可以根据实际情况调整扩大范围的速度。
  5. 回滚和修复:如果在灰度发布过程中发现问题或负面影响,可以快速回滚到之前的版本,并修复问题。这需要有一个可靠的回滚机制和紧急修复计划。

通过灰度发布,可以降低新版本引入的风险,并在生产环境中逐步验证和改进软件。它可以提供更好的用户体验、更高的可靠性,并减少对整个系统的冲击。灰度发布通常与持续集成和持续交付(CI/CD)流程结合使用,以实现快速、可靠的软件发布和迭代。

灰度发布策略

灰度发布策略可以根据实际需求和环境来制定,以下是几种常见的灰度发布策略:

  1. 用户划分策略:将用户根据一定的规则或条件划分为不同的群体,然后逐步将新版本发布给这些群体。例如,可以按照用户ID的哈希值或随机选择一小部分用户进行初始发布,然后逐渐扩大发布范围。
  2. 地理位置策略:根据用户的地理位置将其划分为不同的群体。这对于全球性应用程序或服务特别有用。可以从一个或多个地理位置开始发布新版本,然后逐渐扩大到其他地理区域。
  3. 时间窗口策略:将发布限制在特定的时间窗口内,例如在非高峰期或低流量时间进行发布。这可以减少对系统性能的影响,并提供更好的控制和监控能力。
  4. 百分比策略:将新版本逐步引入到一小部分用户中,并逐渐增加比例。例如,开始时只发布给1%的用户,然后逐渐增加到10%,20%等,直到全部用户都在使用新版本。
  5. 功能开关策略:在代码中引入功能开关或配置项,通过控制开关或配置的状态来控制新功能的开启或关闭。这样可以在生产环境中逐渐开启新功能,以便进行测试和验证。
  6. 回滚策略:在灰度发布过程中,如果发现问题或负面影响,需要有一个可靠的回滚策略。可以快速回滚到之前的版本,并修复问题,以确保系统的稳定性。

在实施灰度发布策略时,需要结合实际情况和系统需求,选择适合的策略,并确保有足够的监控和反馈机制,以便及时发现和解决问题。灰度发布通常需要与持续集成和持续交付(CI/CD)流程结合使用,以实现自动化的发布和验证过程。

KubeSphere中恢复发布策略

蓝绿部署

蓝绿部署(Blue-Green Deployment)是一种在生产环境中进行软件发布和切换的策略,旨在实现无缝的部署和回滚过程。它通过在两个独立的环境(蓝色环境和绿色环境)中部署不同版本的应用程序来实现。
在蓝绿部署中,蓝色环境是当前正在运行的稳定版本,而绿色环境是新版本的部署目标。整个过程可以分为以下步骤:

  1. 部署蓝色环境:首先,将当前稳定版本的应用程序部署到蓝色环境中,使其对外提供服务。此时,所有的流量都会被蓝色环境处理。
  2. 部署绿色环境:在蓝色环境运行期间,将新版本的应用程序部署到绿色环境中,但不将其暴露给外部流量。这样可以在绿色环境中进行测试、验证和准备。
  3. 切换流量:当绿色环境中的新版本经过验证并准备就绪时,可以将流量逐步切换到绿色环境。这可以通过负载均衡器或代理服务器来实现,将一部分流量导向绿色环境,而将剩余的流量仍然发送到蓝色环境。
  4. 验证和监控:在切换流量后,需要仔细监控新版本在绿色环境中的性能、稳定性和用户反馈。这可以帮助发现潜在问题,并及时进行回滚或修复。
  5. 回滚和清理:如果在绿色环境中发现问题或不满意的情况,可以快速回滚到蓝色环境,恢复到之前的稳定版本。同时,还需要清理绿色环境中的部署和资源,以便下一次部署。

蓝绿部署的优势在于它提供了一种无缝切换和回滚的机制,减少了对生产环境的影响和风险。它还提供了更好的可用性和可靠性,因为在切换过程中,至少有一个环境是稳定运行的。同时,蓝绿部署也为持续交付和持续集成流程提供了支持,使团队能够更快地交付新功能和修复。
需要注意的是,蓝绿部署可能需要额外的资源和成本来维护两个独立的环境,并需要谨慎规划和管理切换过程,以确保顺利和可靠的发布。

金丝雀发布

金丝雀发布(Canary Release)是一种用于软件部署和测试的策略,旨在逐步引入新版本的功能和变化,以减少潜在的风险。金丝雀发布通过将新版本的应用程序或功能逐步引入到一小部分用户或流量中,以便测试和验证其性能、稳定性和用户反馈。
以下是金丝雀发布的一般步骤:

  1. 确定目标:首先,需要明确金丝雀发布的目标和指标。例如,可以选择一小部分用户、特定地理区域或特定的功能使用者作为目标。
  2. 创建金丝雀环境:在金丝雀发布中,需要创建一个独立的环境来承载新版本的应用程序或功能。这个环境可以是一个独立的服务器、容器或命名空间。
  3. 部署新版本:将新版本的应用程序或功能部署到金丝雀环境中。这个版本可能包含一些新的功能、修复或其他变化。
  4. 引入流量:逐步将一小部分流量或用户导向金丝雀环境。可以使用负载均衡器、代理服务器或路由规则来控制流量的分发。
  5. 监控和验证:在金丝雀环境中,需要仔细监控新版本的性能、稳定性和用户反馈。这可以通过日志、指标、异常报告等方式进行。
  6. 逐步增加流量:如果新版本在金丝雀环境中表现良好,可以逐步增加流量或用户比例,将更多的流量导向金丝雀环境。
  7. 回滚或推进:根据监控和验证的结果,可以选择回滚到之前的版本或继续推进新版本的发布。如果发现问题或不满意的情况,及时回滚可以减少对用户的影响。

金丝雀发布的优势在于它提供了一种渐进式的发布和验证机制,可以在较小的范围内测试新版本,减少潜在的风险和影响。它还可以帮助团队更快地获取用户反馈,并根据反馈进行调整和改进。
需要注意的是,金丝雀发布需要有良好的监控和反馈机制,以便及时发现问题并采取相应的措施。同时,也需要考虑金丝雀环境的资源和成本,以及逐步增加流量的策略和时间表。

流量镜像

流量镜像(Traffic Mirroring)是一种网络流量管理技术,它允许将网络流量从一个网络设备镜像到另一个设备或系统进行监控、分析或其他目的。通过流量镜像,可以实时复制网络流量并将其传送到指定的目标位置,而不会中断原始流量的正常传输。
流量镜像通常在网络设备(如交换机、路由器、防火墙)上进行配置。以下是流量镜像的一般工作流程:

  1. 选择源和目标:首先,需要选择要镜像的源设备和要将镜像流量发送到的目标设备或系统。源设备通常是网络中的某个交换机或路由器,而目标设备可以是监控系统、网络分析工具或其他需要分析流量的系统。
  2. 配置镜像策略:在源设备上配置镜像策略,以指定要镜像的流量类型和目标设备。可以选择镜像特定的端口、协议、IP地址范围或其他标识符来过滤要镜像的流量。
  3. 镜像流量传输:源设备根据配置的镜像策略,将匹配的流量复制到指定的目标设备或系统。这通常通过将镜像流量封装在专用的镜像数据包中,并通过网络传输到目标设备。
  4. 流量分析和监控:在目标设备或系统上,可以对镜像流量进行分析、监控或其他操作。这可以包括网络流量分析、安全审计、故障排除或性能优化等。

流量镜像的优势在于它提供了一种非侵入性的方式来监控和分析网络流量,而不会影响原始流量的传输和性能。它可以帮助网络管理员和安全团队实时监控网络流量,检测异常活动、网络攻击或其他问题。同时,流量镜像也对网络故障排除和性能优化提供了有价值的数据。
需要注意的是,流量镜像可能会对网络设备和系统的性能产生一定的影响,因此在配置和使用时需要谨慎考虑。此外,合规性和隐私问题也需要在使用流量镜像时加以注意,并确保符合适用的法律和规定。

常见用例包括:

  • 测试新的应用版本。您可以对比镜像流量和生产流量的实时输出。
  • 测试集群。您可以将实例的生产流量用于集群测试。
  • 测试数据库。您可以使用空数据库来存储和加载数据。

灰度发布实战

需安安装servicemesh组件,参考《16.云原生之kubesphere组件安装卸载》

部署自制应用

  1. 部署示例项目

27. 云原生流量治理之kubesphere灰度发布_第1张图片

  1. 开启服务治理

27. 云原生流量治理之kubesphere灰度发布_第2张图片

  1. 服务暴露配置

27. 云原生流量治理之kubesphere灰度发布_第3张图片
image.png
配置hostimage.png


27. 云原生流量治理之kubesphere灰度发布_第4张图片

  1. 查看部署情况

27. 云原生流量治理之kubesphere灰度发布_第5张图片

  1. 访问页面测试

27. 云原生流量治理之kubesphere灰度发布_第6张图片

金丝雀发布

创建金丝雀发布任务

  1. 创建灰度发布任务入口

27. 云原生流量治理之kubesphere灰度发布_第7张图片
27. 云原生流量治理之kubesphere灰度发布_第8张图片

  1. 创建任务review-v2版本任务

27. 云原生流量治理之kubesphere灰度发布_第9张图片

  1. 选择review下一步

27. 云原生流量治理之kubesphere灰度发布_第10张图片

  1. 选择review灰度发布使用的镜像版本

27. 云原生流量治理之kubesphere灰度发布_第11张图片

  1. 调整流量

27. 云原生流量治理之kubesphere灰度发布_第12张图片
调整请求参数可以更精确匹配
27. 云原生流量治理之kubesphere灰度发布_第13张图片

  1. 查看创建情况

27. 云原生流量治理之kubesphere灰度发布_第14张图片

测试金丝雀发布情况

  1. 浏览器中访问测试

27. 云原生流量治理之kubesphere灰度发布_第15张图片
27. 云原生流量治理之kubesphere灰度发布_第16张图片

  1. 模拟请求不断访问,测试流量比例
watch -n 1 curl http://productpage.base.192.168.31.11.nip.io/productpage?u=normal

image.png
点击进入查看详情
27. 云原生流量治理之kubesphere灰度发布_第17张图片

注意:这儿这个流量比例不一定完全精确,可以通过折线图看基本一致

  1. 新版本接管

当新版没有问题,能接管老版本时,需设置新版本接管(或流量调到100%),如下
27. 云原生流量治理之kubesphere灰度发布_第18张图片

  1. 删除发布任务

新版本 接管后,删除金丝雀发布任务,即可删除老版本
27. 云原生流量治理之kubesphere灰度发布_第19张图片

蓝绿部署

创建蓝绿部署

创建步骤跟金丝雀发布类似,下述截关键的图

  1. 选择服务

27. 云原生流量治理之kubesphere灰度发布_第20张图片

  1. 将版本修改回v1

27. 云原生流量治理之kubesphere灰度发布_第21张图片

27. 云原生流量治理之kubesphere灰度发布_第22张图片

  1. 查看创建情况

image.png

测试蓝绿部署情况

27. 云原生流量治理之kubesphere灰度发布_第23张图片
v1接管v2,查看下图转折点
27. 云原生流量治理之kubesphere灰度发布_第24张图片

流量镜像

创建流量进行任务

创建步骤跟金丝雀发布类似,下述截关键的图

  1. 选择服务

27. 云原生流量治理之kubesphere灰度发布_第25张图片

  1. 流量镜像一般需要和正式环境版本保持一致,最大还原生产环境

注意:这儿测试选v2版本,访问测试看是否会返回v2版本页面

27. 云原生流量治理之kubesphere灰度发布_第26张图片
image.png

测试流量镜像情况

watch -n 1 curl http://productpage.base.192.168.31.11.nip.io/productpage?u=normal

测试无v2版本页面数据返回
27. 云原生流量治理之kubesphere灰度发布_第27张图片

灰度发布真实案例分析

l 背景描述:xx公司充电桩系统,接入三方公司充电桩,用户充电三方公司会将相关数据回调传输到xx公司充电桩系统。充电桩系统升级存在问题:

  1. 三方公司回调只接入到了xx公司生产环境
  2. 升级后路测需去现场,并需三方充电桩IOT公司接入
  3. 升级后代码,需发布到生产环境,影响较大

为减小对线上的影响,需采用蓝灰度发布。

l 传统做法:使用openresty、lua,对请求进行拦截判断,判断请求是否携带目标充电桩id和用户id,若满足打到目标环境。

l 传统做法和kubesphere中金丝雀发布对比:

  1. 传统做法将修改代码还是发布到了生产环境,只是通过判断,判断是否走修改逻辑
  2. kubesphere中金丝雀发布,将新版本代码另外发布了一个服务,不会影响原来服务,通过服务治理组件(边车)istio来判断请求中的参数,进行流量控制

你可能感兴趣的:(私有云+云原生实战,云原生)