以下是使用Argo CD Agent架构带来的关键优势高度可扩展采用中心辐射模型轻松应对成百上千的集群规模。轻量级部署在Spoke集群上仅部署必需的Argo CD组件而非完整套件。代理发起通信Spoke集群上的Agent主动连接Hub更符合安全边界要求拉取而非推送。工作负载集群自治Hub故障不影响Spoke集群上现有应用的持续协调。消除高速网络依赖适合边缘、船舶、车辆等间歇性连接环境。安全设计Hub无需存储Spoke集群的kubeconfig。通过集成的mTLS认证使用短期证书OCM默认每小时轮换安全性更高。演示概览https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/1efb83fffc64d6d91e576f65cdfb4e2d_5.png在演示中我们看到了如何使用OCM快速搭建Argo CD Agent环境https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/1efb83fffc64d6d91e576f65cdfb4e2d_7.png定义插件模板在Hub上创建一个AddOn模板定义了要部署到Spoke的Argo CD组件和Agent。部署插件实例通过OCM的ManagedClusterAddOn将模板实例化并部署到指定的Spoke集群。创建应用在Hub上创建Argo CDApplication资源目标指向特定的Spoke集群。同步与删除Agent将应用定义拉取到Spoke本地Argo CD开始同步。从Hub删除应用后更改也会同步到Spoke并清理资源。安全贡献mTLS 集成https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/1efb83fffc64d6d91e576f65cdfb4e2d_9.png团队为Argo CD Agent的安全做出了重要贡献。默认的Agent使用用户名/密码认证这仍然存在凭证管理的挑战。团队增强了其mTLS集成能力https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/1efb83fffc64d6d91e576f65cdfb4e2d_11.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/1efb83fffc64d6d91e576f65cdfb4e2d_12.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/1efb83fffc64d6d91e576f65cdfb4e2d_13.png工作原理Agent使用由OCM自动管理和轮换的客户端证书向Principle进行认证。优势无需密码消除了静态密码的存储和管理。自动轮换OCM默认每小时轮换证书即使证书泄露攻击窗口也极短。集群标识从证书的Subject Name中提取集群名称用于在Principle端标识请求来源。总结https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/1efb83fffc64d6d91e576f65cdfb4e2d_15.png本节课中我们一起学习了如何利用Argo CD Agent与Open Cluster Management的强大组合来应对大规模GitOps部署的挑战。我们从OCM的基础概念出发详细分析了三种集成模式并重点介绍了最具优势的Argo CD Agent模型。该模型通过中心辐射、拉取通信、工作负载自治和安全设计等特性为实现高度可扩展、弹性和安全的云原生GitOps架构提供了清晰的路径。您可以从Argo CD官方文档中关于OCM集成的部分开始实践。020使用 Argo Events 实现实时事件自动修复 ️https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/f8a659f7c0e2e0f03953875216411856_1.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/f8a659f7c0e2e0f03953875216411856_2.png在本节课中我们将学习如何利用 Argo Events 构建自动化的弹性系统实现实时事件的检测与修复。我们将从核心概念入手通过一个具体的演示案例展示如何将监控告警、决策判断和修复动作串联成一个完整的自动化流程。概述什么是自动修复自动修复是指系统自动检测并解决故障的过程。一个理想的自动修复系统能够发现问题并尝试解决它从而实现应用和基础设施的自愈。你可以将其与现有的开发工具或流水线集成以提供实时的故障缓解。例如一个应用在99%的时间里运行良好但偶尔会出现功能异常通常简单的重启就能解决问题。在这种情况下自动修复可以通过检查日志并重启服务来缓解问题之后你的团队再添加永久性修复。这可以节省成本、时间并减少人工操作。自动修复的工作原理自动修复通常包含三个核心阶段检测、决策和行动。上一节我们介绍了自动修复的基本概念本节中我们来看看它的具体工作流程。以下是自动修复的三个阶段检测这是一个持续监控系统的工具。它通常检查系统中的所有日志、指标和活动。当检测到异常时该组件会发出警报。例如使用 Prometheus 和 Alertmanager 设置规则当 CPU 使用率超过90%持续一段时间时触发告警或者使用 Grafana Loki在日志中发现可疑内容时发出通知。决策该组件接收来自检测组件的通知对其进行验证并根据信息采取行动。例如你收到一个通知称系统在某个端点上返回500错误。决策组件会验证此通知并根据严重程度或其他预定义规则决定是否触发修复动作。行动这是实际的修复动作。它接收来自决策引擎的命令并基于该命令启动适当的操作。这个操作可以是一个工作流、一个无服务器函数或者一个简单的命令来回滚系统中的更改。沿用上面的例子修复动作可能是重启受影响的服务器或者如果该服务最近有更新则回滚到上一个版本。Argo Events 简介了解了自动修复的流程后我们需要一个强大的工具来充当“决策”和“触发”的核心。这就是 Argo Events。Argo Events 允许你定义强大的事件驱动工作流使你的系统能够对故障、安全漏洞或业务触发器等事件做出反应而无需人工干预。Argo Events是一个 Kubernetes 原生的事件驱动工作流自动化框架。它使用户能够使用事件源、传感器和触发器来定义和管理基于事件的自动化。例如Argo Events 可以接收你的 Webhook 事件并将其传递给相应的传感器。该传感器随后会触发适当的操作在本例中这个操作是一个工作流。Argo Events 的核心组件Argo Events 主要由四个组件构成https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/f8a659f7c0e2e0f03953875216411856_4.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/f8a659f7c0e2e0f03953875216411856_6.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/f8a659f7c0e2e0f03953875216411856_8.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/f8a659f7c0e2e0f03953875216411856_10.png事件源定义了从外部源消费事件的配置。它可以转换事件并将事件分派到事件总线。例如如果你想消费一个 Webhook就需要创建一个 Webhook 事件源配置。事件总线传输层负责将事件源连接到传感器。用于此目的的组件包括 Kafka、NATS JetStream 等。传感器监听来自事件总线的事件并触发相应的操作。控制器管理器一个常规的 Kubernetes Operator负责管理上述组件。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/f8a659f7c0e2e0f03953875216411856_12.png实战演示自动响应加密挖矿告警理论部分已经介绍完毕现在让我们通过一个具体的演示来看看如何将 Argo Events 应用于实际场景。在本演示中我们将模拟一个场景一个恶意行为者在夜间侵入你的环境并在你的集群中运行加密挖矿程序。如果没有自动修复你可能只有一些告警来告诉你 CPU 或 GPU 使用率激增但这很可能被忽略直到早晨。因此你需要一种更快应对此场景的方法。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/f8a659f7c0e2e0f03953875216411856_14.png演示流程如下检测使用 Prometheus Alertmanager 通知 Argo Events 集群中正在运行加密挖矿程序。决策Argo Events 将接收此事件对其进行过滤、处理并触发高严重性的告警。行动随后执行一个 Argo Workflow。该工作流将捕获受影响 Pod 的元数据然后使用网络策略隔离该 Pod使用 Trivy 扫描容器镜像并通过 Slack 或 PagerDuty 发出警报。以下是演示中关键配置的说明事件源配置我们配置了一个 Webhook 事件源来接收来自 Alertmanager 的告警。我们指定了端口、端点和使用 POST 方法。同时使用了 Bearer Token 进行身份验证。Argo Events 会过滤所有请求仅当告警状态为firing、严重性为critical且告警名称为cryptominer-detected时才采取行动。传感器配置传感器接收到事件后会将其转换为更友好的结构提取 Pod 名称、命名空间、实例和受影响的容器等信息。然后传感器启动一个 Argo Workflow并将转换后的值作为工作流参数传递。修复工作流工作流包含多个修复和数据收集步骤目的是快速捕获所有数据并限制 Pod直到值班人员前来检查。使用kubectl获取 Pod 日志和元数据并将所有数据保存到 S3 以供进一步分析。应用网络策略以隔离该 Pod阻止其所有入站和出站流量。使用 Trivy 扫描容器镜像以查找可能的安全问题。通过 Slack 通知用户有关潜在加密挖矿程序的信息并附上之前保存到 S3 的数据链接。封锁节点以防节点本身出现问题。通过这个演示我们看到了一个完整的自动修复流程如何从告警开始经过决策判断最终执行一系列复杂的修复动作全部自动化完成。最佳实践与优势在构建自动修复系统时遵循一些最佳实践至关重要验证与过滤事件不要每次发生事件都触发修复只在需要时才行动。添加重试策略和死信队列以防处理过程中出现故障。确保操作幂等性避免多次触发同一操作。为系统添加告警和监控监控自动修复流程本身。充分测试你的流水线模拟各种场景并观察系统的反应。使用 Argo Events 构建自动修复系统能带来诸多好处支持多种事件源和目的地是开源且容器原生的。即插即用易于扩展和维护。支持基本的事件过滤和丢弃对于更复杂的逻辑可以轻松添加工作流来处理。可以组合多个事件源例如可以同时使用 Alertmanager 和 AWS Guard Duty 来检测加密挖矿只有从两者都收到通知时才确认事件这用 Argo Events 很容易实现。通过自动化值班手册可以最大限度地减少人为错误自动化响应速度远快于人工。降低运营成本和手动工作量让工程师从重复性的故障排查中解放出来专注于创新。增强安全性可以检测安全异常并立即触发缓解措施。总结https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/f8a659f7c0e2e0f03953875216411856_16.png本节课中我们一起学习了如何利用 Argo Events 实现实时事件的自动修复。我们从自动修复的核心概念和工作原理讲起深入介绍了 Argo Events 作为事件驱动自动化框架的组件与能力。通过一个完整的加密挖矿告警响应演示我们看到了如何将检测、决策、行动三个阶段无缝衔接构建出自愈系统。最后我们探讨了实施自动修复的最佳实践及其为系统弹性、安全性和运营效率带来的显著优势。希望本教程能帮助你开始构建自己的自动化修复流水线。021利用 Argo CD 管理 OCI 源内容https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_1.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_3.png概述在本教程中我们将学习 ArgoCD 如何实现对 OCIOpen Container Initiative仓库的原生集成。我们将了解其背后的工作原理、带来的优势、开发历程以及如何开始使用这一新功能。通过本教程初学者可以理解如何将 OCI 仓库作为应用清单的存储源从而在 Git 受限或更偏好容器化工作流的环境中部署应用。核心组件Repo Server 的工作原理上一节我们介绍了本教程的概述本节中我们来看看实现 OCI 集成的核心组件——Repo Server 是如何工作的。理解后端机制有助于明白 ArgoCD 如何支持 OCI。ArgoCD 包含多个组件如应用控制器、应用集控制器等。其中Repo Server 是后端访问 Git、Helm 以及现在 OCI 的接入点。Repo Server 维护着几种不同的缓存内存缓存用于存储版本信息。对于 Git 仓库这包括提交哈希、标签和分支名对于 OCI 仓库则是镜像标签。磁盘缓存用于存储从 Git、OCI 镜像等提取的所有文件。Redis 缓存用于存储渲染后的清单。OCI 的实现需要与这些缓存和功能点集成。幸运的是OCI 的工作方式与 Git 和 Helm 足够相似使得集成变得相对顺畅。在 Repo Server 内部为了实现这些缓存和功能OCI 层需要完成以下三个核心步骤解析版本访问 OCI 仓库获取所有标签根据用户指定的版本范围如语义化版本进行匹配并找到最新的一个然后将版本列表缓存起来。获取制品拉取 OCI 清单Manifest制品。通常一个 OCI 制品包含一个层Layer该层包含了用于生成清单的所有文件。提取内容将上述文件提取到磁盘使其可供渲染逻辑使用。所有渲染逻辑在 Git、Helm 和 OCI 之间都是相同的这保证了可靠性。但上述前三个阶段必须由 OCI 层具体实现。使用 OCI 的优势上一节我们了解了 Repo Server 如何支持 OCI本节中我们来看看使用 OCI 作为源能带来哪些实际好处。最大的优势在于你无需改变现有的 ArgoCD 使用模式。你可以沿用与 Git 或 Helm 仓库相同的模式只是将内容打包成新格式并推送到 OCI 注册表而非 Git 仓库。以下是使用 OCI 源的具体优势突破环境限制在许多组织尤其是受严格监管的行业的生产环境中可能不允许使用 Git。此时可以使用必须可用的 OCI 制品注册表如容器镜像仓库来存储清单。简化演示与测试对于创建演示或测试场景无需搭建 GitLab 或配置防火墙规则开放 Git 访问可以直接使用 OCI 仓库中的内容。增强安全与元数据OCI 社区的工作使得可以在主要部署制品之外存储各种额外的元数据和安全性制品。例如你可以在包含 ArgoCD 所需文件的 tar 包上附加签名或添加其他元数据未来可能支持基于制品类型的搜索或过滤。提供更多选项对于 Helm 用户现在有多种使用方式作为扁平的 Git 仓库、OCI Helm 图表、传统 Helm 仓库或作为 OCI 制品。这为在不同架构环境中工作提供了灵活性。功能开发历程与社区协作上一节我们探讨了使用 OCI 的优势本节中我们来回顾一下这个功能从构想到实现的开发历程这离不开开放的社区协作。OCI 支持功能是许多人共同努力的成果。其愿景最初由 Red Hat 的 Andy 在两年前提出并形成了详细的提案。来自 Akuity、Intuit、Microsoft 等公司的开发者如 Blake、Michael也基于客户需求如在隔离环境中的部署需求推动了这一功能的开发。开发过程并非一帆风顺。从 2023 年到 2025 年团队经历了漫长的努力。初始概念验证POC很快完成但后续的“最后 10%”工作如理解 OCI 规范细节、设计单层还是多层结构、如何与 ArgoCD 现有架构无缝集成花费了大量时间进行打磨和重构。跨社区协作是成功的关键。ArgoCD 社区与 OCI 规范社区特别是 Auras 项目保持了紧密沟通。通过专门的 Slack 频道来自全球北美、欧洲、亚太的贡献者共同讨论、设计和实现。Microsoft 的团队也基于新的用例投入资源帮助推进开发。这个功能预计将在 ArgoCD 3.1 版本中正式发布。组织支持对开源的重要性上一节我们看到了社区协作的力量本节中我们强调一个更深层的成功因素组织对开源贡献的支持。实现这样一个重大功能需要贡献者投入大量连续的时间。如果没有所在组织的支持允许员工在工作时间内参与开源开发这几乎是不可能完成的。时间投入是关键开发者通常有繁忙的内部任务。获得组织批准将一部分工作时间即使是 5% 或 10%用于特定开源功能开发是极其宝贵的。多元贡献模式开源项目既需要能够快速提交错误修复的贡献者也需要能够长期深入项目、负责设计评审和方向指导的资深贡献者。两者都需要组织的支持。互利共赢组织支持开源不仅能推动项目发展也能为组织带来技术影响力、人才吸引力和对项目方向的发言权。Microsoft 等公司投入开源也需要了解社区的真实需求来指导投资方向。如何使用 OCI 源上一节我们强调了成功背后的支持体系本节中我们回到技术层面看看如何在 ArgoCD 中实际配置和使用 OCI 源。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_5.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_7.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_9.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_11.png在即将发布的 ArgoCD 3.1 中将引入一个新的 OCI 客户端类型。这意味着除了现有的git和helm现在多了一个oci源类型。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_13.png以下是配置的核心要点https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_15.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_17.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_19.png协议前缀在配置仓库 URL 时使用oci://作为协议前缀ArgoCD 就会自动进入 OCI 模式。制品要求开箱即用地支持构建为特定 OCI 镜像类型如application/vnd.oci.image.manifest.v1json的单层制品。也可以通过环境变量添加对自定义媒体类型的支持。Helm OCI 图表原生支持 Helm OCI 图表其处理方式有特殊逻辑。路径与版本targetRevision对应 OCI 仓库中的标签。path取决于制品构建方式通常是制品层中的目录路径。对于 Helm OCI 图表路径固定为当前目录.。凭证OCI 仓库凭证的配置方式与其他源类型类似支持 HTTPS 和 HTTP不推荐。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_21.png创建 OCI 制品的过程与使用docker push类似。你可以使用oras等工具将包含清单文件的目录推送到兼容 OCI 的注册表如 Docker Hub、GHCR、ACR 等并可以添加作者、描述等 OCI 元数据。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_23.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_24.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_26.png总结在本教程中我们一起学习了 ArgoCD 原生集成 OCI 仓库的方方面面。我们首先了解了Repo Server是实现此功能的核心它通过解析版本、获取制品和提取内容三个步骤来处理 OCI 源。接着我们探讨了使用OCI 源的优势包括突破 Git 环境限制、简化流程、增强安全性与元数据支持并为部署提供了更多选项。然后我们回顾了这个功能的开发历程看到了从提案到实现过程中全球开源社区的紧密协作。我们也认识到组织支持对于完成此类大型开源功能至关重要。最后我们介绍了如何在 ArgoCD 中配置和使用 OCI 源包括协议前缀、制品要求和凭证配置。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/30878e14fa38af885ce292a142e1ae8d_28.png虽然现场演示因网络问题未能完美展示但该功能已基本就绪等待社区试用和反馈。这是一个通过社区协作克服挑战、扩展 ArgoCD 适用性的优秀范例。023自动扩缩与渐进式交付——天作之合https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_1.png在本节课中我们将要学习如何将 Argo Rollouts 与 Horizontal Pod Autoscaler (HPA) 结合使用以实现既安全又经济的渐进式交付。我们将探讨成本挑战、解决方案以及两者协同工作的具体方式。课程概述大家好我是 Cosmin来自 Octopus Deploy 的开发者布道师也是专注于 Argo Rollouts 和 Argo CD 的 Argo 团队成员。今天与我一同演讲的是 Anastasiia。大家好我是 Anastasiia Gubska来自英国电信的 SRE/DevOps 工程师也是 CNCF 大使。我们致力于推广 Argo Rollouts。本次演讲将深入探讨在采用渐进式交付策略时如何利用 Argo Rollouts 和 HPA 来应对成本挑战。渐进式交付与 Argo Rollouts 基础让我们从基础开始。Argo Rollouts 是一个用于实现渐进式交付的工具或解决方案。渐进式交付主要包含两种策略蓝绿部署和金丝雀发布。蓝绿部署同时运行两个环境。蓝色环境运行应用的稳定版本绿色环境运行新版本。当新版本在绿色环境就绪后再将流量完全切换过去。金丝雀发布同样使用两个环境但会逐步将流量从旧版本迁移到新版本。这让我们有机会在增加流量前验证应用运行状况或在发现问题时快速回滚。使用渐进式交付策略的好处在于可以在零停机的情况下发布新版本并能自动化处理回滚以解决问题。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_3.pngArgo Rollouts 是 Kubernetes 原生的它不依赖Argo CD两者可以独立工作。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_5.png安装 Argo Rollouts 后你会获得一个新的 Kubernetes 资源类型Rollout。这意味着你可以通过两种方式使用它为现有的Deployment添加渐进式交付策略。直接创建一个新的Rollout资源。以下是一个金丝雀策略的Rollout配置示例https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_7.pngapiVersion:argoproj.io/v1alpha1kind:Rolloutmetadata:name:example-rolloutspec:replicas:10strategy:canary:steps:-setWeight:10-pause:{duration:1h}-setWeight:20# ... 更多步骤https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_9.png如代码所示你可以从 10% 的流量开始暂停一小时后再将流量提升至 20%。Argo Rollouts 提供了仪表盘可以实时查看部署状态。你能看到稳定的旧版本 Pod 和预览的新版本 Pod 的数量及流量分配情况。Argo Rollouts 的一个强大特性是自动化监控。它会持续检查应用的性能和健康状态。如果发现问题它会自动回滚并标记部署失败如果一切顺利则自动完成部署并标记成功。这意味着整个部署过程可以无需人工干预。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_11.png想象一下你的团队可以在周五下午 5 点发起一个部署然后安心下班Argo Rollouts 会替你完成后续所有工作。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_13.png认识 Horizontal Pod Autoscaler (HPA)接下来我们谈谈自动扩缩。本次讨论聚焦于Horizontal Pod Autoscaler。HPA 会根据需求自动增加或减少 Pod 的数量。还有其他类型的扩缩器如垂直扩缩、集群扩缩、基于自定义指标的扩缩以及 Kubernetes 事件驱动扩缩你可以查阅官方文档了解更多。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_15.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_17.pngHPA 监控 CPU 等指标并在负载增加时例如黑色星期五促销或国际足球赛事期间流量激增自动扩容。它使用replicas并设定阈值来决定何时扩缩。公式: HPA 的核心是根据目标指标如 CPU 使用率动态调整 Pod 副本数其行为可描述为期望副本数 ceil[当前副本数 * (当前指标值 / 目标指标值)]。渐进式交付的成本挑战与基础优化当你在云环境中采用渐进式交付策略时成本可能成为一个显著问题。我们来看看如何降低相关成本影响。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_19.png在蓝绿部署示例中两个环境各有 10 个 Pod这可能会使部署成本翻倍。同样在金丝雀发布中当流量完全切换到新版本时你也会暂时拥有双倍的 Pod 数量导致成本增加。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_21.png有些人喜欢让测试运行数天甚至数周但这并非使用 Argo Rollouts 最有效的方式。Argo Rollouts 更适合快速部署。不过我们理解某些场景下确实需要长时间测试。在直接使用 HPA 之前让我们先看看 Argo Rollouts 本身提供的成本控制选项。以下是无需 HPA 即可控制成本的方法。有些人想直接使用 HPA但我们可以先通过调整 Rollout 设置来管理成本。配置中高亮的属性可以帮助你管理成本并固定部署期间使用的 Pod 数量。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_23.png我们建议你先了解这些选项再尝试使用 HPA 策略。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_25.png蓝绿部署的成本控制通过设置previewReplicaCount字段可以固定预览环境的 Pod 数量。例如将其设为 5意味着预览版本将只有 5 个 Pod这能自动将部署成本降低 50%。金丝雀部署的成本控制在金丝雀发布中你可能同时运行 20 个 Pod导致成本翻倍。通过设置dynamicStableScale: true属性系统可以在增加新版本 Pod 时自动减少稳定版本中的 Pod 数量从而控制总资源消耗。我们还有另一个解决方案可以讨论。使用流量管理进行成本优化在金丝雀发布中除了控制 Pod 数量我们还可以使用流量控制器来管理发送到每个 Pod 的流量比例。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_27.png左侧是没有流量管理的例子每个 Pod 接收固定的流量比例例如一个 Pod 接收 10% 流量。右侧是使用流量管理本例使用 Linkerd的例子你可以将 80% 的流量导向一个 Pod。这样我们可以固定 Pod 数量例如 5 个但通过流量管理决定新版本接收多少流量例如 50%。这有助于通过减少稳定版本的 Pod 数量来管理成本。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_29.png配置中我们添加了maxTrafficPercentage: 50等字段来限制发送到新版本的最大流量比例。整合 HPA 与 Argo Rollouts假设你不想使用 Anastasiia 提到的那些选项而由于某些原因想使用 HPA。第一个问题是HPA 能与 Argo Rollouts 一起工作吗答案是肯定的。你可能已经将 HPA 用于普通的Deployment。本质上HPA 可以与任何实现了scale子资源的对象一起工作。Argo Rollouts 实现了这个端点因此两者可以协同。scale端点有三个属性当前副本数、期望副本数和状态。由于 Argo Rollouts 已实现此端点我可以创建一个 HPA 配置并将其指向Rollout而不是Deployment它就能正常工作。在我们的示例中我们创建了一个 HPA 配置设置最小 1 个 Pod最大 10 个 Pod并基于内存使用率进行扩缩。代码库中还包含一个示例应用每次调用会多占用 1MB 内存你可以将其与 HPA 一起应用观察 HPA 的实际工作方式。当两者一起使用时会发生什么在蓝绿部署中启用 HPA 后在内存使用较低时左图HPA 决定只需要 3 个 Pod并将相同数量应用于预览 Pod 和稳定 Pod。在内存使用较高时右图HPA 决定需要更多 Pod并同时控制预览 Pod 和稳定 Pod 的数量。结论在蓝绿部署中HPA 同时影响所有 Pod。在金丝雀部署中也是如此。在流量 50% 导向新 Pod 的中间阶段Argo Rollouts 通常规定预览 Pod 数量是稳定 Pod 的一半。HPA 会根据负载决定具体的 Pod 数量例如低负载时需要 4 个预览 Pod 和 8 个稳定 Pod高负载时需要 5 个预览 Pod 和 10 个稳定 Pod。这是开箱即用的工作方式。冲突解决当 Argo Rollouts 遇到 HPAhttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_31.pnghttps://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_33.png我知道你在想什么如果同时使用 HPA 和 Anastasiia 提到的选项会发生冲突吗正如之前剧透的Argo Rollouts 会胜出。它将接管控制权。例如在同时使用 HPA 并设置了previewReplicaCount: 3的场景中Argo Rollouts 将接管控制预览 Pod 数量将始终为 3无论 HPA 如何指示。在这种场景下HPA 只控制稳定 Pod不控制其他。在金丝雀部署中也是如此。如果我指定将 50% 的流量发送给 3 个 Pod这将被强制执行并覆盖 HPA 的指示。HPA 将只影响稳定 Pod预览 Pod 完全由 Argo Rollouts 控制。总结与资源谢谢 Cosmin。让我们来总结一下。Argo Rollouts 使你的部署变得简单且安全。正如我们之前所示在跳转到使用 HPA 之前了解其他可用选项和一些有助于控制 Rollout 的属性非常重要。评估成本节约、业务需求和部署的灵活性也至关重要。我们展示的选项应该能让你在不使用 HPA 的情况下使用 Argo Rollouts从而简化事务。并且正如 Cosmin 所说在发生冲突时Argo Rollouts 的规则将始终覆盖 HPA。我们鼓励你查看官方文档。我们稍后会分享一些链接。首先我们想分享这张幻灯片它总结了今天讨论的所有用例。标为橙色的单元格是人们经常混淆的例子值得仔细研究并试验看看哪种最适合你的业务场景。你可以拍下这张幻灯片或者使用幻灯片底部的二维码链接查看。最后我们提供了一些有用的链接Argo Rollouts 概念文档Argo Rollouts 特性文档本次演讲的示例代码库为活动组织者提供的无障碍指南如果你有任何问题可以通过 Slack 联系我们。也请反馈你对今天演讲的看法告诉我们你喜欢的内容或未来希望听到更多的话题。https://github.com/OpenDocCN/cs-notes-pt1-zh/raw/master/docs/argocon-eu-2025/img/865dade7187ea96e018c33e4c201ea92_35.png本节课中我们一起学习了 Argo Rollouts 与 HPA 的集成了解了渐进式交付的成本优化方法以及两者协同工作时的优先级规则。希望这些知识能帮助你构建更高效、更经济的云原生交付流程。