跳到主要内容

金丝雀发布

金丝雀发布会把部分流量发送到新版本，评估结果后再提升或拒绝该版本，从而限制应用更新的影响范围。Ingress Controller 通过把加权路由同步到网关来支持此工作流，发布自动化系统则控制应用版本和期望的流量权重。

金丝雀发布的工作原理​

发布自动化位于请求路由之上。下图分别展示发布控制、路由同步和请求处理。


在此流程中，GitOps、CI 或操作人员应用新的应用版本。发布自动化决定该版本的流量放量速度，并更新期望的流量权重。Ingress Controller 转换加权路由，网关负责转发每个请求。指标、检查或人工批准决定发布是否继续。

选择发布自动化方式​

发布过程可以由专用控制器、CI/CD 工作流或人工操作流程管理。无论使用哪种方式，都应做到：

  • 协调稳定版与金丝雀工作负载及其 Service 选择器。
  • 按照既定顺序或分析策略修改路由权重。
  • 能够暂停、提升或回滚发布，且不会与其他协调器冲突。

选择 Route API​

无论使用 Gateway API HTTPRoute 还是 APISIX ApisixRoute CRD，发布流程都相同：转移流量、评估结果，然后提升或回滚。Route API 决定自动化系统如何更新流量权重，以及可以使用哪些路由能力：

  • HTTPRoute 是可跨实现移植的标准 Gateway API 资源。当 Gateway API 能表达所需路由行为时，新集成应优先使用它。
  • 对于现有 APISIX 自定义资源部署，或路由需要 Gateway API 无法表达的 APISIX 专用插件或策略时，请使用 ApisixRoute。

APISIX Ingress Controller 和 API7 Ingress Controller 均支持 apisix.apache.org/v2 资源；两种产品中的 HTTPRoute 都使用标准 gateway.networking.k8s.io/v1 API。不要仅为了满足发布自动化，就为相同主机和路径同时维护两种 Route 类型。

协调资源所有权​

金丝雀自动化会为集群增加一个协调器。请为每个可能变化的对象或字段指定唯一所有者：

  • 发布自动化系统负责应用发布、稳定版和金丝雀 Service 选择器，以及发布期间的后端权重。
  • 平台或 GitOps 配置负责 Ingress Controller 与网关安装，以及发布期间保持不变的路由主机、路径、插件和策略。
  • Ingress Controller 负责把 Kubernetes Route 转换并同步到网关。

发布自动化修改路由权重时，不要让 GitOps 控制器持续恢复这些权重。当所选工作流负责初始化权重时，请从期望的 Route 中省略这些字段。如果其他策略仍报告漂移，请仅针对这些字段配置范围尽可能小的差异忽略规则。

有些发布系统会生成 Service 或 Route，而不是更新你提供的资源。不要把生成的资源提交到 Git，也不要把它们加入其他 Helm Release 或 Kustomize Base。

定义发布策略​

实现工作流之前，请确定：

  • 第一步接收多少流量、金丝雀最大权重，以及每一步的观察时长。
  • 哪些成功率、延迟、饱和度和应用专用指标决定发布是否继续，以及多少次检查失败会触发回滚。
  • 生产提升是否需要人工批准，以及指标提供方或负载生成器不可用时如何处理。

请选择包含足够请求量的观察窗口，使结果具有意义。仍然需要健康探针，但它们不能替代发布分析：Pod 可能已就绪，却会针对特定 API、租户或依赖返回错误。

集成示例​

以下指南演示如何使用两个第三方发布控制器进行金丝雀发布。两个工具也支持其他发布策略，但可用性会因流量提供方而异。这些是经过测试的金丝雀示例，并非兼容自动化方案的完整清单：

集成状态

这些第三方项目独立于 Ingress Controller 项目决定其发布集成的成熟度和支持状态。请阅读所选指南中的警告，并在非生产集群中验证具体的控制器、网关和发布控制器版本。

相关内容​