解读

在国内云原生面试中，面试官提出“回滚速度”对比，核心想验证两点：

1. 你是否理解容器级别回滚的真实含义——即把业务 Pod 重新调度到旧版本镜像并重新创建容器的全过程耗时；
2. 你是否能区分 Flagger（基于 Gloo/Contour/Nginx/Traefik 等流量网关）与 Argo Rollouts（自带 TrafficManager）在流量切换策略、Pod 生命周期钩子、镜像预热、缩容顺序上的实现差异，从而推导出谁能在秒级完成回滚，谁需要数十秒甚至分钟级。
   回答时必须给出可量化的耗时区间与可落地的优化手段，否则会被认为“纸上谈兵”。

知识点

1. 回滚路径

   • Flagger：由 Canary 对象监听 Helm/Kustomize 版本变更，回滚时直接改回旧版本 Helm revision，依赖原 Deployment 的 rollout 策略（maxUnavailable、maxSurge）。
   • Argo Rollouts：由 Rollout CR 自己控制 ReplicaSet，回滚时把 stableRS 指针切回上一版本 RS，跳过 Deployment 层，直接操作 RS。

2. 流量切换方式

   • Flagger 默认做权重回退（0%→100%），需等 Ingress 控制器把规则同步到 Envoy/Nginx；一次 full rollback 需两次变更（canary weight 0 + 回退 revision）。
   • Argo Rollouts 支持即时流量切换（setWeight: 100 直接切到 stable），一次 patch 即可把 VirtualService/TraefikService 指向旧版本。

3. Pod 终止与创建并发度

   • Flagger 仍受 Deployment 的滚动更新策略约束，默认 maxUnavailable=25%，串行删除；若集群节点跨可用区，镜像拉取+容器启动平均 15–25 s。
   • Argo Rollouts 可设置scaleDownDelaySeconds: 0、fastRollback: true，旧 Pod 立即删除，新 Pod 提前预热（previewReplicaCount），并行启动可把容器创建时间压到 5–8 s。

4. 镜像加速
   国内常用阿里云 ACR 镜像缓存或Dragonfly P2P，两者都能把镜像拉取耗时从 30 s 降到 5 s 以内；但 Argo Rollouts 支持提前拉取 preview 副本，回滚时零拉取，Flagger 无此机制。

5. Hook 与就绪探针
   Flagger 回滚时若旧版本 Deployment 的 readinessProbe 失败，会重试 3 次×10 s，导致额外 30 s 延迟；Argo Rollouts 的rollbackWindow可跳过探针直接判定 Ready，节省 20–30 s。

答案

在默认配置下，Argo Rollouts 回滚速度显著快于 Flagger：

• Argo Rollouts：从触发回滚到容器级别全部就绪平均 8–12 s（镜像已预热、流量一次切换、Pod 并行创建）。
• Flagger：需两次流量权重变更 + Deployment 串行滚动，镜像重新拉取，平均 35–50 s；若跨可用区或镜像较大，可拖到 60 s+。

优化后差距可缩小但无法逆转：

• Flagger 打开kubectl rollout undo直接回滚、maxUnavailable=50%、提前做ACR 预热，可压缩到 20–25 s；
• Argo Rollouts 继续启用fastRollback、scaleDownDelay=0、previewReplicaCount=100%，可稳定保持 <10 s。

因此，在容器级别回滚速度这一单项指标上，Argo Rollouts 比 Flagger 快 2–4 倍，且稳定性更高。

拓展思考

1. 如果公司已经统一使用Istio + Flagger，想达到 Argo Rollouts 的秒级回滚，可落地三步：

   • 把 Deployment 改成两套独立 Deployment（蓝绿），Flagger 只做流量切换，Pod 预跑；
   • 在 CI 阶段并行推送镜像到缓存节点，回滚时强制 nodeAffinity 调度到缓存节点；
   • 关闭 readinessProbe 的失败重启阈值，改用livenessProbe 兜底，可把回滚时间压到 15 s 左右，但牺牲部分安全性。

2. 在金融场景（监管要求可审计），Argo Rollouts 的rollbackWindow与RevisionHistoryLimit需配合审计日志导出到 SLS/ELK，否则秒级回滚虽快，却可能丢失变更证据。

3. 未来Kubernetes 1.30 的 In-Place Update（原地重启容器）GA 后，两者都可把镜像替换时间降到 2 s 内，但前提是镜像层复用率 >90%；国内镜像仓库建议开启按需加载（Stargz/CRI-O lazy-pull），才能把理论速度变成生产速度。