基于 Zadig + Ingress 实现单应用灰度发布最佳实践
在当前激烈的软件开发竞争中,工程师们面临着众多挑战,其中最为关键的是如何在发布过程中确保稳定性、可靠性以及高效性。为了解决这一问题,企业通常会根据业务架构和应用场景综合选择适用的发布策略。在我们之前的文章「基于 Istio + Zadig,零负担实现云原生全链路灰度发布」中,Zadig 为微服务架构提供了通用的全链路灰度发布方案。然而,在实际场景中,仍有许多业务处于单体架构或单应用发布阶段。因此,Zadig 结合 Ingress 提供了专为单应用生产发布场景设计的安全保障方案。
本文将详细介绍如何结合 Zadig 和 Ingress 实现生产稳定发布的基本原理,并通过实际案例演示在 Zadig 中的具体操作。
基本原理
说明:生产版本和新版本(蓝环境)在 Zadig 同一个生产环境中管理。
工作原理:
1. 部署蓝环境:复制当前 workload,设置新镜像,并创建一个 blue service 指向它。
2. 切换部分生产流量到蓝环境:在原来 ingress 基础上创建一个相同 Host 的 ingress-blue ,service 指向 blue service,并且开启 nginx.ingress.kubernetes.io/canary: "true",并按实际情况修改权重配置 nginx.ingress.kubernetes.io/canary-weight:20。
3. 蓝绿发布:将生产使用的 workload 镜像设置为新镜像。
4. 切断蓝环境流量:修改 ingress-blue 配置 nginx.ingress.kubernetes.io/canary: "false"。
5. 蓝绿清理:工作流执行完成后,无论最终为何种状态,删除 blue service、blue workload 。
下面将详细介绍如何在 Zadig 中结合 Ingress 实现安全、稳定、高效的生产发布。
项目准备
创建项目
创建项目,配置生产服务a、b、c。本示例源码和服务 YAML 配置参考项目。
在 a 服务 YAML 配置上添加 ingress 配置:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: a-ingress annotations: nginx.ingress.kubernetes.io/rewrite-target: / spec: ingressClassName: koderover rules: - host: a-prod.edu.koderover.com http: paths: - path: / pathType: Prefix backend: service: name: a port: number: 8080
配置环境
1. 创建生产环境 prod > 管理服务 > 添加服务,选择 a、b、c。
2. 添加 ingress-blue ,为生产发布配置做准备。
在 a 服务 ingress-blue 配置如下:
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: a-ingress-blue annotations: nginx.ingress.kubernetes.io/rewrite-target: / nginx.ingress.kubernetes.io/canary: "false" nginx.ingress.kubernetes.io/canary-weight: "0" spec: ingressClassName: koderover rules: - host: a-prod.edu.koderover.com #此处和 a 服务 ingress 配置中使用的 host 保持一致 http: paths: - path: / pathType: Prefix backend: service: name: a-blue #指向 a 服务新版本的 service port: number: 8080
配置工作流
新建工作流 > 选择 「蓝绿发布」模板 > 配置工作流,工作流包含步骤和具体配置如下:
选择模板
工作流配置
1. 部署蓝绿环境:使用「部署蓝绿环境」任务,添加 服务 a。
部署蓝环境配置
2. 导 50 流量: 使用「更新 K8s YAML 任务」,选择 ingress-blue 配置,并设置 nginx.ingress.kubernetes.io/canary: "true",nginx.ingress.kubernetes.io/canary-weight: "50"。
导 50 流量配置
3. 检查新版本: 使用「通用任务」或者「测试」任务来配置对应的检查脚本,针对新版本进行自动化测试。
4. 审批:在生产升级阶段上开启「人工审批」,来保证发布的可靠性。
审批配置
5. 生产升级:使用「蓝绿发布」任务,注意配置中前置「部署蓝绿环境」任务需要正确选择。
生产升级配置
6. 切断流量:使用「更新 K8s YAML 任务」,选择 ingress-blue 配置,并设置 nginx.ingress.kubernetes.io/canary: "false",nginx.ingress.kubernetes.io/canary-weight: "0"。
切断流量配置
执行生产发布
执行工作流
按照以下配置执行工作流:
· 部署蓝环境:服务组件选择 myapp-1(a),以及选择需要发布的镜像
· 导 50 流量:选择 ingress-blue 资源
· 切断流量:选择 ingress-blue 资源
执行工作流
审批状态
工作流运行至待审批状态时,已完成自动部署蓝环境、导入 50% 流量到新版本中、对生产环境自动化测试验证三个操作。下面结合 Zadig 环境能力来验证流量走向是否符合预期。
效果验证
在发布过程中,服务 a 存在两组 deployment 和 service,分别为生产版本和新版本,此时,预期 50% 流量进入生产版本,50% 流量进入新版本。
发布过程中的服务情况
发布过程中 service 情况
执行以下请求,查看服务日志以验证流量分配结果。
for i in $(seq 1 100); do curl -X PUT http://a-prod.edu.koderover.com/api/v1/count; done
请求分别进入服务 a 生产版本和新版本的数量:
进入生产版本的请求数量
进入新版本的请求数量
人工审批通过后,工作流自动更新生产环境镜像,并将流量全部切回生产,最后清理所有临时资源。
生产版本升级完成
流量全部进入生产版本
至此,一次完整的生产发布已经完成。在实际使用过程中,可以结合监控数据在人工审批阶段控制新版本上线的时间,以确保在使用低峰时段进行生产发布,减少上线过程对用户的影响。
Zadig,让工程师更加专注创造
阅读原文 / Zadig 在 Github / Zadig 在 Gitee
推荐阅读 :
200 小时深度体验分析,DevOps 选型重磅发布 / Zadig vs. Jenkins 详细比对:时代的选择与开发者之选 / 基于 Istio + Zadig,零负担实现云原生全链路灰度发布 / 探索 Zadig 自测模式,一套环境多人协同,释开发者创造力! / ZADIG 专家版倾情上线:一键高效发布,119元/人月起,社区老友享年终福利!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
容易发生内存泄漏的八个场景,你都知道吗?
内存泄漏与内存溢出 JVM在运行时会存在大量的对象,一部分对象是长久使用的,一部分对象只会短暂使用 JVM会通过可达性分析算法和一些条件判断对象是否再使用,当对象不再使用时,通过GC将这些对象进行回收,避免资源被用尽 内存泄漏:当不再需要使用的对象,因为不正确使用时,可能导致GC无法回收这些对象 当不正确的使用导致对象生命周期变成也是宽泛意义上的内存泄漏 内存溢出:当大量内存泄漏时,可能没有资源为新对象分配 举例内存泄漏 接下来将从对象生命周期变长、不关闭资源、改变对象哈希值、缓存等多个场景举例内存泄漏 对象生命周期变长引发内存泄漏 静态集合类 public class StaticClass { private static final List<Object> list = new ArrayList<>(); /** * 尽管这个局部变量Object生命周期非常短 * 但是它被生命周期非常长的静态列表引用 * 所以不会被GC回收 发生内存溢出 */ public void addObject(){ Object o = new Object(); list...
- 下一篇
AIGC下一步:如何用AI再度重构或优化媒体处理?
让媒资中“沉默的大多数”再次焕发光彩。 邹娟|演讲者 编者按 AIGC时代下,媒体内容生产领域随着AI的出现也涌现出更多的变化与挑战。面对AI的巨大冲击,如何优化或重构媒体内容生产技术架构?在多样的应用场景中媒体内容生产技术又有着怎样的实践效果?LiveVideoStackCon2023深圳站邀请到阿里云智能资深技术专家邹娟,与大家分享阿里云视频云的媒体内容生产技术实践。 策划 撰写 / LiveVideoStack、IMMENSE 《AIGC时代下阿里云视频云媒体内容生产技术实践》主题分享,包含如下四个部分: 01 AIGC时代的媒体内容生产技术架构 首先给大家分享阿里云视频云媒体服务的顶层架构设计,这为AIGC的快速落地奠定了基础。媒体服务整体架构分三层。 最底层是云原生底座,阿里云视频云构架在分布式云原生框架之上,视频云与我们的客户一样,自身也是云的使用者,可以获得云计算IaaS层弹性、按需按量、规模化的红利。 中间层为媒体基础层,即媒体服务的底层技术核心。 这一层分为三个部分:左侧的算法区域包括音视频编解码与增强算法、特效渲染算法、视觉AI算法、3A算法等。中间的媒体...
相关文章
文章评论
共有0条评论来说两句吧...