- 综合排序
- 最热优先
- 最新优先
- 来自专栏ThoughtWorks
漫谈金丝雀部署
一段时间后，人们发现金丝雀这种生物对于有毒气体更加敏感。在 1900 年开始有记录显示，一些矿井开始把金丝雀作为井下有毒气体的预警物种。 后来，人们为了能重复使用金丝雀，发明了一个用于金丝雀毒气探测的专用笼子。笼子可以主动充氧，前方设有一个通气孔，通气孔可以通过密闭窗进行开启和关闭。在需要金丝雀进行预警的时候,把通气孔打开。 如果笼子中的金丝雀被毒气毒晕，关上通气孔的窗口并让笼子充满氧气。如果金丝雀如果没有被毒死，就有可能活过来。 金丝雀部署，这种部署方式的目标与逻辑和使用金丝雀来预警非常类似(通过开关通气孔/流量的方式来控制危害与恢复能力)，我猜想可能大家也希望能纪念一下在 20 世纪为矿工献出生命的金色小鸟们，所以这种方式被冠上了金丝雀的名称 金丝雀发布 or 金丝雀部署? 在交流和口语中，大家习惯于将发布和部署混用。
58530编辑于 2022-02-16 - 来自专栏痴者工良
Isito 入门（八）：金丝雀发布
6，金丝雀发布 项目总是处于不断变化之中，每次发布新的版本时，都考验了团队的运维能力。 【图源：互联网】 新版本上线之前，经历过开发和测试人员的验证，也经过产品经理的验收。 金丝雀发布 尴尬，在学习 Istio 之前，我对蓝绿发布、灰度发布、金丝雀发布的概念并不清晰，很多文章都是将它们分成三类发布方式。实际上蓝绿发布和金丝雀发布都是灰度发布的一种。 所以，可以把蓝绿发布、A/B 测试、金丝雀发布都划分为灰度发布。 当然，它们有一些差别，每个人的划分方法也有差别，有的说法是金丝雀发布才是灰度发布。 金丝雀发布 先上线一个新版本，然后根据规则将一小部分用户导向到新应用，观察新版本在生产环境的表现，如果达到预期，则逐步将流量切换到新版本中。 金丝雀发布其实很简单，除了 Istio 之外，我们通过 Nginx、Apisix、Kong 等网关都可以轻松实现。
1K50编辑于 2023-11-03 - 来自专栏JavaEdge
KubeSphere实现金丝雀发布（Canary Release）
0 前言 KubeSphere 基于 [Istio] 向用户提供金丝雀发布功能，即： 引入服务的新版本，并向其发送一小部分流量来进行测试 同时，旧版本负责处理其余的流量 如果一切顺利，就可逐渐增加向新版本发送的流量 参见创建企业空间、项目、用户和角色 开启应用治理并有一个可用应用，以便实现该应用的金丝雀发布。本教程使用示例应用 Bookinfo。参见部署 Bookinfo 和管理流量。 1 创建金丝雀发布任务 登录 KubeSphere 控制台： 转到灰度发布页面，点击创建灰度发布任务： 在发布模式选项卡，点击金丝雀发布右侧的创建： 设置任务名称，点击下一步： 在服务设置选项卡，从下拉列表中选择你的应用和要实现金丝雀发布的服务 操作完成后，点击创建： 结果： 点击进去查看，v2的资源已被创建： 到工作负载下观察： 2 验证金丝雀发布 现在有两个可用的应用版本了，访问该应用以验证金丝雀发布。 5 接管所有流量 若一切运行顺利，则可以将所有流量引入新版本： 在任务状态中，点击金丝雀发布任务 在弹出的对话框中，点击 reviews v2 右侧的 ，选择接管。
50921编辑于 2024-01-12 - 来自专栏k8s技术圈
Argo Rollouts 实现蓝绿金丝雀发布
Argo Rollouts 是一个 Kubernetes Operator 实现，它为 Kubernetes 提供更加高级的部署能力，如蓝绿、金丝雀、金丝雀分析、实验和渐进式交付功能，为云原生应用和服务实现自动化 蓝绿部署 金丝雀部署 与 Ingress 控制器和服务网格整合，实现高级流量路由 与用于蓝绿和金丝雀分析的指标提供者集成 根据成功或失败的指标，自动发布或回滚 渐进式交付 渐进式交付是以受控和渐进的方式发布产品更新的过程 Blue-Green Canary(金丝雀)：金丝雀发布指将一部分用户暴露在新版本的应用程序中，而将其余流量提供给旧版本，一旦新版本被验证是正确的，新版本可以逐渐取代旧版本。 使用金丝雀策略，用户指定他们希望新版本接收的百分比以及在百分比之间等待的时间。 部署 Rollout 首先我们部署一个 Rollout 资源和一个针对该资源的 Kubernetes Service 对象，这里我们示例中的 Rollout 采用了金丝雀的更新策略，将 20% 的流量发送到金丝雀上
3.3K30发布于 2021-07-23 - 来自专栏SY小站的专栏
ingress-nginx高级金丝雀发布
通过修改nginx.ingress.kubernetes.io/configuration-snippet配置，并且配置正则实现：
84330发布于 2020-06-15 - 来自专栏黑客下午茶
Linkerd 金丝雀部署与 AB 测试
金丝雀分析将运行五分钟，同时每半分钟验证一次 HTTP 指标和 rollout(推出) hooks。 自动金丝雀推进 Flagger 实施了一个控制循环，在测量 HTTP 请求成功率、请求平均持续时间和 Pod 健康状况等关键性能指标的同时，逐渐将流量转移到金丝雀。 Flagger 金丝雀阶段 通过更新容器镜像触发金丝雀部署： kubectl -n test set image deployment/podinfo \ podinfod=stefanprodan/ ，流量将路由回主服务器，金丝雀缩放为零，并将推出标记为失败。 如果 404s 率达到 3% 阈值，则分析将中止，金丝雀被标记为失败。
92340发布于 2021-07-30 - 来自专栏院长运维开发
ingress-nginx金丝雀发布
ingress-nginx金丝雀 原有的 ingress 不需要改变 apiVersion: extensions/v1beta1 kind: Ingress metadata: name: tomcat-test
68620发布于 2020-06-11 - 来自专栏SY小站的专栏
ingress-nginx金丝雀发布
2. ingress-nginx金丝雀 2.1 原有ingress不需要改变 apiVersion: extensions/v1beta1 kind: Ingress metadata: name:
51330发布于 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 - 来自专栏架构驿站
基于 Flagger Operator 的 Traefik 金丝雀部署
在整个持续交付体系中，金丝雀发布，或许是最为经典的一个场景，基于此，我们能够很快发现不健康和“有问题”的服务，并且可以毫不费力地回滚到上一个的版本。 金丝雀部署 什么是金丝雀部署？ 针对金丝雀部署工作流，其往往主要涉及以下阶段： Step 1：将流量从待部署节点移出，更新该节点服务至待发布状态，此时，节点称为“金丝雀节点”。 Step 2：依据不同的场景策略，将流量引入至金丝雀节点。 Step 3：金丝雀节点验证通过后，选取更多的节点作为金丝雀节点，然后重复步骤一和步骤二，直到所有节点全部更新至最新状态。 如果 404s 率达到 5% 阈值，则金丝雀失败。
1.6K50编辑于 2021-12-10 - 来自专栏DevOps时代的专栏
使用 Istio 实现灰度发布（金丝雀发布）
可以通过灰度发布（又名金丝雀发布）来实现业务从老版本到新版本的平滑过渡，并避免升级过程中出现的问题对用户造成的影响。 “金丝雀发布”的来源于矿工们用金丝雀对矿井进行空气测试的做法。 以前矿工挖煤的时候，矿工下矿井前会先把金丝雀放进去，或者挖煤的时候一直带着金丝雀。金丝雀对甲烷和一氧化碳浓度比较敏感，会先报警。所以大家都用“金丝雀”来搞最先的测试。 下图中，左下方的少部分用户就被当作“金丝雀”来用于测试新上线的1.1版本。如果新版本出现问题，“金丝雀”们会报警，但不会影响其他用户业务的正常运行。 ? 灰度发布（金丝雀发布）的流程如下： 准备和生产环境隔离的“金丝雀”服务器。 将新版本的服务部署到“金丝雀”服务器上。 对“金丝雀”服务器上的服务进行自动化和人工测试。 测试通过后，将“金丝雀”服务器连接到生产环境，将少量生产流量导入到“金丝雀”服务器中。
7.6K52发布于 2020-04-14 - 来自专栏院长运维开发
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 金丝雀部署
在整个持续交付体系中，金丝雀发布，或许是最为经典的一个场景，基于此，我们能够很快发现不健康和“有问题”的服务，并且可以毫不费力地回滚到上一个的版本。 金丝雀部署 什么是金丝雀部署？ 针对金丝雀部署工作流，其往往主要涉及以下阶段： Step 1：将流量从待部署节点移出，更新该节点服务至待发布状态，此时，节点称为“金丝雀节点”。 Step 2：依据不同的场景策略，将流量引入至金丝雀节点。 Step 3：金丝雀节点验证通过后，选取更多的节点作为金丝雀节点，然后重复步骤一和步骤二，直到所有节点全部更新至最新状态。 如果 404s 率达到 5% 阈值，则金丝雀失败。
75760发布于 2021-11-24 - 来自专栏运维开发故事
使用argo-rollouts实现金丝雀发布
支持特性如下： 蓝绿色更新策略 金丝雀更新策略 细粒度，加权流量转移 自动回rollback和promotion 手动判断 可定制的指标查询和业务KPI分析 入口控制器集成：NGINX，ALB 服务网格集成 /kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts 金丝雀发布 金丝雀发布包含Replica Shifting Traffic Shifting 上面我们并没有接入外部流量，仅仅是在内部使用展示了金丝雀部署过程，下面我们接入外部流量进行测试。 通过测试来看，Argo-Rollout提供更加强大的Deployment，包含比较适合运维的金丝雀发布和蓝绿发布功能，要使用蓝绿发布，仅需要配置rollout，如下： apiVersion: argoproj.io
3K80发布于 2020-12-16 - 来自专栏云原生运维社区
Ingress企业实战：金丝雀与蓝绿发布篇
什么是金丝雀发布 金丝雀发布，又称灰度发布，是指通过让小部份用户流量引入的新版本进行测试，如果一切顺利，则可以增加（可能逐渐增加）百分比，逐步替换旧版本。 最简单的方式是随机选择百分比请求到金丝雀版本，但在更复杂的方案下，则可以基于请求的内容、特定范围的用户或其他属性等。 总结 本文介绍了金丝雀发布与蓝绿发布，并以企业案例的方式讲解了不同的场景使用什么样的发布方式，下一章将介绍Ingress 证书管理与双向认证，请敬请期待！
94920编辑于 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.3K20编辑于 2023-10-09 - 来自专栏云原生工具箱
基于 Flagger 和 Nginx-Ingress 实现金丝雀发布
前言 很久之前我写过一篇介绍使用 Nginx-Ingress 实现蓝绿部署和金丝雀发布的文章，但那篇文章只是介绍了 nginx-ingress 具备这些能力，真正应用还要很多额外的配置和操作，况且现在能实现这些功能的并不只有 Flagger 使用 Service Mesh（App Mesh，Istio，Linkerd）或 Ingress Controller（Contour，Gloo，NGINX）来实现多种部署策略（金丝雀发布 本文主要介绍 Flagger 使用 Nginx-Ingress 进行金丝雀发布并监控发布状态，更多内容见官方文档[2]。 ? 自动金丝雀发布 通过更新镜像版本触发金丝雀部署： $ kubectl -n test set image deployment/podinfo podinfod=stefanprodan/podinfo 金丝雀发布 发布成功后，会收到 Slack 通知： ? Slack 通知 自动回滚 当然，有自动发布就会有自动回滚，下面就通过手动触发状态码 500 异常，演示暂停发布并回滚。
1.4K30发布于 2020-12-30
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号