kodacd/argo-rollouts

Gloo Platform Argo Rollouts插件

概述

该插件是一个POC（概念验证）实现，用于支持Gloo Platform API的https://argoproj.github.io/argo-rollouts/features/traffic-management/plugins/%E3%80%82**%E6%B3%A8%E6%84%8F%EF%BC%9A%E6%AD%A4%E6%8F%92%E4%BB%B6%E4%B8%BAPOC%E8%B4%A8%E9%87%8F%EF%BC%8C%E4%B8%94Argo Rollouts在1.5版本中刚发布alpha功能，使用时需谨慎！**

插件模式基于https://github.com/argoproj-labs/rollouts-plugin-trafficrouter-gatewayapi%E5%AE%9E%E7%8E%B0%EF%BC%8C%E5%8F%AF%E7%94%A8%E4%BA%8E%E5%9C%A8Kubernetes%E9%9B%86%E7%BE%A4%E4%B8%AD%E9%80%9A%E8%BF%87Gloo Platform进行渐进式发布（如金丝雀、蓝绿部署）的流量路由管理。

Rollouts核心概念

Argo Rollout CR可视为Kubernetes Deployment CR的替代方案，主要包含两部分核心配置：

• 与Deployment类似的Pod模板
• 滚动发布策略配置（步骤、权重、暂停等）

尽管可以引用Deployment获取Pod模板细节，但Rollouts不会直接管理被引用的Deployment。

工作流程

1. 创建稳定版（stable）和金丝雀版（canary）或蓝绿部署的K8s服务
2. 创建路由至稳定版服务的Gateway/Ingress资源
3. 不创建Deployment，而是创建包含Pod模板的Rollout资源
4. Rollout控制器工作逻辑：
   • 首次部署时，创建初始ReplicaSet
   • 非首次部署时，通过比较现有ReplicaSet的Pod模板哈希判断是否需要更新
     • 若需更新，则根据Rollout规范执行金丝雀或蓝绿发布

插件架构与安装

Argo Rollouts使用Hashi的https://github.com/hashicorp/go-plugin%EF%BC%8C%E6%8F%92%E4%BB%B6%E6%98%AF%E9%81%B5%E5%BE%AAArgo Rollouts定义的RPC接口的Go二进制文件。插件可嵌入Argo Rollouts控制器镜像，或在容器启动时下载。

安装方式

当前下载方式存在问题（参考社区讨论），推荐使用预嵌入插件的衍生镜像：

1. 使用镜像 kodacd/argo-rollouts:latest（POC阶段，仅更新latest标签）
2. 配置Argo Rollouts ConfigMap：

yaml
trafficRouterPlugins: "- name: \"solo-io/glooplatformAPI\"\n  location: \"file://./plugin\" "

使用场景

适用于在Kubernetes集群中已安装Gloo Platform，需要需要通过Argo Rollouts实现渐进式发布（如金丝雀部署、蓝绿部署）的场景，支持基于权重的流量分配和手动验证步骤。

使用方法

前置要求

1. 已安装Gloo Platform的Kubernetes集群
2. （可选）Argo Rollouts kubectl插件（用于 dashboard，参考安装文档）
3. （可选）Argocd + Argo Rollouts UI扩展（参考https://github.com/argoproj-labs/rollout-extension%EF%BC%89

部署步骤

1. 安装Argo Rollouts

bash
kubectl create ns argo-rollouts
kubectl apply -f ./examples/_install_rollouts/argo-rollouts.yaml -n argo-rollouts

此清单使用已嵌入Gloo Platform插件的镜像，并包含Argo Rollouts配置。

2. 创建初始工作负载状态

包含K8s服务、Gloo VirtualGateway和RouteTable（不含Deployment）：

bash
kubectl apply -f ./examples/demo-api-initial-state

3. 创建初始Rollout资源

首次部署时，将创建初始ReplicaSet：

bash
kubectl apply -f ./examples/0-rollout-initial

4. 查看Rollout dashboard（可选）

bash
kubectl argo rollouts dashboard &
open http://localhost:3100/rollouts/gloo-rollout-demo

5. 验证API

通过端口转发访问API，应返回v1版本响应：

bash
kubectl port-forward $(kubectl get pods -l istio=ingressgateway -n gloo-mesh-gateways -oname) -n gloo-mesh-gateways 8080:8080
curl localhost:8080/demo  # 预期响应: {"image":"kodacd/argo-rollouts-demo-api","tag":"v1"}

6. 启动金丝雀部署

应用更新后的Rollout CR（镜像标签从v1改为v2）：

bash
kubectl apply -f ./examples/1-rollout-first-change 

7. 监控与验证

• 在Argo Rollouts UI中可看到金丝雀步骤（如10%流量权重）及手动暂停状态
• 持续请求API可观察v1和v2版本的混合响应
• 可手动推进各步骤或直接"完全推广"至100%流量

配置参数说明

Rollout资源中流量路由插件配置示例：

yaml
trafficRouting:
  plugins:
    solo-io/glooplatformAPI:
      # 必选；需提供标签选择器或显式RouteTable名称
      routeTableSelector:
        # 标签需精确匹配RouteTable
        # 若提供name，则忽略标签选择器
        labels:
          app: demo
        # 默认为Rollout所在命名空间
        namespace: gloo-mesh
        # 若提供name，标签选择器将被忽略
        # name: my-rt-name

      # 可选；选择匹配RouteTable中的特定路由
      # 适用于多个路由指向同一后端但无需全部参与金丝雀的场景
      routeSelector:
        # 通过标签选择路由；若提供name则忽略标签
        labels:
          route: demo-preview
        # 若提供name，标签选择器将被忽略
        # name: route-name

已知问题与TODO

• Gloo UI中显示Pod名称而非Deployment名称（因Rollout不生成Deployment），需支持Deployment CR生成（参考https://github.com/argoproj/argo-rollouts/issues/2779%EF%BC%89
• 待实现功能：
  • 使用github.com/solo-io/solo-apis/client-go/common.gloo.solo.io/v2 ObjectSelector支持按工作区过滤RouteTable
  • 实现setheader路由
  • 添加单元测试
  • 支持不同forwardTo.destination.kinds
  • 处理目标已存在的"静态"权重路由
  • 实现RouteTable和Route的标签选择器
  • 处理稳定版与金丝雀版的不同目标类型
  • 发布完成后移除金丝雀目标（当前仅设为0权重）
  • 支持命名端口