如何用ArgoCD管理Pod依赖？需确保Pod A就绪后再部署Pod B

如果需要确保Pod A完全就绪后再部署Pod B，ArgoCD没有像Flux那样直接的工作负载依赖特性，但可以通过以下几种方式实现：

1. 应用间依赖配置 #

将Pod A和Pod B分别封装为独立的ArgoCD Application，然后在Pod B对应的Application中配置依赖，指定等待Pod A的Application完成同步且状态健康后再部署。

示例配置（Pod B的Application YAML）：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: app-b
spec:
  destination:
    namespace: default
    server: https://kubernetes.default.svc
  project: default
  source:
    repoURL: https://your-repo-url.git
    path: app-b
    targetRevision: main
  dependencies:
    - name: app-a
      namespace: argocd
      waitForSync: true

这里waitForSync: true会让ArgoCD等待app-a完成同步（即Pod A所在的资源都处于就绪状态）后，才开始同步app-b。

2. 使用Kubernetes Init容器（同应用内依赖） #

如果Pod A和Pod B属于同一个ArgoCD应用（比如同一个Deployment/StatefulSet或同一组资源），可以给Pod B添加Init容器，在容器启动前检查Pod A的就绪状态，只有检查通过后才启动Pod B的主容器。

示例Init容器配置（Pod B的Pod模板）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-b
spec:
  replicas: 1
  template:
    spec:
      initContainers:
        - name: wait-for-app-a
          image: bitnami/kubectl:latest
          command:
            - sh
            - -c
            - |
              until kubectl get pods -l app=app-a -o jsonpath='{.items[*].status.conditions[?(@.type=="Ready")].status}' | grep -q "True"; do
                echo "Waiting for app-a to be ready..."
                sleep 5
              done
      containers:
        - name: app-b-container
          image: your-app-b-image:latest

注意：需要确保该Init容器有足够的Kubernetes API权限（可以通过Role/RoleBinding配置）来查询Pod状态。

3. 利用ArgoCD PreSync钩子 #

给Pod B的部署资源添加PreSync钩子，钩子会在同步Pod B资源之前执行一个检查任务，确认Pod A已经就绪，检查通过后才继续部署流程。

示例钩子配置（添加到Pod B的Deployment注解中）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-b
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  # ... 其他配置

同时需要定义一个执行检查的Job（作为钩子的一部分）：

apiVersion: batch/v1
kind: Job
metadata:
  name: wait-for-app-a
  annotations:
    argocd.argoproj.io/hook: PreSync
    argocd.argoproj.io/hook-delete-policy: HookSucceeded
spec:
  template:
    spec:
      containers:
        - name: check-app-a
          image: bitnami/kubectl:latest
          command:
            - sh
            - -c
            - |
              until kubectl get pods -l app=app-a -o jsonpath='{.items[*].status.conditions[?(@.type=="Ready")].status}' | grep -q "True"; do
                echo "Waiting for app-a to be ready..."
                sleep 5
              done
      restartPolicy: OnFailure

4. 自定义健康检查规则 #

如果Pod A对应的服务有特定的就绪条件，可以自定义ArgoCD的健康检查规则，确保ArgoCD将Pod A标记为"健康"后，再处理依赖它的应用。

你可以在ArgoCD的argocd-cm ConfigMap中添加自定义健康检查规则，比如：

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  resource.customizations: |
    apps/v1/Deployment:
      health.lua: |
        function health(obj)
          if obj.status.availableReplicas == obj.spec.replicas then
            return {status="Healthy", message="Deployment is available"}
          end
          return {status="Progressing", message="Waiting for replicas to be available"}
        end

之后在应用间依赖中，ArgoCD会根据自定义规则判断Pod A所在Deployment的健康状态，只有状态为Healthy时才会部署Pod B。

内容的提问来源于stack exchange，提问作者Matthias M