如何实现Argo Rollout的部署依赖排序：让服务A等待服务B完成部署后再执行？

这个问题在monorepo的渐进式交付场景里挺常见的，我来分享几个实用的方案，帮你确保API部署完成后再推进Web UI的发布：

方法1：利用Argo Rollouts的分析阶段（Analysis Phase）等待API就绪 #

你可以在Web UI的Rollout资源中添加一个分析阶段，这个阶段会在开始渐进式发布（比如蓝绿、金丝雀流量切分）之前，先检查API服务是否已经部署完成且状态正常。

具体来说，你可以创建一个分析模板，用Kubernetes Job来执行API的健康检查，只有当检查通过时，Web的Rollout才会继续执行。

示例Rollout配置片段：

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web-ui-rollout
spec:
  strategy:
    canary:
      canaryService: web-ui-canary
      stableService: web-ui-stable
      steps:
      - setWeight: 20
      # 在流量切分前先等待API就绪
      - analysis:
          templates:
          - name: check-api-readiness
          args:
          - name: api-service
            value: api-service.default.svc.cluster.local
  # ... 其他Rollout配置

对应的分析模板：

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: check-api-readiness
spec:
  args:
  - name: api-service
  metrics:
  - name: api-health-check
    interval: 10s
    successCondition: result.status == 200
    failureLimit: 3
    provider:
      job:
        spec:
          template:
            spec:
              containers:
              - name: health-check
                image: curlimages/curl:latest
                command: ["curl", "-s", "-o", "/dev/null", "-w", "%{http_code}", "http://{{args.api-service}}/health"]
              restartPolicy: OnFailure

这个方法的优势是把依赖检查直接集成在Rollout的生命周期里，不需要额外的编排工具。

方法2：用Argo Workflows编排部署顺序 #

如果你的服务依赖关系更复杂，或者需要批量控制多个服务的部署，Argo Workflows是更合适的选择。你可以定义一个Workflow，先部署API的Rollout，等待它完全就绪后，再启动Web UI的部署。

示例Workflow配置：

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: deploy-monorepo-
spec:
  entrypoint: deploy-services
  templates:
  - name: deploy-services
    dag:
      tasks:
      - name: deploy-api
        template: wait-for-rollout
        arguments:
          parameters: [{name: rollout-name, value: api-rollout}]
      - name: deploy-web-ui
        template: wait-for-rollout
        arguments:
          parameters: [{name: rollout-name, value: web-ui-rollout}]
        dependencies: [deploy-api]
  - name: wait-for-rollout
    inputs:
      parameters:
      - name: rollout-name
    script:
      image: argoproj/argo-rollouts:latest
      command: [sh]
      source: |
        # 等待Rollout进入可用状态
        kubectl argo rollouts wait rollout/{{inputs.parameters.rollout-name}} --for=condition=available
        # 确认Rollout发布完成
        kubectl argo rollouts status rollout/{{inputs.parameters.rollout-name}}

Workflow会严格按照依赖顺序执行，先完成API的部署检查，再触发Web UI的部署，非常适合monorepo的多服务协同发布场景。

方法3：在CI流程中控制部署触发顺序 #

如果你的CI工具（比如GitHub Actions、GitLab CI）支持脚本控制，也可以直接在CI阶段处理依赖逻辑：先触发API的部署，轮询检查API的Rollout状态，确认完成后再触发Web UI的部署。

示例GitHub Actions脚本片段：

jobs:
  deploy-api:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy API
        run: kubectl apply -k ./k8s/api
      - name: Wait for API Rollout to complete
        run: |
          kubectl argo rollouts wait rollout/api-rollout --for=condition=available --timeout=5m

  deploy-web-ui:
    runs-on: ubuntu-latest
    needs: deploy-api
    steps:
      - name: Deploy Web UI
        run: kubectl apply -k ./k8s/web-ui
      - name: Wait for Web UI Rollout to complete
        run: |
          kubectl argo rollouts wait rollout/web-ui-rollout --for=condition=available --timeout=5m

这个方法最直接，利用CI的任务依赖机制就能实现顺序部署，不需要额外修改Kubernetes资源配置。

内容的提问来源于stack exchange，提问作者Tim Scriv