- 综合排序
- 最热优先
- 最新优先
- 来自专栏ThoughtWorks
漫谈金丝雀部署
一段时间后，人们发现金丝雀这种生物对于有毒气体更加敏感。在 1900 年开始有记录显示，一些矿井开始把金丝雀作为井下有毒气体的预警物种。 后来，人们为了能重复使用金丝雀，发明了一个用于金丝雀毒气探测的专用笼子。笼子可以主动充氧，前方设有一个通气孔，通气孔可以通过密闭窗进行开启和关闭。在需要金丝雀进行预警的时候,把通气孔打开。 如果笼子中的金丝雀被毒气毒晕，关上通气孔的窗口并让笼子充满氧气。如果金丝雀如果没有被毒死，就有可能活过来。 金丝雀部署，这种部署方式的目标与逻辑和使用金丝雀来预警非常类似(通过开关通气孔/流量的方式来控制危害与恢复能力)，我猜想可能大家也希望能纪念一下在 20 世纪为矿工献出生命的金色小鸟们，所以这种方式被冠上了金丝雀的名称 金丝雀发布 or 金丝雀部署? 在交流和口语中，大家习惯于将发布和部署混用。
59330编辑于 2022-02-16 - 来自专栏痴者工良
Isito 入门（八）：金丝雀发布
金丝雀发布 尴尬，在学习 Istio 之前，我对蓝绿发布、灰度发布、金丝雀发布的概念并不清晰，很多文章都是将它们分成三类发布方式。实际上蓝绿发布和金丝雀发布都是灰度发布的一种。 所以，可以把蓝绿发布、A/B 测试、金丝雀发布都划分为灰度发布。 当然，它们有一些差别，每个人的划分方法也有差别，有的说法是金丝雀发布才是灰度发布。 打入到包含 10个 Pod 的 v1 版本。 因为 v2 版本只有10% 的流量，所以只需要 1 个 Pod 也可以支撑了叭。 kubectl scale deployment reviews-v2 -n bookinfo --replicas=10 与此同时，修改 VirtualService，将全部流量路由到 v2 中。
1.1K50编辑于 2023-11-03 - 来自专栏JavaEdge
KubeSphere实现金丝雀发布（Canary Release）
0 前言 KubeSphere 基于 [Istio] 向用户提供金丝雀发布功能，即： 引入服务的新版本，并向其发送一小部分流量来进行测试 同时，旧版本负责处理其余的流量 如果一切顺利，就可逐渐增加向新版本发送的流量 参见创建企业空间、项目、用户和角色 开启应用治理并有一个可用应用，以便实现该应用的金丝雀发布。本教程使用示例应用 Bookinfo。参见部署 Bookinfo 和管理流量。 1 创建金丝雀发布任务 登录 KubeSphere 控制台： 转到灰度发布页面，点击创建灰度发布任务： 在发布模式选项卡，点击金丝雀发布右侧的创建： 设置任务名称，点击下一步： 在服务设置选项卡，从下拉列表中选择你的应用和要实现金丝雀发布的服务 操作完成后，点击创建： 结果： 点击进去查看，v2的资源已被创建： 到工作负载下观察： 2 验证金丝雀发布 现在有两个可用的应用版本了，访问该应用以验证金丝雀发布。 5 接管所有流量 若一切运行顺利，则可以将所有流量引入新版本： 在任务状态中，点击金丝雀发布任务 在弹出的对话框中，点击 reviews v2 右侧的 ，选择接管。
54121编辑于 2024-01-12 - 来自专栏k8s技术圈
Argo Rollouts 实现蓝绿金丝雀发布
Canary 上面显示了一个有两个阶段的金丝雀（10%和33%的流量进入新版本），通过使用 Argo Rollouts，我们可以根据实际的使用情况定义确切的阶段数和流量百分比。 ~ kubectl argo rollouts version kubectl-argo-rollouts: v1.0.2+7a23fe5 BuildDate: 2021-06-15T19:36:10Z 发布的节奏 - setWeight: 20 - pause: {} # 会一直暂停 - setWeight: 40 - pause: {duration: 10 } - setWeight: 60 - pause: {duration: 10} - setWeight: 80 - pause: {duration: 10} revisionHistoryLimit: 2 # 下面部分其实是和 Deployment 兼容的 selector: matchLabels: app: rollouts-demo
3.3K30发布于 2021-07-23 - 来自专栏黑客下午茶
Linkerd 金丝雀部署与 AB 测试
自动金丝雀推进 Flagger 实施了一个控制循环，在测量 HTTP 请求成功率、请求平均持续时间和 Pod 健康状况等关键性能指标的同时，逐渐将流量转移到金丝雀。 ，流量将路由回主服务器，金丝雀缩放为零，并将推出标记为失败。 canary iteration 4/10 Advance podinfo.test canary iteration 5/10 Advance podinfo.test canary iteration 6/10 Advance podinfo.test canary iteration 7/10 Advance podinfo.test canary iteration 8/10 Advance podinfo.test canary iteration 9/10 Advance podinfo.test canary iteration 10/10 Copying podinfo.test
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 - 来自专栏架构驿站
基于 Flagger Operator 的 Traefik 金丝雀部署
在整个持续交付体系中，金丝雀发布，或许是最为经典的一个场景，基于此，我们能够很快发现不健康和“有问题”的服务，并且可以毫不费力地回滚到上一个的版本。 金丝雀部署 什么是金丝雀部署？ number or name targetPort: 9898 analysis: # schedule interval (default 60s) interval: 10s # max number of failed metric checks before rollback threshold: 10 # max traffic percentage -q 10 -c 2 -host app.example.com http://traefik.traefik" logCmdOutput: "true" [administrator deployment for podinfo.test Advance podinfo.test canary weight 5 Advance podinfo.test canary weight 10
1.6K50编辑于 2021-12-10 - 来自专栏DevOps时代的专栏
使用 Istio 实现灰度发布（金丝雀发布）
可以通过灰度发布（又名金丝雀发布）来实现业务从老版本到新版本的平滑过渡，并避免升级过程中出现的问题对用户造成的影响。 “金丝雀发布”的来源于矿工们用金丝雀对矿井进行空气测试的做法。 以前矿工挖煤的时候，矿工下矿井前会先把金丝雀放进去，或者挖煤的时候一直带着金丝雀。金丝雀对甲烷和一氧化碳浓度比较敏感，会先报警。所以大家都用“金丝雀”来搞最先的测试。 灰度发布（金丝雀发布）的流程如下： 准备和生产环境隔离的“金丝雀”服务器。 将新版本的服务部署到“金丝雀”服务器上。 对“金丝雀”服务器上的服务进行自动化和人工测试。 测试通过后，将“金丝雀”服务器连接到生产环境，将少量生产流量导入到“金丝雀”服务器中。 备注：本例只是描述原理，因此为简单起见，将50%流量导入V2版本，在实际操作中，更可能是先导入较少流量，然后根据监控的新版本运行情况将流量逐渐导入，如采用5%，10%，20%，50% …的比例逐渐导入。
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）。 后面可以渐渐的把所有流量都切到金丝雀版本（v2），只需要修改weight: 10参数，注意v1和v2版本和一定要等于100 apiVersion: networking.istio.io/v1alpha3 的请求发送到金丝雀版本，无论每个版本的运行副本数量是多少。 这允许简单而强大的方式来进行金丝雀测试和上线。 支持金丝雀部署的智能路由只是 Istio 的众多功能之一，它将使基于大型微服务的应用程序的生产部署变得更加简单。查看 istio.io 了解更多信息。
2.3K11发布于 2020-06-04 - 来自专栏架构驿站
基于 Flagger Operator 的 Traefik 金丝雀部署
在整个持续交付体系中，金丝雀发布，或许是最为经典的一个场景，基于此，我们能够很快发现不健康和“有问题”的服务，并且可以毫不费力地回滚到上一个的版本。 金丝雀部署 什么是金丝雀部署？ number or name targetPort: 9898 analysis: # schedule interval (default 60s) interval: 10s # max number of failed metric checks before rollback threshold: 10 # max traffic percentage -q 10 -c 2 -host app.example.com http://traefik.traefik" logCmdOutput: "true" Flagger deployment for podinfo.test Advance podinfo.test canary weight 5 Advance podinfo.test canary weight 10
76360发布于 2021-11-24 - 来自专栏运维开发故事
使用argo-rollouts实现金丝雀发布
支持特性如下： 蓝绿色更新策略 金丝雀更新策略 细粒度，加权流量转移 自动回rollback和promotion 手动判断 可定制的指标查询和业务KPI分析 入口控制器集成：NGINX，ALB 服务网格集成 /kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts 金丝雀发布 金丝雀发布包含Replica Shifting } - setWeight: 60 - pause: {duration: 10} - setWeight: 80 - pause: {duration: strategy字段定义的是发布策略，其中： setWeight：设置流量的权重 pause：暂停，如果里面没有跟duration: 10则表示需要手动更新，如果跟了表示等待多长时间会自动更新。 Traffic Shifting 上面我们并没有接入外部流量，仅仅是在内部使用展示了金丝雀部署过程，下面我们接入外部流量进行测试。
3K80发布于 2020-12-16 - 来自专栏云原生运维社区
Ingress企业实战：金丝雀与蓝绿发布篇
什么是金丝雀发布 金丝雀发布，又称灰度发布，是指通过让小部份用户流量引入的新版本进行测试，如果一切顺利，则可以增加（可能逐渐增加）百分比，逐步替换旧版本。 最简单的方式是随机选择百分比请求到金丝雀版本，但在更复杂的方案下，则可以基于请求的内容、特定范围的用户或其他属性等。 总结 本文介绍了金丝雀发布与蓝绿发布，并以企业案例的方式讲解了不同的场景使用什么样的发布方式，下一章将介绍Ingress 证书管理与双向认证，请敬请期待！
97320编辑于 2023-09-11 - 来自专栏物流IT圈
蓝绿部署、金丝雀发布（灰度发布）和AB测试
3.金丝雀发布/灰度发布 金丝雀发布（Canary）/ 灰度发布也是一种发布策略，和国内常说的灰度发布是同一类策略。 先将线上的一万台服务器中的10台更新为最新的系统，然后观察验证。确认没有异常之后，再将剩余的所有服务器更新。 这个方法就是金丝雀发布。 实际操作中还可以做更多控制，譬如说，给最初更新的10台服务器设置较低的权重、控制发送给这10台服务器的请求数，然后逐渐提高权重、增加请求数。 上面的例子中可以用金丝雀，不能用蓝绿，那么什么时候可以用蓝绿，不能用金丝雀呢？整个系统只有一台服务器的时候。 在A/B测试中，需要能够控制流量的分配，譬如说，为A版本分配10%的流量，为B版本分配10%的流量，为C版本分配80%的流量。
1.3K31发布于 2019-07-16 - 来自专栏云原生运维社区
如何使用Higress快速实现金丝雀与蓝绿发布
什么是金丝雀发布 金丝雀发布，又称灰度发布，是指通过让小部份用户流量引入的新版本进行测试，如果一切顺利，则可以增加（可能逐渐增加）百分比，逐步替换旧版本。 最简单的方式是随机选择百分比请求到金丝雀版本，但在更复杂的方案下，则可以基于请求的内容、特定范围的用户或其他属性等。 console.higress.io --set higress-console.admin.password.value=admin NAME: higress LAST DEPLOYED: Thu Aug 10 demo-new-svc.default.svc.cluster.local:8080 higress.io/ignore-path-case: "false" creationTimestamp: "2023-10 总结 本文介绍了金丝雀与蓝绿发布及不同的应用场景，并基于Higress结合企业实战案例进行演示，让大家更容易理解上手，接下来的文章会讲解Higress更多企业级应用实战，请敬请期待！
1.4K20编辑于 2023-10-09 - 来自专栏云原生工具箱
基于 Flagger 和 Nginx-Ingress 实现金丝雀发布
本文主要介绍 Flagger 使用 Nginx-Ingress 进行金丝雀发布并监控发布状态，更多内容见官方文档[2]。 ? # 回滚前的最大失败指标检查次数 threshold: 10 # 路由到金丝雀副本的最大流量百分比 # 百分比 (0-100) maxWeight: 50 自动金丝雀发布 通过更新镜像版本触发金丝雀部署： $ kubectl -n test set image deployment/podinfo podinfod=stefanprodan/podinfo (x3 over 10m) flagger all the metrics providers are available! Normal Synced 10m flagger Initialization done!
1.4K30发布于 2020-12-30
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号