- 综合排序
- 最热优先
- 最新优先
- 来自专栏ThoughtWorks
漫谈金丝雀部署
一段时间后，人们发现金丝雀这种生物对于有毒气体更加敏感。在 1900 年开始有记录显示，一些矿井开始把金丝雀作为井下有毒气体的预警物种。 后来，人们为了能重复使用金丝雀，发明了一个用于金丝雀毒气探测的专用笼子。笼子可以主动充氧，前方设有一个通气孔，通气孔可以通过密闭窗进行开启和关闭。在需要金丝雀进行预警的时候,把通气孔打开。 如果笼子中的金丝雀被毒气毒晕，关上通气孔的窗口并让笼子充满氧气。如果金丝雀如果没有被毒死，就有可能活过来。 金丝雀部署，这种部署方式的目标与逻辑和使用金丝雀来预警非常类似(通过开关通气孔/流量的方式来控制危害与恢复能力)，我猜想可能大家也希望能纪念一下在 20 世纪为矿工献出生命的金色小鸟们，所以这种方式被冠上了金丝雀的名称 金丝雀发布 or 金丝雀部署? 在交流和口语中，大家习惯于将发布和部署混用。
59330编辑于 2022-02-16 - 来自专栏痴者工良
Isito 入门（八）：金丝雀发布
6，金丝雀发布 项目总是处于不断变化之中，每次发布新的版本时，都考验了团队的运维能力。 【图源：互联网】 新版本上线之前，经历过开发和测试人员的验证，也经过产品经理的验收。 金丝雀发布 尴尬，在学习 Istio 之前，我对蓝绿发布、灰度发布、金丝雀发布的概念并不清晰，很多文章都是将它们分成三类发布方式。实际上蓝绿发布和金丝雀发布都是灰度发布的一种。 所以，可以把蓝绿发布、A/B 测试、金丝雀发布都划分为灰度发布。 当然，它们有一些差别，每个人的划分方法也有差别，有的说法是金丝雀发布才是灰度发布。 金丝雀发布 先上线一个新版本，然后根据规则将一小部分用户导向到新应用，观察新版本在生产环境的表现，如果达到预期，则逐步将流量切换到新版本中。 金丝雀发布其实很简单，除了 Istio 之外，我们通过 Nginx、Apisix、Kong 等网关都可以轻松实现。
1.1K50编辑于 2023-11-03 - 来自专栏JavaEdge
KubeSphere实现金丝雀发布（Canary Release）
0 前言 KubeSphere 基于 [Istio] 向用户提供金丝雀发布功能，即： 引入服务的新版本，并向其发送一小部分流量来进行测试 同时，旧版本负责处理其余的流量 如果一切顺利，就可逐渐增加向新版本发送的流量 参见创建企业空间、项目、用户和角色 开启应用治理并有一个可用应用，以便实现该应用的金丝雀发布。本教程使用示例应用 Bookinfo。参见部署 Bookinfo 和管理流量。 1 创建金丝雀发布任务 登录 KubeSphere 控制台： 转到灰度发布页面，点击创建灰度发布任务： 在发布模式选项卡，点击金丝雀发布右侧的创建： 设置任务名称，点击下一步： 在服务设置选项卡，从下拉列表中选择你的应用和要实现金丝雀发布的服务 操作完成后，点击创建： 结果： 点击进去查看，v2的资源已被创建： 到工作负载下观察： 2 验证金丝雀发布 现在有两个可用的应用版本了，访问该应用以验证金丝雀发布。 5 接管所有流量 若一切运行顺利，则可以将所有流量引入新版本： 在任务状态中，点击金丝雀发布任务 在弹出的对话框中，点击 reviews v2 右侧的 ，选择接管。
54021编辑于 2024-01-12 - 来自专栏k8s技术圈
Argo Rollouts 实现蓝绿金丝雀发布
Argo Rollouts 是一个 Kubernetes Operator 实现，它为 Kubernetes 提供更加高级的部署能力，如蓝绿、金丝雀、金丝雀分析、实验和渐进式交付功能，为云原生应用和服务实现自动化 BuildDate: 2021-06-15T19:36:10Z GitCommit: 7a23fe5dbf78181248c48af8e5224246434e7f99 GitTreeState # 定义5个副本 strategy: # 定义升级策略 canary: # 金丝雀发布 steps: # 发布的节奏 - setWeight: 20 watch rollouts 当 demo rollout 到达第二步时，我们可以从插件中看到，Rollout 处于暂停状态，现在有5个副本中的1个运行新版本的 pod，其余4个仍然运行旧版本，这相当于 所以，这个 Rollout 有一个限制，即它只能实现 20% 的最小加权，通过扩展5个pod中的一个来运行新版本。
3.3K30发布于 2021-07-23 - 来自专栏黑客下午茶
Linkerd 金丝雀部署与 AB 测试
自动金丝雀推进 Flagger 实施了一个控制循环，在测量 HTTP 请求成功率、请求平均持续时间和 Pod 健康状况等关键性能指标的同时，逐渐将流量转移到金丝雀。 Flagger 金丝雀阶段 通过更新容器镜像触发金丝雀部署： kubectl -n test set image deployment/podinfo \ podinfod=stefanprodan/ ，流量将路由回主服务器，金丝雀缩放为零，并将推出标记为失败。 如果 404s 率达到 3% 阈值，则分析将中止，金丝雀被标记为失败。 $namespace.svc.cluster.local:9898; proxy_hide_header l5d-remote-ip; proxy_hide_header l5d-server-id
93140发布于 2021-07-30 - 来自专栏SY小站的专栏
ingress-nginx高级金丝雀发布
通过修改nginx.ingress.kubernetes.io/configuration-snippet配置，并且配置正则实现：
84830发布于 2020-06-15 - 来自专栏院长运维开发
ingress-nginx金丝雀发布
ingress-nginx金丝雀 原有的 ingress 不需要改变 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: tomcat-test
69020发布于 2020-06-11 - 来自专栏SY小站的专栏
ingress-nginx金丝雀发布
2. ingress-nginx金丝雀 2.1 原有ingress不需要改变 apiVersion: extensions/v1beta1 kind: Ingress metadata: name:
51530发布于 2020-06-15 - 来自专栏云原生工具箱
Istio 升级新方式：金丝雀升级
而 1.6 发布也有一段时间了，目前都已经到了 1.6.4 版本，就升级部分，Istio 1.6 推出了渐进式的升级方式：金丝雀升级，为相对头疼的 Istio 升级问题提供了一种解决方案。 金丝雀升级 顾名思义，金丝雀升级可以让新老版本的 istiod 同时存在，并允许将所有流量在由新版控制平面 istiod-canary 控制之前，先将一小部分工作负载交由新版本 istiod-canary ojson | grep hostname "hostname": "istiod-canary.istio-system.svc" 这时 default namespace 内的 Pod 就完成了金丝雀升级 总结 总体来说，金丝雀升级的出现很好的解决了控制平面渐进式升级的需求，但是由于istioctl upgrade命令支持的场景和版本太少以及 Istio 整体架构的更改，目前的原地升级体验很差。
1.5K10发布于 2020-12-30 - 来自专栏我的小碗汤
ingress-nginx实现灰度和金丝雀发布
use_under_30_feature为always的时候，则会访问demo-canary 基于服务权重的流量切分 nginx.ingress.kubernetes.io/canary-weight：将路由到金丝雀
5.6K40发布于 2019-07-30 - 来自专栏DevOps时代的专栏
使用 Istio 实现灰度发布（金丝雀发布）
可以通过灰度发布（又名金丝雀发布）来实现业务从老版本到新版本的平滑过渡，并避免升级过程中出现的问题对用户造成的影响。 “金丝雀发布”的来源于矿工们用金丝雀对矿井进行空气测试的做法。 以前矿工挖煤的时候，矿工下矿井前会先把金丝雀放进去，或者挖煤的时候一直带着金丝雀。金丝雀对甲烷和一氧化碳浓度比较敏感，会先报警。所以大家都用“金丝雀”来搞最先的测试。 灰度发布（金丝雀发布）的流程如下： 准备和生产环境隔离的“金丝雀”服务器。 将新版本的服务部署到“金丝雀”服务器上。 对“金丝雀”服务器上的服务进行自动化和人工测试。 测试通过后，将“金丝雀”服务器连接到生产环境，将少量生产流量导入到“金丝雀”服务器中。 备注：本例只是描述原理，因此为简单起见，将50%流量导入V2版本，在实际操作中，更可能是先导入较少流量，然后根据监控的新版本运行情况将流量逐渐导入，如采用5%，10%，20%，50% …的比例逐渐导入。
7.6K52发布于 2020-04-14 - 来自专栏架构驿站
基于 Flagger Operator 的 Traefik 金丝雀部署
在整个持续交付体系中，金丝雀发布，或许是最为经典的一个场景，基于此，我们能够很快发现不健康和“有问题”的服务，并且可以毫不费力地回滚到上一个的版本。 金丝雀部署 什么是金丝雀部署？ interval: 1m 上述配置通过检查 HTTP 404 req/sec 百分比是否低于总流量的 5% 来验证金丝雀。 如果 404s 率达到 5% 阈值，则金丝雀失败。 7.60 > 5 Halt podinfo.test advancement 404s percentage 8.69 > 5 Halt podinfo.test advancement 404s percentage 9.70 > 5 Rolling back podinfo.test failed checks threshold reached 5 Canary failed!
1.6K50编辑于 2021-12-10 - 来自专栏院长运维开发
ingress-nginx高级金丝雀发布
开源ingress实现 通过修改nginx.ingress.kubernetes.io/configuration-snippet配置，并且配置正则实现：
1.4K20发布于 2020-06-11 - 来自专栏YP小站
K8S 金丝雀部署之 Istio
什么是金丝雀发布? 金丝雀发布（Canary）：也是一种发布策略，和国内常说的灰度发布是同一类策略。蓝绿部署是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统。 如将 10％ 的流量发送到金丝雀版本（v2）。 高层次的金丝雀部署 只允许特定网站上50％的用户流量路由到金丝雀（v2）版本，而其他用户则不受影响 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService gateway 总结 本文中，我们看到了 Istio 如何支持通用可扩展的金丝雀部署。 这允许简单而强大的方式来进行金丝雀测试和上线。 支持金丝雀部署的智能路由只是 Istio 的众多功能之一，它将使基于大型微服务的应用程序的生产部署变得更加简单。查看 istio.io 了解更多信息。
2.3K11发布于 2020-06-04 - 来自专栏架构驿站
基于 Flagger Operator 的 Traefik 金丝雀部署
在整个持续交付体系中，金丝雀发布，或许是最为经典的一个场景，基于此，我们能够很快发现不健康和“有问题”的服务，并且可以毫不费力地回滚到上一个的版本。 金丝雀部署 什么是金丝雀部署？ interval: 1m 上述配置通过检查 HTTP 404 req/sec 百分比是否低于总流量的 5% 来验证金丝雀。 如果 404s 率达到 5% 阈值，则金丝雀失败。 7.60 > 5 Halt podinfo.test advancement 404s percentage 8.69 > 5 Halt podinfo.test advancement 404s percentage 9.70 > 5 Rolling back podinfo.test failed checks threshold reached 5 Canary failed!
76360发布于 2021-11-24 - 来自专栏运维开发故事
使用argo-rollouts实现金丝雀发布
支持特性如下： 蓝绿色更新策略 金丝雀更新策略 细粒度，加权流量转移 自动回rollback和promotion 手动判断 可定制的指标查询和业务KPI分析 入口控制器集成：NGINX，ALB 服务网格集成 /kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts 金丝雀发布 金丝雀发布包含Replica Shifting Current: 5 Updated: 5 Ready: 5 Available: 5 NAME Traffic Shifting 上面我们并没有接入外部流量，仅仅是在内部使用展示了金丝雀部署过程，下面我们接入外部流量进行测试。 通过测试来看，Argo-Rollout提供更加强大的Deployment，包含比较适合运维的金丝雀发布和蓝绿发布功能，要使用蓝绿发布，仅需要配置rollout，如下： apiVersion: argoproj.io
3K80发布于 2020-12-16 - 来自专栏云原生运维社区
Ingress企业实战：金丝雀与蓝绿发布篇
什么是金丝雀发布 金丝雀发布，又称灰度发布，是指通过让小部份用户流量引入的新版本进行测试，如果一切顺利，则可以增加（可能逐渐增加）百分比，逐步替换旧版本。 最简单的方式是随机选择百分比请求到金丝雀版本，但在更复杂的方案下，则可以基于请求的内容、特定范围的用户或其他属性等。 总结 本文介绍了金丝雀发布与蓝绿发布，并以企业案例的方式讲解了不同的场景使用什么样的发布方式，下一章将介绍Ingress 证书管理与双向认证，请敬请期待！
97320编辑于 2023-09-11 - 来自专栏物流IT圈
蓝绿部署、金丝雀发布（灰度发布）和AB测试
1.说明 蓝绿部署、A/B测试、金丝雀发布，以及灰度发布、流量切分等，经常被混为一谈，影响沟通效率。 根本原因是这些名词经常出现，人们耳熟能详能够熟练地谈起，对这些术语的理解却没有达成一致。 3.金丝雀发布/灰度发布 金丝雀发布（Canary）/ 灰度发布也是一种发布策略，和国内常说的灰度发布是同一类策略。 这个控制叫做“流量切分”，既可以用于金丝雀发布，也可以用于后面的A/B测试。 蓝绿部署和金丝雀发布是两种发布策略，都不是万能的。有时候两者都可以使用，有时候只能用其中一种。 上面的例子中可以用金丝雀，不能用蓝绿，那么什么时候可以用蓝绿，不能用金丝雀呢？整个系统只有一台服务器的时候。 A/B测试(A/B Testing) 首先需要明确的是，A/B测试和蓝绿部署以及金丝雀，完全是两回事。 蓝绿部署和金丝雀是发布策略，目标是确保新上线的系统稳定，关注的是新系统的BUG、隐患。
1.3K31发布于 2019-07-16 - 来自专栏云原生运维社区
如何使用Higress快速实现金丝雀与蓝绿发布
什么是金丝雀发布 金丝雀发布，又称灰度发布，是指通过让小部份用户流量引入的新版本进行测试，如果一切顺利，则可以增加（可能逐渐增加）百分比，逐步替换旧版本。 最简单的方式是随机选择百分比请求到金丝雀版本，但在更复杂的方案下，则可以基于请求的内容、特定范围的用户或其他属性等。 总结 本文介绍了金丝雀与蓝绿发布及不同的应用场景，并基于Higress结合企业实战案例进行演示，让大家更容易理解上手，接下来的文章会讲解Higress更多企业级应用实战，请敬请期待！
1.4K20编辑于 2023-10-09 - 来自专栏云原生工具箱
基于 Flagger 和 Nginx-Ingress 实现金丝雀发布
本文主要介绍 Flagger 使用 Nginx-Ingress 进行金丝雀发布并监控发布状态，更多内容见官方文档[2]。 ? # 百分比 (0-100) maxWeight: 50 # 金丝雀每次递增的百分比 # 百分比 (0-100) stepWeight: 5 # NGINX 自动金丝雀发布 通过更新镜像版本触发金丝雀部署： $ kubectl -n test set image deployment/podinfo podinfod=stefanprodan/podinfo 金丝雀发布 发布成功后，会收到 Slack 通知： ? Slack 通知 自动回滚 当然，有自动发布就会有自动回滚，下面就通过手动触发状态码 500 异常，演示暂停发布并回滚。 B 测试 Slack 通知 正常访问，还是访问到老的 v3.1.1 版： $ curl http://app.example.com { "hostname": "podinfo-primary-5dc6b76bd5
1.4K30发布于 2020-12-30
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号