- ubuntu12.04环境下使用kvm ioctl接口实现最简单的虚拟机
- Ubuntu 通过无线网络安装Ubuntu Server启动系统后连接无线网络的方法
- 在Ubuntu上搭建网桥的方法
- ubuntu 虚拟机上网方式及相关配置详解
CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.
这篇CFSDN的博客文章Linkerd 金丝雀部署与 A/B 测试由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.
本指南向您展示如何使用 Linkerd 和 Flagger 来自动化金丝雀部署与 A/B 测试.
Flagger Linkerd Traffic Split(流量拆分) 。
前提条件 。
Flagger 需要 Kubernetes 集群 v1.16 或更新版本和 Linkerd 2.10 或更新版本.
安装 Linkerd the Prometheus(Linkerd Viz 的一部分):
在 linkerd 命名空间中安装 Flagger:
引导程序 。
Flagger 采用 Kubernetes deployment 和可选的水平 Pod 自动伸缩 (HPA),然后创建一系列对象(Kubernetes 部署、ClusterIP 服务和 SMI 流量拆分)。这些对象将应用程序暴露在网格内部并驱动 Canary 分析和推广.
创建一个 test 命名空间并启用 Linkerd 代理注入:
安装负载测试服务以在金丝雀分析期间生成流量:
创建部署和水平 pod autoscaler:
为 podinfo 部署创建一个 Canary 自定义资源:
将上述资源另存为 podinfo-canary.yaml 然后应用:
当 Canary 分析开始时,Flagger 将在将流量路由到 Canary 之前调用 pre-rollout webhooks。金丝雀分析将运行五分钟,同时每半分钟验证一次 HTTP 指标和 rollout(推出) hooks.
几秒钟后,Flager 将创建 canary 对象:
在 boostrap 之后,podinfo 部署将被缩放到零, 并且到 podinfo.test 的流量将被路由到主 pod。在 Canary 分析过程中,可以使用 podinfo-canary.test 地址直接定位 Canary Pod.
自动金丝雀推进 。
Flagger 实施了一个控制循环,在测量 HTTP 请求成功率、请求平均持续时间和 Pod 健康状况等关键性能指标的同时,逐渐将流量转移到金丝雀。根据对 KPI 的分析,提升或中止 Canary,并将分析结果发布到 Slack.
Flagger 金丝雀阶段 。
通过更新容器镜像触发金丝雀部署:
Flagger 检测到部署修订已更改并开始新的部署:
请注意,如果您在 Canary 分析期间对部署应用新更改,Flagger 将重新开始分析.
金丝雀部署由以下任何对象的更改触发:
您可以通过以下方式监控所有金丝雀:
自动回滚 。
在金丝雀分析期间,您可以生成 HTTP 500 错误和高延迟来测试 Flagger 是否暂停并回滚有故障的版本.
触发另一个金丝雀部署:
使用以下命令执行负载测试器 pod:
生成 HTTP 500 错误:
生成延迟:
当失败的检查次数达到金丝雀分析阈值时,流量将路由回主服务器,金丝雀缩放为零,并将推出标记为失败.
自定义指标 。
Canary analysis 可以通过 Prometheus 查询进行扩展.
让我们定义一个未找到错误的检查。编辑 canary analysis 并添加以下指标:
上述配置通过检查 HTTP 404 req/sec 百分比是否低于总流量的 3% 来验证金丝雀版本。如果 404s 率达到 3% 阈值,则分析将中止,金丝雀被标记为失败.
通过更新容器镜像触发金丝雀部署:
生成 404:
监视 Flagger 日志:
如果您配置了 Slack,Flager 将发送一条通知,说明金丝雀失败的原因.
Linkerd Ingress 。
有两个入口控制器与 Flagger 和 Linkerd 兼容:NGINX 和 Gloo.
安装 NGINX:
为 podinfo 创建一个 ingress 定义,将传入标头重写为内部服务名称(Linkerd 需要):
使用 ingress controller 时,Linkerd 流量拆分不适用于传入流量,因为 NGINX 在网格之外运行。为了对前端应用程序运行金丝雀分析,Flagger 创建了一个 shadow ingress 并设置了 NGINX 特定的注释(annotations).
A/B 测试 。
除了加权路由,Flagger 还可以配置为根据 HTTP 匹配条件将流量路由到金丝雀。在 A/B 测试场景中,您将使用 HTTP headers 或 cookies 来定位您的特定用户群。这对于需要会话关联的前端应用程序特别有用.
Flagger Linkerd Ingress 。
编辑 podinfo 金丝雀分析,将提供者设置为 nginx,添加 ingress 引用,移除 max/step 权重并添加匹配条件和 iterations:
上述配置将运行 10 分钟的分析,目标用户是:canary cookie 设置为 always 或使用 X-Canary: always header 调用服务.
请注意,负载测试现在针对外部地址并使用 canary cookie.
通过更新容器镜像触发金丝雀部署:
Flagger 检测到部署修订已更改并开始 A/B 测试:
原文链接:https://mp.weixin.qq.com/s/8ThwH9DvFAnc-trOSf_nNQ 。
最后此篇关于Linkerd 金丝雀部署与 A/B 测试的文章就讲到这里了,如果你想了解更多关于Linkerd 金丝雀部署与 A/B 测试的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我是一名优秀的程序员,十分优秀!