文档教程DevOps运维【免费下载链接】devops-exercisesLinux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization. DevOps Interview Questions项目地址https://gitcode.com/GitHub_Trending/de/devops-exercises点击查看免费下载导读本文基于 devops-exercises 仓库中的 Canary Rollout 练习与解答完整演示如何在 Kubernetes 集群中安装 Argo Rollouts 控制器编写一份采用 canary金丝雀策略的 Rollout 清单并通过逐步放量30% → 60% → 100%与手动暂停确认的方式发布新版本。读完本文你将掌握 canary 发布的核心概念、Rollout 资源的关键字段语义、以及配套的kubectl argo rollouts命令族能够独立完成低风险灰度发布 人工把关的实战场景。背景为什么需要 Argo RolloutsKubernetes 原生Deployment提供的滚动更新在发布新版本时缺乏细粒度的流量控制能力。Argo Rollouts 是运行在 Kubernetes 之上、专门用于高级发布策略的控制器。按本仓库 Argo Rollouts 101 问答 的定义Argo Rollouts 是 Kubernetes 的一个控制器用于使用 Blue/Green、Canary 等不同策略执行应用部署此外还支持 A/B 测试、自动回滚与集成的指标分析。它引入了一个新的自定义资源Rolloutargoproj.io/v1alpha1用来替代或补充Deployment的发布流程。需要注意的是Argo Rollouts 与 ArgoCD 是相互独立的组件——仓库中明确指出这是一个常见的误解使用 Argo Rollouts 并不需要先安装 ArgoCD两者可以独立使用也可以协同工作详见 README 问答。本练习exercise.md的目标是安装 Argo Rollouts 控制器编写一份使用 canary 策略的 Rollout 清单并应用副本数设为 6并禁用自动提升auto-promotion查看 rollout 列表发布一个新版本并检查发布状态。前置条件Requirements根据原文档动手前需要准备一个正在运行的 Kubernetes 集群可以是 kind、minikube、云厂商托管集群等Argo Rollouts CLI 插件提供kubectl argo rollouts子命令用于查看与操控 rollout一个已经部署在集群中的、特定版本的应用本文示例为some/registry/and/image:v1.0。第一步安装 Argo Rollouts 控制器安装过程分为两步先创建独立命名空间再从官方发布的安装清单部署控制器。kubectl create namespace argo-rollouts kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yamlkubectl create namespace argo-rollouts为控制器创建专用命名空间便于资源隔离与清理kubectl apply -n argo-rollouts -f .../install.yaml从 Argo Rollouts 官方 GitHub Releases 拉取最新的安装清单包含 Controller Deployment、RBAC、CRD 定义等并应用到argo-rollouts命名空间。安装完成后控制器会监听集群中Rollout类型的自定义资源并负责驱动 canary/blue-green 发布流程的执行。第二步编写 Canary Rollout 清单以下是原文档提供的完整 Rollout 资源清单。它定义了一个名为some-app的应用初始镜像为some/registry/and/image:v1.0--- apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: some-app spec: replicas: 6 strategy: canary: stableService: k8s-service-stable canaryService: k8s-service-canary trafficRouting: ambassador: mappings: - k8s-mapping steps: - setWeight: 30 - pause: {} - setWeight: 60 - pause: {} - setWeight: 100 - pause: {} selector: matchLabels: app: some-web-app template: metadata: labels: app: some-web-app spec: containers: - name: web-app image: some/registry/and/image:v1.0 ports: - name: http containerPort: 8080 protocol: TCP逐字段解读API 版本与类型apiVersion: argoproj.io/v1alpha1、kind: Rollout这是 Argo Rollouts 注册的自定义资源类型区别于原生apps/v1的Deployment。副本数与发布策略spec.replicas: 6目标副本数为 6与练习目标一致。canary 发布过程中新旧版本 ReplicaSet 的 Pod 数量分配由控制器根据setWeight自动计算。spec.strategy.canary声明采用 canary 策略。canary 与 blue/green 是 Argo Rollouts 的两大内置策略仓库中另有一份 Blue/Green Rollout 解答 可对照学习blue/green 通过autoPromotionEnabled: false控制是否自动切换而 canary 则是通过流量权重阶梯逐步放量。Service 与流量路由stableService: k8s-service-stable稳定版本对应的 Service持续接收部分流量。canaryService: k8s-service-canary金丝雀新版本对应的 Service。trafficRouting.ambassador.mappings: [k8s-mapping]指定由 Ambassador/Emissary 作为流量路由网关通过名为k8s-mapping的 Mapping 资源按权重切分稳定/金丝雀流量。这是 canary 精准控流的关键没有 trafficRouting 时只能控制副本比例配置网关后才能真正按百分比切分线上流量。Steps发布阶梯steps: - setWeight: 30 - pause: {} - setWeight: 60 - pause: {} - setWeight: 100 - pause: {}这 6 步定义了一次完整 canary 发布的节奏setWeight: 30—— 将 30% 流量切到新版本pause: {}—— 暂停等待人工确认setWeight: 60—— 放量到 60%pause: {}—— 再次暂停setWeight: 100—— 全量切换pause: {}—— 最终暂停等待完成。pause: {}正是原文档目标中禁用自动提升Disable auto-promotions的实现方式每一步放量后发布流程都会停在暂停点只有人工执行提升命令后才会进入下一步。这与 blue/green 解答中autoPromotionEnabled: false的意图一致——把关键决策权交给工程师。Selector 与 Pod 模板selector.matchLabels: {app: some-web-app}与template.metadata.labels: {app: some-web-app}Pod 标签必须与选择器匹配Argo Rollouts 据此关联新旧 ReplicaSet。template.spec.containers容器名为web-app镜像some/registry/and/image:v1.0暴露名为http、端口 8080 的 TCP 端口。后续更新镜像时命令中的容器名web-app必须与这里保持一致。第三步查看 Rollout 列表应用清单后使用以下命令确认 Rollout 已被控制器接管kubectl argo rollouts list rollouts该命令会列出集群中所有 Rollout 及其当前状态Healthy、Progressing 等。对应地README 的命令问答 也给出了列出 rollouts 的标准用法。若要查看单个应用的状态可用kubectl argo rollouts get rollout some-app第四步发布新版本并监控状态触发新版本发布kubectl argo rollouts set image SOME-APP web-appsome/registry/and/image:v2.0这条命令将some-app的web-app容器镜像从v1.0更新为v2.0等价于修改清单中的image字段后重新 apply是触发 canary 流程的标准方式。观察发布过程kubectl argo rollouts get rollout some-app --watch--watch会持续刷新输出实时显示当前所处的 step、新旧版本 Pod 数量与流量权重变化。按照本仓库 README 的说明当你对应用执行 rollout 时会发生两件事Argo Rollouts 创建一个新的 ReplicaSet承载新版本旧版本仍然存活——这正是 canary 能够随时回退的基础若与 ArgoCD 集成应用会被标记为 out-of-sync等待同步确认。推进与回退的关键操作由于清单中每个 step 后都有pause发布会停在暂停点你需要手动推进kubectl argo rollouts promote SOME-APPpromote用于跳过当前暂停进入下一个 step如从 30% 提升到 60%。这也印证了仓库 Argo Rollouts Commands 问答 中的结论手动提升新版本正是通过该命令完成的。若在某一暂停点发现新版本异常可以执行kubectl argo rollouts abort some-app或使用undo回退终止发布、让流量回到稳定版本。纵深扩展从手动确认到自动回滚本练习采用的是暂停 人工确认模式。仓库的问答章节进一步指出更成熟的方案是把人工把关升级为基于指标的自动化分析——Argo Rollouts 支持 Datadog、NewRelic、Prometheus 等多种指标提供方可在发布过程中持续采集指标并在条件不满足时自动回滚详见 README 问答。仓库给出的 AnalysisTemplate 示例 展示了这种自动化思路的核心结构apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: success-rate spec: args: - name: service-name metrics: - name: success-rate interval: 4m count: 3 successCondition: result[0] 0.90 provider: prometheus: address: http:/some-prometheus-instance:80 query: sum(response_status{app{{args.service-name}},rolecanary,status~2.*})/sum(response_status{app{{args.service-name}},rolecanary}该模板每 4 分钟从 Prometheus 查询一次金丝雀版本的成功率如果result[0] 0.9090% 以上请求成功发布继续否则判定金丝雀失败并触发回滚。在实际项目中可将这份 AnalysisTemplate 关联到 Rollout 的strategy.canary.analysis字段从而把何时放量、何时回滚交给数据而非人工判断。总结与进一步练习本文从零完成了安装控制器 → 编写 canary Rollout → 查看列表 → 升级镜像并监控 → 手动推进的完整闭环重点掌握canary 策略通过setWeightpause实现阶梯放量 人工把关pause即禁用自动提升stableService/canaryService/trafficRouting共同决定稳定版与金丝雀版之间的流量切分kubectl argo rollouts命令族list、get --watch、set image、promote是日常操控发布的核心工具。如果你希望对比另一种发布策略可以继续完成仓库中的 Blue/Green Rollout 练习 并对照其 解答想系统学习 Rollout 的进阶能力A/B 测试、自动回滚、指标分析可通读 Argo 主题目录 中的 Argo Rollouts 问答章节。赞分享文档教程DevOps运维【免费下载链接】devops-exercisesLinux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization. DevOps Interview Questions项目地址https://gitcode.com/GitHub_Trending/de/devops-exercises点击查看免费下载相关推荐在 Kubernetes 中使用 Argo Rollouts 实现 Canary 金丝雀发布从控制器安装到分步灰度上线实战指南在 Kubernetes 中使用 Argo Rollouts 实现 Canary 金丝雀发布从控制器安装到分步灰度上线实战指南 导读 本文基于 devops文档教程DevOps运维REFramework游戏修改框架兼容性深度分析与崩溃修复终极指南REFramework游戏修改框架兼容性深度分析与崩溃修复终极指南 REFramework作为一款功能强大的游戏修改框架、脚本平台和VR支持工具为所有RE E游戏开发VRProxmark3 Standalone 模式 HF_EMVPNGVisa EMV 卡读取与固定 ARQC 模拟的完整实现解析Proxmark3 Standalone 模式 HF_EMVPNGVisa EMV 卡读取与固定 ARQC 模拟的完整实现解析 本篇指南围绕 Proxmark文档教程DevOps运维上一篇Obsidian-Skills深度实践指南构建智能知识管理工作流的三层架构下一篇PyTorch-NPU/bert_large_uncased问答系统构建基于SQuAD数据集的实战演练创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考