- 综合排序
- 最热优先
- 最新优先
- 来自专栏ThoughtWorks
漫谈金丝雀部署
一段时间后，人们发现金丝雀这种生物对于有毒气体更加敏感。在 1900 年开始有记录显示，一些矿井开始把金丝雀作为井下有毒气体的预警物种。 后来，人们为了能重复使用金丝雀，发明了一个用于金丝雀毒气探测的专用笼子。笼子可以主动充氧，前方设有一个通气孔，通气孔可以通过密闭窗进行开启和关闭。在需要金丝雀进行预警的时候,把通气孔打开。 如果笼子中的金丝雀被毒气毒晕，关上通气孔的窗口并让笼子充满氧气。如果金丝雀如果没有被毒死，就有可能活过来。 金丝雀部署，这种部署方式的目标与逻辑和使用金丝雀来预警非常类似(通过开关通气孔/流量的方式来控制危害与恢复能力)，我猜想可能大家也希望能纪念一下在 20 世纪为矿工献出生命的金色小鸟们，所以这种方式被冠上了金丝雀的名称 金丝雀发布 or 金丝雀部署? 在交流和口语中，大家习惯于将发布和部署混用。
59330编辑于 2022-02-16 - 来自专栏痴者工良
Isito 入门（八）：金丝雀发布
Kubernetes 滚动升级、伸缩参考资料：https://k8s.whuanle.cn/3.pod/6.scale.html Istio 中虽然没有名为 金丝雀发布的功能，但是按照之前我们所学到的 金丝雀发布 尴尬，在学习 Istio 之前，我对蓝绿发布、灰度发布、金丝雀发布的概念并不清晰，很多文章都是将它们分成三类发布方式。实际上蓝绿发布和金丝雀发布都是灰度发布的一种。 所以，可以把蓝绿发布、A/B 测试、金丝雀发布都划分为灰度发布。 当然，它们有一些差别，每个人的划分方法也有差别，有的说法是金丝雀发布才是灰度发布。 apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: reviews spec: host labels: version: v3 现在使用命令将 v1 版本增加到 10 个 pod。
1.1K50编辑于 2023-11-03 - 来自专栏JavaEdge
KubeSphere实现金丝雀发布（Canary Release）
参见创建企业空间、项目、用户和角色 开启应用治理并有一个可用应用，以便实现该应用的金丝雀发布。本教程使用示例应用 Bookinfo。参见部署 Bookinfo 和管理流量。 1 创建金丝雀发布任务 登录 KubeSphere 控制台： 转到灰度发布页面，点击创建灰度发布任务： 在发布模式选项卡，点击金丝雀发布右侧的创建： 设置任务名称，点击下一步： 在服务设置选项卡，从下拉列表中选择你的应用和要实现金丝雀发布的服务 操作完成后，点击创建： 结果： 点击进去查看，v2的资源已被创建： 到工作负载下观察： 2 验证金丝雀发布 现在有两个可用的应用版本了，访问该应用以验证金丝雀发布。 host: reviews port: number: 9080 subset: v2 weight: 50 ... 3 5 接管所有流量 若一切运行顺利，则可以将所有流量引入新版本： 在任务状态中，点击金丝雀发布任务 在弹出的对话框中，点击 reviews v2 右侧的 ，选择接管。
54021编辑于 2024-01-12 - 来自专栏k8s技术圈
Argo Rollouts 实现蓝绿金丝雀发布
Argo Rollouts 是一个 Kubernetes Operator 实现，它为 Kubernetes 提供更加高级的部署能力，如蓝绿、金丝雀、金丝雀分析、实验和渐进式交付功能，为云原生应用和服务实现自动化 蓝绿部署 金丝雀部署 与 Ingress 控制器和服务网格整合，实现高级流量路由 与用于蓝绿和金丝雀分析的指标提供者集成 根据成功或失败的指标，自动发布或回滚 渐进式交付 渐进式交付是以受控和渐进的方式发布产品更新的过程 Blue-Green Canary(金丝雀)：金丝雀发布指将一部分用户暴露在新版本的应用程序中，而将其余流量提供给旧版本，一旦新版本被验证是正确的，新版本可以逐渐取代旧版本。 使用金丝雀策略，用户指定他们希望新版本接收的百分比以及在百分比之间等待的时间。 3. Promote Rollout 经过上面的更新后，Rollout 现在处于暂停状态，当一个 Rollout 到达一个没有持续时间的暂停步骤时，它将一直保持在暂停状态，直到它被恢复/提升。
3.3K30发布于 2021-07-23 - 来自专栏黑客下午茶
Linkerd 金丝雀部署与 AB 测试
自动金丝雀推进 Flagger 实施了一个控制循环，在测量 HTTP 请求成功率、请求平均持续时间和 Pod 健康状况等关键性能指标的同时，逐渐将流量转移到金丝雀。 来验证金丝雀版本。 如果 404s 率达到 3% 阈值，则分析将中止，金丝雀被标记为失败。 7.22 > 3 Halt podinfo.test advancement 404s percentage 6.50 > 3 Halt podinfo.test advancement 404s percentage 6.34 > 3 Rolling back podinfo.test failed checks threshold reached 5 Canary failed!
93140发布于 2021-07-30 - 来自专栏SY小站的专栏
ingress-nginx高级金丝雀发布
check_health.jsp scm [root@ingress]# curl -H "name: bb" http://test.sy.com/abc/check_health.jsp opdev 3.
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 Running 0 33m pod/istiod-canary-865f754fdd-gx7dh 1/1 Running 0 3m25s 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 实现灰度发布（金丝雀发布）
以前矿工挖煤的时候，矿工下矿井前会先把金丝雀放进去，或者挖煤的时候一直带着金丝雀。金丝雀对甲烷和一氧化碳浓度比较敏感，会先报警。所以大家都用“金丝雀”来搞最先的测试。 灰度发布（金丝雀发布）的流程如下： 准备和生产环境隔离的“金丝雀”服务器。 将新版本的服务部署到“金丝雀”服务器上。 对“金丝雀”服务器上的服务进行自动化和人工测试。 测试通过后，将“金丝雀”服务器连接到生产环境，将少量生产流量导入到“金丝雀”服务器中。 因为本试验并不需要安装全部3个版本的reviews服务，因此如果已经安装了该应用，先采用下面的命令卸载。 由于示例中的yaml文件中包含了3个版本的reviews服务，我们先将V2和V3版本的Deployment从yaml文件istio-0.2.10/samples/bookinfo/kube/bookinfo.yaml
7.6K52发布于 2020-04-14 - 来自专栏架构驿站
基于 Flagger Operator 的 Traefik 金丝雀部署
在整个持续交付体系中，金丝雀发布，或许是最为经典的一个场景，基于此，我们能够很快发现不健康和“有问题”的服务，并且可以毫不费力地回滚到上一个的版本。 金丝雀部署 什么是金丝雀部署？ 针对金丝雀部署工作流，其往往主要涉及以下阶段： Step 1：将流量从待部署节点移出，更新该节点服务至待发布状态，此时，节点称为“金丝雀节点”。 Step 3：金丝雀节点验证通过后，选取更多的节点作为金丝雀节点，然后重复步骤一和步骤二，直到所有节点全部更新至最新状态。 接下来，我们用 Helm （此处为 v3 版本）部署 Traefik ，具体如下所示： [administrator@JavaLangOutOfMemory ~ ] % helm repo add traefik podinfo.test advancement success rate 48.05% < 99% Rolling back podinfo.test failed checks threshold reached 3
1.6K50编辑于 2021-12-10 - 来自专栏院长运维开发
ingress-nginx高级金丝雀发布
spm=a2c4g.11186623.6.793.7de864e3cABNYa
1.4K20发布于 2020-06-11 - 来自专栏YP小站
K8S 金丝雀部署之 Istio
什么是金丝雀发布? 金丝雀发布（Canary）：也是一种发布策略，和国内常说的灰度发布是同一类策略。蓝绿部署是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统。 如将 10％ 的流量发送到金丝雀版本（v2）。 后面可以渐渐的把所有流量都切到金丝雀版本（v2），只需要修改weight: 10参数，注意v1和v2版本和一定要等于100 apiVersion: networking.istio.io/v1alpha3 .svc.cluster.local subset: v2 weight: 10 --- apiVersion: networking.istio.io/v1alpha3 高层次的金丝雀部署 只允许特定网站上50％的用户流量路由到金丝雀（v2）版本，而其他用户则不受影响 apiVersion: networking.istio.io/v1alpha3 kind: VirtualService
2.3K11发布于 2020-06-04 - 来自专栏架构驿站
基于 Flagger Operator 的 Traefik 金丝雀部署
在整个持续交付体系中，金丝雀发布，或许是最为经典的一个场景，基于此，我们能够很快发现不健康和“有问题”的服务，并且可以毫不费力地回滚到上一个的版本。 金丝雀部署 什么是金丝雀部署？ 针对金丝雀部署工作流，其往往主要涉及以下阶段： Step 1：将流量从待部署节点移出，更新该节点服务至待发布状态，此时，节点称为“金丝雀节点”。 Step 3：金丝雀节点验证通过后，选取更多的节点作为金丝雀节点，然后重复步骤一和步骤二，直到所有节点全部更新至最新状态。 接下来，我们用 Helm （此处为 v3 版本）部署 Traefik ，具体如下所示： [administrator@JavaLangOutOfMemory ~ ] % helm repo add traefik podinfo.test advancement success rate 48.05% < 99% Rolling back podinfo.test failed checks threshold reached 3
76360发布于 2021-11-24 - 来自专栏运维开发故事
使用argo-rollouts实现金丝雀发布
支持特性如下： 蓝绿色更新策略 金丝雀更新策略 细粒度，加权流量转移 自动回rollback和promotion 手动判断 可定制的指标查询和业务KPI分析 入口控制器集成：NGINX，ALB 服务网格集成 /kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts 金丝雀发布 金丝雀发布包含Replica Shifting Paused Message: CanaryPauseStep Strategy: Canary Step: 3/8 SetWeight: 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快速实现金丝雀与蓝绿发布
什么是金丝雀发布 金丝雀发布，又称灰度发布，是指通过让小部份用户流量引入的新版本进行测试，如果一切顺利，则可以增加（可能逐渐增加）百分比，逐步替换旧版本。 最简单的方式是随机选择百分比请求到金丝雀版本，但在更复杂的方案下，则可以基于请求的内容、特定范围的用户或其他属性等。 : ${ADMIN_PASSWORD}" NOTE: If this is an upgrade release, your current password won't be changed. 3. demo-new-canary namespace: higress-system resourceVersion: "221188" uid: bf833256-6993-4e56-bc3e-f96fe606e278 总结 本文介绍了金丝雀与蓝绿发布及不同的应用场景，并基于Higress结合企业实战案例进行演示，让大家更容易理解上手，接下来的文章会讲解Higress更多企业级应用实战，请敬请期待！
1.4K20编辑于 2023-10-09 - 来自专栏云原生工具箱
基于 Flagger 和 Nginx-Ingress 实现金丝雀发布
prometheus\.io/port"=10254 安装部署 Flagger 安装 Flagger 提供了 Hlem 和 Kustomize 两种安装方式，这里使用 Helm 3 安装： $ helm 这里设置的是全局通知，集群中的 Flagger 被触发后都会进行通知，当然也可以为单个 Flagger 配置专门的通知，这里就不做过多介绍，详情见官方文档[3]。 自动金丝雀发布 通过更新镜像版本触发金丝雀部署： $ kubectl -n test set image deployment/podinfo podinfod=stefanprodan/podinfo ready: waiting for rollout to finish: 0 of 2 updated replicas are available Normal Synced 10m (x3 引用链接 [1] Flagger: https://github.com/weaveworks/flagger [2] 官方文档: https://docs.flagger.app/ [3] 官方文档:
1.4K30发布于 2020-12-30
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号