灰度发布与蓝绿部署实战

百万DAU社区实战：为何从Ingress注解迁移至Argo Rollouts v1.7.2

去年双十一前夜，我们那个百万DAU的社区动态流服务面临一个棘手的问题。当时用的还是 Nginx Ingress 自带的 nginx.ingress.kubernetes.io/canary 注解做灰度，流量切到 20% 的时候，新版本因为缓存击穿导致 P99 延迟从 120ms 飙到了 800ms。那时候我只能手动改 Ingress 权重，回滚过程花了整整 3 分钟，期间大量用户刷新动态失败。

这次事故让我下定决心重构发布体系。我调研了一圈，最终选定了 Argo Rollouts v1.7.2（2024年5月发布的最新稳定版）。为什么是这个版本？因为它解决了我们当时最痛的几个点：多集群支持和对分析指标的实时性增强。我们当时在灰度到 10% 的时候，Prometheus 里的错误率其实已经红了，但 Ingress 注解根本没法自动感知并回滚。

迁移后的第一个收益是零停机更新的可靠性。以前用 Ingress 注解，新旧 Service 切换时总会有几秒的流量丢失，因为 Ingress Controller 重载配置需要时间。Argo Rollouts 直接接管了 ReplicaSet 的生命周期，配合我们自建的 Gateway API，切换过程对客户端完全透明。

下面是我们在生产环境跑的第一个 Rollout 配置，直接替换了原来的 Deployment：

apiVersion: argoproj.io/v1.7.2
kind: Rollout
metadata:
  name: community-feed-v2
  namespace: production
spec:
  replicas: 10
  strategy:
    canary:
      # 关键：分阶段推进，每步间隔 5 分钟观察
      steps:
      - setWeight: 5
      - pause: {duration: 5m}
      - setWeight: 20
      - pause: {duration: 5m}
      - setWeight: 50
      - pause: {duration: 5m}
      # 自动分析：一旦失败立刻回滚
      analysis:
        templates:
        - templateName: success-rate-check
        args:
        - name: service-name
          value: community-feed-svc
  selector:
    matchLabels:
      app: community-feed
  template:
    metadata:
      labels:
        app: community-feed
        version: v2.3.1
    spec:
      containers:
      - name: feed-service
        image: registry.xxx.com/community/feed:v2.3.1
        ports:
        - containerPort: 8080
        # 健康检查必须配，否则自动回滚会误判
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

这个配置里最让我省心的是 analysis 部分。我们定义了一个 success-rate-check 的模板，它会去查 Prometheus 里 http_requests_total{status=~"5.."} 的速率。如果 5xx 错误率超过 1%，Rollout 会自动把流量切回旧版本。

有一次线上接口突然变慢，排查下来发现是新版本里一个 N+1 查询问题。当时流量已经切到 20%，但因为配置了自动分析，系统在 2 分钟内就检测到了延迟异常并自动回滚，用户甚至没感知到。要是用以前的 Ingress 注解，我估计得等监控告警炸锅了才能手动介入。

另外，v1.7.2 版本对多集群的支持也帮了大忙。我们的社区业务跑在两个 Kubernetes 集群里，以前做灰度得分别去两个集群改 Ingress，现在 Argo Rollouts 配合 Argo CD 可以统一管理，发布策略在 Git 里声明一次，两个集群同步生效。

选型对比：Argo Rollouts vs Flagger——谁更适合高并发交易链路？

我们团队内部在重构发布系统时，针对 Argo Rollouts 和 Flagger 做过一次为期两周的压测对比。场景是我们那个订单交易链路，峰值 QPS 能到 1.2 万，对延迟和错误率极其敏感。

我直接说结论：对于高并发、强一致性的交易链路，Argo Rollouts 更适合。原因不是 Flagger 不好，而是两者的设计哲学不同。Flagger 深度绑定 Istio 等 Service Mesh，依赖 Sidecar 做流量劫持；而 Argo Rollouts 更轻量，既支持 Service Mesh，也支持纯 Ingress/Nginx 场景，甚至能直接管理 ReplicaSet。

我们当时在测试环境复现了一个场景：新版本订单服务引入了慢 SQL，导致接口 RT 从 50ms 涨到 500ms。我们分别用两者配置了基于 Prometheus 指标的自动回滚。

这是我们在 Flagger 里的配置片段：

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: order-service
spec:
  # Flagger 必须依赖 Provider，这里用的是 Istio
  provider: istio
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  service:
    port: 8080
    # Istio 相关的流量配置
    gateways:
    - public-gateway.istio-system.svc.cluster.local
    hosts:
    - order.xxx.com
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: request-success-rate
      templateRef:
        name: success-rate
      thresholdRange:
        min: 99
    - name: request-duration
      templateRef:
        name: latency
      thresholdRange:
        max: 100

这是 Argo Rollouts 里的对应配置（核心部分）：

apiVersion: argoproj.io/v1.7.2
kind: Rollout
metadata:
  name: order-service
spec:
  strategy:
    canary:
      analysis:
        # 实时性更强，v1.7.2 优化了这里的计算逻辑
        interval: 30s
        successCondition: result[0] >= 0.99
        failureCondition: result[0] < 0.99
        metrics:
        - name: success-rate
          successCondition: result[0] >= 0.99
          failureCondition: result[0] < 0.99
          provider:
            prometheus:
              address: http://prometheus.istio-system:9090
              query: |
                100 - sum(rate(http_requests_total{app="order",status=~"5.."}[1m])) 
                / sum(rate(http_requests_total{app="order"}[1m])) * 100

压测结果很有意思。在 1.2 万 QPS 下，Flagger 因为 Istio Sidecar 的额外开销，订单服务的 P99 延迟增加了约 8ms，内存占用多了 70MB 左右。而 Argo Rollouts 在这种纯 Nginx Ingress 场景下，几乎没有额外开销。

另一个关键区别是环境隔离性。我们的交易链路有个硬性要求：发布过程中，新旧版本不能共享同一个进程空间或网络命名空间。蓝绿部署是合规审计要求的标配。Argo Rollouts 的 BlueGreen 策略非常干净，直接创建两套完整的 ReplicaSet，通过 Service 切换 Label 来实现流量转移，完全符合我们的审计要求。

# Argo Rollouts 的蓝绿配置
spec:
  strategy:
    blueGreen:
      activeService: order-service-active
      previewService: order-service-preview
      # 手动确认才切换，适合大版本发布
      autoPromotionEnabled: false
      # 切换前先预热预览环境
      prePromotionAnalysis:
        templates:
        - templateName: smoke-test

Flagger 虽然也支持蓝绿，但配置起来更绕，且强依赖 Mesh 的 VirtualService 资源。

不过 Flagger 也有优势，它在 A/B 测试 场景下更灵活，尤其是基于 HTTP Header 的复杂匹配规则，Flagger 配合 Istio 的 VirtualService 写起来更顺手。但我们的交易链路不需要那么复杂的 A/B 逻辑，我们更看重的是自动化回滚的速度和确定性。

最后我选了 Argo Rollouts，因为它和我们的 GitOps 流水线（Tekton + Argo CD）集成更丝滑，而且 v1.7.2 版本对多集群的支持让我们在跨地域发布时少写了很多胶水代码。

深度实战：基于Header与权重的渐进式交付与eBPF流量观测

上个月我们上线一个针对 VIP 用户的动态流新算法，需要精准地把内部员工和北京地区的用户导流到新版本，同时观察性能。这种需求用简单的权重切流是搞不定的，必须上 Header 匹配。

我直接用了 Argo Rollouts 配合 Istio 的 VirtualService 来实现。这里有个细节：Argo Rollouts v1.7.2 对 setHeaderRoute 的支持已经非常稳定，可以直接在 Rollout 对象里定义流量规则，不需要手动去改 Istio 的资源。

这是我们在生产环境跑了两周的配置，实现了基于 X-User-Type: internal 和 X-Region: bj 的灰度：

apiVersion: argoproj.io/v1.7.2
kind: Rollout
metadata:
  name: feed-algo-v2
spec:
  replicas: 8
  strategy:
    canary:
      # 核心：定义流量路由
      trafficRouting:
        istio:
          virtualService:
            name: feed-vs
            routes:
            - primary
          # 这里定义 Header 匹配规则
          headers:
            - name: X-User-Type
              values: ["internal"]
            - name: X-Region
              values: ["bj"]
      steps:
      # 第一步：先切 10% 权重，同时保留 Header 路由
      - setWeight: 10
      - pause: {duration: 10m}
      # 第二步：扩大范围
      - setWeight: 50
      - pause: {duration: 10m}
      # 第三步：全量
      - setWeight: 100
  template:
    spec:
      containers:
      - name: algo-service
        image: registry.xxx.com/feed/algo:v2.1.0
        env:
        - name: ALGO_VERSION
          value: "v2"

这个配置上线后，内部员工打开 App 直接就能看到新算法的效果，而普通用户还是老版本。但我发现了一个问题：虽然流量切得准，但我不知道新版本在处理这些特定用户请求时，具体的网络开销和内核态耗时是多少。传统的 Prometheus 指标只能看到应用层的 RT，看不到 TCP 重传或者丢包。

这时候我想到了社区里最近讨论很火的 eBPF 流量观测。我引入了 Cilium 的 Hubble，利用 eBPF 在内核层直接抓包分析。

我们在灰度期间，用 Hubble CLI 实时观察 feed-algo-v2 这个 Pod 的流量：

# 观测新版本 Pod 的流出流量，过滤 VIP 用户的请求
hubble observe --pod feed-algo-v2-7d8f9 --protocol tcp --port 8080 \
  -f | grep "X-User-Type: internal"

通过 eBPF，我直接看到了新版本在处理 VIP 用户请求时，TCP 的 retries 次数比老版本高了 3 倍。进一步排查发现是新版本连接 Redis 集群时，DNS 解析逻辑有问题，导致在内核态频繁重试。这个问题如果只看应用日志，根本发现不了，因为应用层只报了个 Connection Timeout，看不出是网络层的锅。

为什么这么做？ 因为在高并发下（我们当时灰度环境 QPS 6000+），应用层的监控往往有滞后性，而且会被业务逻辑掩盖。eBPF 提供了上帝视角，能看到真实的流量路径。

如果不做这种细粒度的观测，后果就是：你可能觉得新版本功能没问题，灰度也通过了，但上线后却发现整体集群的网络负载莫名其妙地升高了，最后还得回滚查问题。

另外，关于权重控制，我们在实际执行中发现，Argo Rollouts 的 setWeight 并不是瞬间完成的。它有一个渐进的过程，配合 Istio 的 OutlierDetection，如果新版本 Pod 健康检查失败，权重会自动被剔除。

# 我们在 Istio DestinationRule 里加了实例剔除策略
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: feed-dr
spec:
  host: feed-algo-svc
  trafficPolicy:
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 1m
      maxEjectionPercent: 50

这个组合拳下来，我们那次 VIP 算法的灰度发布非常稳。先通过 Header 精准圈定人群，用 eBPF 观测内核态流量确认无异常，再通过权重逐步放大。整个过程持续了 40 分钟，期间业务指标（点击率、停留时长）完全符合预期，没有出现一次因发布导致的用户投诉。这种渐进式交付的威力，在一次次大促中已经被我们验证过了。

4. 血泪复盘：一次因HPA与灰度冲突引发的线上502排查与止损

去年双十一大促前，我们上线了一个订单核心链路的重构版本，当时使用的是 Argo Rollouts v1.6.4（现在最新稳定版已经是 v1.7.2，发布于 2024年5月，那会儿还没升级）。我本以为这次灰度发布会像往常一样平稳，结果在灰度流量推到 30% 的时候，监控大盘突然出现了大量的 502 报警，持续了将近 8 分钟才完全恢复。

原因在于我们的灰度策略与 HPA（Horizontal Pod Autoscaler）发生了冲突。当时我们的 Rollout 配置是渐进式交付，先切 10% 流量，观察 5 分钟，再切到 30%。新版本 Pod 启动后，由于初始化了一些新的缓存逻辑，启动时间从原来的 15 秒增加到了 35 秒。我们在 Rollout 里设置了 setCanaryScale 来限制灰度 Pod 数量，但忽略了 HPA 的 minReplicas 配置。

当灰度流量进来后，HPA 检测到新版本 Pod 的 CPU 使用率飙升（因为新逻辑确实更耗 CPU），立刻触发扩容。但 Argo Rollouts 在 Canary 阶段对 ReplicaSet 有严格的控制权，它期望 Canary 的 Pod 数量维持在 weight 对应的比例。HPA 的扩容指令与 Rollout 的控制逻辑打架，导致新版本的 Pod 反复被创建又销毁，Ingress 层面的健康检查频繁失败，最终返回 502。

解决方案是调整 Rollout 与 HPA 的协作方式。我在排查时通过 kubectl describe rollout 发现 Canary ReplicaSet 一直处于 Progressing 状态，但 Pod 数量一直跳变。后来我修改了策略，在 Canary 阶段禁用了 HPA 对该 Deployment 的管控，改为由 Rollout 完全接管副本数，直到全量发布完成后再交还控制权。

以下是当时我们修复后的 Rollout 关键配置片段，重点在于 canaryMetadata 和 scaleDown 策略的配合：

apiVersion: argoproj.io/v1.7.2
kind: Rollout
metadata:
  name: order-service-rollout
spec:
  replicas: 10
  strategy:
    canary:
      # 禁用 HPA 在灰度期间的干扰
      canaryMetadata:
        annotations:
          autoscaling.alpha.kubernetes.io/conditions: "disabled"
      steps:
      - setWeight: 10
      - pause: { duration: 5m }
      - setWeight: 30
      - pause: { duration: 10m }
      - setWeight: 100
      # 确保旧版本在切换后不会立即缩容，给 HPA 一个缓冲
      scaleDown:
        rules:
        - type: Analysis
          analysisRun: 
            name: success-rate-check
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
      - name: order-service
        image: registry.example.com/order-service:v2.1.4
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 30 # 针对新版本启动慢的优化
          periodSeconds: 5

这次事故让我意识到，在云原生环境下，单一维度的发布策略是不够的。现在的 Argo Rollouts v1.7.2 增强了对多集群的支持和指标实时性，其实也是为了解决这类复杂场景下的状态同步问题。如果你的系统也用了 HPA，一定要在灰度阶段明确谁拥有 Pod 数量的决策权，否则在流量洪峰下，两个控制器的冲突会直接击穿你的服务可用性。

排查过程中的关键发现

我通过查看 Argo Rollouts Controller 的日志，发现频繁出现 ReplicaSet count mismatch 的错误。深入了解后发现，Argo Rollouts 在计算 setWeight 对应的 Pod 数量时，是基于 spec.replicas 的整数比例。例如 replicas: 10 且 weight: 30 时，Canary 应该是 3 个 Pod。但 HPA 此时计算的是基于 CPU 利用率的期望值，比如它认为需要 15 个 Pod，这就产生了不可调和的矛盾。

不这么做会怎样？如果不隔离 HPA 和 Rollout 的控制权，每次灰度发布都会变成一场“抢椅子”的游戏，Pod 数量在期望值之间反复横跳，导致服务实例极不稳定。

5. 数据说话：蓝绿切换前后0 downtime与P99延迟压测对比

在金融类系统中，我们对于“零停机”的要求近乎苛刻。今年上半年，我们将支付网关从传统的虚拟机部署迁移到了 Kubernetes 上，并采用了蓝绿部署策略。为了验证这套方案是否真的能做到 0 downtime，我在预发布环境做了一次全链路压测。

测试场景是这样的：我们有一套基于 Spring Boot 的支付服务，QPS 常年维持在 2500 左右，P99 延迟要求在 200ms 以内。旧版本是 v3.2.1，运行在 8 个 Pod 上；新版本 v3.3.0 引入了全新的加密模块。我使用 Argo Rollouts 来管理蓝绿部署，因为最新版本 v1.7.2 提供了更稳定的 BlueGreen 策略支持，特别是在 autoPromotionEnabled 和 previewService 的切换逻辑上。

压测工具用的是 k6，模拟了 3000 个并发用户。我在切换的瞬间（即 activeService 从 Blue 切向 Green 的那一刻），持续发送请求。结果显示，在切换的 3 秒窗口期内，并没有出现任何请求失败（HTTP 5xx），真正做到了 0 downtime。

原因在于蓝绿部署的本质是流量入口的瞬间切换，而不是 Pod 的滚动更新。我们是通过修改 Service 的 Selector 来实现的。当 Service 的 Selector 从 version: blue 变为 version: green 时，Kubernetes 的 Endpoint Controller 会更新 Endpoints 对象，kube-proxy 或 Ingress Controller（我们用的 Nginx Ingress）会更新转发规则。由于新旧 Pod 都在运行，流量只是从一个健康的池子跳到了另一个健康的池子。

以下是我们在压测中使用的 Rollout 蓝绿配置，以及压测后的数据对比：

apiVersion: argoproj.io/v1.7.2
kind: Rollout
metadata:
  name: payment-gateway
spec:
  replicas: 8
  strategy:
    blueGreen:
      activeService: payment-active
      previewService: payment-preview
      autoPromotionEnabled: false # 手动确认，确保指标无误
      scaleDownDelaySeconds: 300 # 旧版本保留 5 分钟，防止连接未断开
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: payment-gateway
  template:
    metadata:
      labels:
        app: payment-gateway
    spec:
      containers:
      - name: payment
        image: registry.example.com/payment:v3.3.0
        env:
        - name: JAVA_OPTS
          value: "-Xmx2g -Xms2g"
        ports:
        - containerPort: 8080

压测数据对比：

| :--- | :--- | :--- | :--- |

| QPS | 2500 | 2500 | 0% |

| P99 延迟 | 185ms | 142ms | -23.2% |

| P95 延迟 | 120ms | 95ms | -20.8% |

| 错误率 (5xx) | 0% | 0% | 0% |

| 内存占用 (Heap) | 1.8GB | 1.6GB | -11.1% |

新版本的 P99 延迟从 185ms 优化到了 142ms，原因在于新的加密模块采用了更高效的本地缓存策略，减少了调用外部 KMS 的次数。

如果不采用蓝绿部署，而是用滚动更新（Rolling Update），在 Pod 重启的间隙，必然会有部分请求被转发到尚未就绪的 Pod 上，导致短暂的 502 或 503。对于支付系统，哪怕是 0.1% 的错误率，在大促期间也是无法接受的。这次压测数据也印证了 2024-2026 年技术趋势中提到的，蓝绿部署在满足严格业务连续性要求方面的价值。

关于切换时的连接耗尽

虽然 Service 层面的切换是瞬间的，但应用层的连接（如数据库连接池、HTTP Keep-Alive）并不会立刻断开。我在配置中设置了 scaleDownDelaySeconds: 300，就是为了让旧版本的 Pod 在切换后继续存活 5 分钟，处理完残留的长连接请求，然后再优雅关闭。如果不设置这个延迟，可能会导致部分正在处理的事务被强制中断。

6. 面试加分项：灰度发布与A/B测试的异同及自动化回滚机制

在面试中，很多候选人会把灰度发布（Canary Release）和 A/B 测试混为一谈，或者只谈概念，不讲落地时的细节。作为一个在一线写了 8 年代码的工程师，我通常会从业务目的和技术实现的差异来切入。

灰度发布的核心目的是降低发布风险。例如，我们上个月上线了一个用户画像服务，担心新算法会拖慢接口响应。我通过 Argo Rollouts 配置了一个灰度策略，先切 5% 的流量到新版本，并持续观察 Prometheus 中的 http_request_duration_seconds 指标。如果 P99 延迟超过 500ms，就自动回滚。

A/B 测试的核心目的是验证业务假设。比如我们想测试两种不同的推荐算法哪个转化率更高。这时候，流量分发不是基于“新旧版本”，而是基于“用户特征”。通常是根据 User ID 的哈希值或者特定的 HTTP Header（如 X-Experiment-Group: B）来决定路由。

原因在于两者的决策依据不同。灰度发布看的是技术指标（错误率、延迟、资源消耗），而 A/B 测试看的是业务指标（点击率、留存率、GMV）。

自动化回滚机制实战

自动化回滚是灰度发布的“安全气囊”。在 Argo Rollouts 中，这通常通过 AnalysisTemplate 结合 Prometheus 指标来实现。有一次，我们的商品详情页服务在灰度到 20% 时，新版本因为连接池配置错误导致大量超时。系统自动检测到了异常，并在 2 分钟内完成了回滚，没有人工干预。

以下是当时我定义的 AnalysisTemplate，它查询 Prometheus 中新版本的错误率，如果超过阈值就标记为失败：

apiVersion: argoproj.io/v1.7.2
kind: AnalysisTemplate
metadata:
  name: success-rate-check
spec:
  metrics:
  - name: error-rate
    successCondition: result < 0.01 # 错误率小于 1%
    failureCondition: result >= 0.05 # 错误率大于 5% 立即失败
    failureLimit: 3 # 连续 3 次检查失败则触发回滚
    successLimit: 5 # 连续 5 次检查成功则继续发布
    provider:
      prometheus:
        address: http://prometheus.istio-system:9090
        query: |
          sum(rate(
            http_requests_total{app="product-service", version="canary", status=~"5.."}[5m]
          )) / 
          sum(rate(
            http_requests_total{app="product-service", version="canary"}[5m]
          ))

在 Rollout 的配置中引用这个模板：

apiVersion: argoproj.io/v1.7.2
kind: Rollout
metadata:
  name: product-service
spec:
  strategy:
    canary:
      analysis:
        templates:
        - templateName: success-rate-check
        args:
        - name: service-name
          value: product-service
      steps:
      - setWeight: 20
      - analysis:
          templates:
          - templateName: success-rate-check
          duration: 5m # 观察 5 分钟
      - setWeight: 100

两者的异同总结：

相同点：都涉及流量的精细化控制，都需要基础设施（如 Service Mesh 或 Ingress）支持基于权重的流量分发。
不同点：

1. 流量分配逻辑：灰度通常是随机百分比（如 5%, 20%）；A/B 测试通常是基于特定条件（如 Header、Cookie、用户标签）。

2. 评估指标：灰度关注系统稳定性（Metrics）；A/B 测试关注业务效果（Conversion）。

3. 结束动作：灰度结束通常是全量切换或回滚；A/B 测试结束通常是保留优胜版本，下线实验版本。

如果不做自动化回滚，一旦新版本有致命 Bug，你需要人工去修改 Rollout 的 setWeight 或者手动 kubectl rollout undo，这在深夜或者高压场景下，反应速度往往跟不上故障扩散的速度。利用 Argo Rollouts v1.7.2 的分析能力，配合 Prometheus 或 Datadog 的指标，才能真正实现“无人值守”的安全发布。这也是目前 AI 驱动的智能发布 趋势的雏形，未来系统会根据历史数据自动调整灰度步长和回滚阈值。

站长实战手记

去年双十一前，我带团队给一个做生鲜电商的客户做大促护航。他们当时日活已经冲到八十多万，核心交易链路还是最原始的滚动更新，每次发版都有几秒的卡顿，客服电话能被打爆。我拍板上了 Argo Rollouts，打算用蓝绿加灰度把发版影响压到零。

一开始我直接照着文档配了 Header 路由 + 权重 10% 切流，看着仪表盘挺美。结果第一次灰度到 30% 的时候，监控里突然冒出来一堆 502。我第一反应是 Rollout 配置写错了，对着 YAML 查了半小时。后来才反应过来，是他们早先配的 HPA 阈值太低，灰度期间 Pod 副本数一变，Ingress 的 upstream 刷新跟不上，直接把流量打到了还没 Ready 的容器上。

那次我蹲在电脑前，一边改 HPA 的缩容冷却时间，一边把 Rollout 的 scaleDown 策略调成等待 60 秒，才算把流量稳住。最后大促当天，我们连续发了三个小版本，P99 延迟稳稳卡在 80 毫秒以内，客服那边一个关于“下单卡顿”的投诉都没接到。

关于选型，我现在的看法很直接：

* 如果你的业务只是个内部管理系统，或者 QPS 常年不过百，真的没必要折腾这套。K8s 原生的滚动更新足够你用了，上 Argo 只会徒增维护负担。

* 但如果是交易链路、支付核心这种哪怕停 1 秒都要出大事的场景，Argo Rollouts 或者 Flagger 是必选项。

我之前还纠结过要不要上 Flagger，后来发现它强依赖 Istio，而客户那边只是简单的 Nginx Ingress，硬上 Service Mesh 成本太高，最后还是选了 Argo。

最后想跟你们说一句，别光看文档里那几个 YAML 觉得简单。真到了线上，流量、自动扩缩容、还有那些陈年老旧的配置搅在一起，任何一环都能让你通宵。动手前，先在自己的测试集群里把自动回滚和流量激增的场景跑烂，比啥都强。