使用 Ingress 实现灰度发布 一.Canary 规则说明 Ingress-Nginx 是一个K8S ingress工具,支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试( Ingress-Nginx 是在0.21.0 版本 中,引入的Canary 功能). Nginx Annotations 支持以下 4 种 Canary 规则: nginx.ingress.kubernetes.io/canary-by-header:基于 Request Header

本篇已加入<.NET Core on K8S学习实践系列文章索引>,可以点击查看更多容器化技术相关系列文章. 之前一篇介绍了Ingress的基本概念和Nginx Ingress的基本配置和使用,本篇继续Ingress的使用,来看看如何使用Ingress实现灰度发布(金丝雀发布).此外,我也有录制一个10min+的小视频介绍蓝绿发布和金丝雀发布的基本概念,视频入口点击这里. 一.准备工作 1.1 WebAPI项目准备 首先,我们还是准备两个版本的ASP.NET Core WebAPI项目,具体项

灰度发布在实际生产部署中是经常被使用的方式,常规的方法是手动从前端LB(负载均衡)上将后端服务器摘掉,然后,停服务,最后上传代码,完成软连接更新.在使用CI/CD工具时,这个过程变得自动化了,我们只需要通过Jenkins这个功能强大的开源持续集成和部署工具,就可以联合Gitlab 或 Gogs 来实现自动拉取代码,并根据自己编写的pipeline脚本,实现自动连接到LB上摘掉后端Server,并自动连接到后端Server上,上传代码,并重启服务,最后通过邮件通知管理员整个过程的结果报告.但今天,

通过Kubernetes+Istio的流量控制实现灰度发布,主要演示通过流量权重实现蓝绿,通过http自定义头实现金丝雀 准备环境 k8s和istio不想自己装的话可以在云上买个按量付费集群,用完即删,推荐华为云. 项目中用到的代码 用的springboot+springcloud feign做rest强类型调用,放到github了 https://github.com/assionyang/istio-test.git 代码结构说明 istio-service-union #聚合服务项目,用来

为什么需要灰度发布 灰度发布(又名金丝雀发布)是指在黑与白之间,能够平滑过渡的一种发布方式.在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来. 总结下一些应用场景: 微服务依赖很多组件,需要在实际环境验证 部署新功能有风险,然后可以通过导流一小部分用户实际使用,来减小风险 让特定的用户访问新版本,比如部署一个版本,只让测试使用 A/B Testing,部署两个版本,进行版本

之前介绍过使用ambassador实现灰度发布,今天介绍如何使用ingre-nginx实现. 介绍 Ingress-Nginx 是一个K8S ingress工具,支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试. Nginx Annotations 支持以下 4 种 Canary 规则: nginx.ingress.kubernetes.io/canary-by-header:基于 Request Header 的流量切分,适用于灰度发布以及 A/B 测试.当

K8s 1.18.6版本基于 ingress-nginx 实现金丝雀发布(灰度发布) 环境 软件 版本 kubernetes v1.18.6 nginx-ingress-controller 0.32.0 Rancher v2.4.5 本次实验基于 Rancher-v2.4.5 部署了1.18.6版本的k8s集群,nginx-ingress 版本为0.32.0,理论上 ingress-nginx >= 0.21.0都是可以的. 介绍 金丝雀发布:又叫灰度发布,控制产品从A版本平滑的过度到B版本

Istio是什么? Istio是Google继Kubernetes之后的又一开源力作,主要参与的公司包括Google,IBM,Lyft等公司.它提供了完整的非侵入式的微服务治理解决方案,包含微服务的管理.网络连接以及安全管理等关键能力,无需修改任何代码就能够实现微服务的负载均衡,服务与服务之间的认证授权以及监控.从整个基础设施角度上看,可以将它理解为PaaS平台上的一个面向微服务管理平台的补充. Istio架构示意图 Istio与Kubernetes Kubernetes提供了部署.升级和有限的

大家好,先简单自我介绍下,我叫厉辉,来自腾讯云.业余时间比较喜欢开源,现在是Apache APISIX PPMC.今天我来简单给大家介绍下 K8S Ingress 控制器的选型经验,今天我讲的这些内容需要大家对 K8S 有一定的了解,下面是我的分享. 名词解释 阅读本文需要熟悉以下基本概念: 集群:是指容器运行所需云资源的集合,包含了若干台云服务器.负载均衡器等云资源. 实例(Pod):由相关的一个或多个容器构成一个实例,这些容器共享相同的存储和网络空间. 工作负载(Node):Kubernet

作者:王炜,CODING DevOps 后端开发工程师,拥有多年研发经验,云原生.DevOps.Kubernetes 资深爱好者,Servicemesher 服务网格中文社区成员.获得 Kubernetes CKA.CKAD 认证. 前言 在 Kubernetes 上的应用实现灰度发布,最简单的方案是引入官方的 Nginx-ingress 来实现. 我们通过部署两套 deployment 和 services,分别代表灰度环境和生产环境,通过负载均衡算法,实现对两套环境的按照灰度比例进行分流,进

作者 | 李鹏(元毅) 来源 | Serverless 公众号 一.Knative Knative 提供了基于流量的自动扩缩容能力,可以根据应用的请求量,在高峰时自动扩容实例数:当请求量减少以后,自动缩容实例,做到自动化地节省资源成本.此外,Knative 还提供了基于流量的灰度发布能力,可以将流量的百分比进行灰度发布. 在介绍 Knative 灰度发布和自动弹性之前,先带大家了解一下 ASK Knative 中的流量请求机制. 如上图所示,整体的流量请求机制分为以下部分: 左侧是 Knativ

一.灰度发布 灰度发布是一种发布方式,也叫金丝雀发布,起源是矿工在下井之前会先放一只金丝雀到井里,如果金丝雀不叫了,就代表瓦斯浓度高.原因是金丝雀对瓦斯气体很敏感.灰度发布的做法是:会在现存旧应用的基础上,启动一个新版应用,但是新版应用并不会直接让用户访问.而是先让测试同学去进行测试.如果没有问题,则可以将真正的用户流量慢慢导入到新版,在这中间,持续对新版本运行状态做观察,直到慢慢切换过去,这就是所谓的A/B测试.当然,你也可以招募一些灰度用户,给他们设置独有的灰度标示(Cookie,Heade

文章转载自:https://mp.weixin.qq.com/s?__biz=MzU4MjQ0MTU4Ng==&mid=2247484478&idx=1&sn=238390dc34340ec291aed517f4a6cb9f&chksm=fdb90b23cace8235ef224bd086f9f3e9e29e07fa18d444e0edde5e76efa39bdbb921588726b8&cur_album_id=1319287026209947648&sc

软件总会有缺陷的,解决问题的同时往往会引入新的问题,关键是看这些问题是否在我们的控制范围内,“灰度发布”就是让问题受控的方法之一. 前言 我们的 CTO 经常说:“研发团队最首要的任务是提供稳定的服务,然后才是提供符合客户需求的.易用和低成本的产品”.但事实是,在提供稳定云服务的同时,面对快速发展的客户业务场景,我们还需要不断 “拥抱变化”. Max Kanat-Alexander 在<简约之美:软件设计之道>(Code Simplicity)中提出的软件设计的 6 条法则恰到好处的描述了这一

在 Bookinfo 微服务的灰度发布示例 中,KubeSphere 基于 Istio 对 Bookinfo 微服务示例应用实现了灰度发布.有用户表示自己的项目还没有上 Istio,要如何实现灰度发布? 在 Ingress-Nginx (0.21.0 版本) 中,引入了一个新的 Canary 功能,可用于为网关入口配置多个后端服务,还可以使用指定的 annotation 来控制多个后端服务之间的流量分配. KubeSphere 在 2.0.2 的版本 中,升级了项目网关 (Ingress Con

作者 | 邓洪超,阿里云容器平台工程师, Kubernetes Operator 第二人,云原生应用标准交付与管理领域知名技术专家   导读:近年来,越来越多专门给 Kubernetes 做应用发布的工具开始缤纷呈现,帮助大家管理和发布不断增多的 Kubernetes 应用.在做技术选型的时候,我们需要给业务选择一个最好的工具.最稳的底座.那么又该如何比较和衡量这些工具呢?本篇文章中阿里云技术专家邓洪超将会和大家分享自己独特的体验,帮助读者初步了解 Tekton 项目. 背景 近年来,伴随着云原

概述 如何在腾讯云 Kubernetes 集群实现蓝绿发布和灰度发布?通常要向集群额外部署其它开源工具来实现,比如 Nginx Ingress,Traefik 等,或者让业务上 Service Mesh(服务网格),利用服务网格的能力来实现.这些方案多多少少都是需要一点点门槛的,如果蓝绿发布或灰度发布的需求不复杂,同时不希望让集群引入更多的组件或复杂的用法,可以考虑使用本文的简单方案,利用 Kubernetes 原生的特性以及腾讯云 TKE/EKS 集群自带的 LB 插件实现简单的蓝绿发布和灰度

本期是Istio技术实践专题的最后一个模块,主题是Istio的路由控制与灰度发布.上一期我们讲到,虚拟服务(Virtual Service)以及目标规则(Destination Rule)是 Istio 流量路由的两大基石.虚拟服务可以将流量路由到 Istio 服务网格中的服务.每个虚拟服务由一组路由规则组成,这些路由规则按顺序进行评估.如果没有 Istio virtual service,仅仅使用 k8s service 的话,那么只能实现最基本的流量负载均衡转发,但是就不能实现类似按百分比来

此文系[大话云原生]系列第四篇,该系列文章期望用最通俗.简单的语言说明白云原生生态系统内的组成.架构以及应用关系.从这篇开始我们要开始针对Kubernetes进行介绍了,本文内容如下: 一.Kubernetes的Pod概念解析 前文说到老婆过生日了我们一起出去旅游,上了团体服务班车,小娜同学(老婆)闲聊到:"这服务还不错哈,2个跟车导游,1个司机".三句不离老本行,我无聊的说到:"他们三个人就是一个Pod,提供一天的旅游服务内容,有主有次不可分割". 小娜同学又上套

Kubernetes 作为基础平台,提供了强大的容器编排能力.但是在其上部署业务和服务治理上,仍然会面对一些复杂性和局限性.在服务治理上,已经有许多成熟的 ServiceMesh 框架用于扩充其能力,如 Istio.Linkerd.Dapr 等.本文将主要介绍如何使用 Istio 扩充 Kubernetes 灰度发布的能力. 而在部署上,则会利用开源项目 Rainbond 作为基础平台来进行实践.Rainbond 是一个云原生应用管理平台,它使用以应用为中心的设计模式.基于这一设计模式抽象出了标