通过ArgoCD部署App-of-Apps至远程集群遇CRD报错求助

你的错误核心是App-of-Apps的顶层Application资源被错误配置为部署到开发集群，而argoproj.io/Application CRD仅安装在控制集群（ArgoCD所在集群），开发集群中不存在该CRD，因此同步时触发资源找不到的错误。

另外你调整命名空间导致控制集群部署混乱，是因为误改了控制集群中ArgoCD组件依赖的命名空间配置，破坏了控制面的正常运行逻辑。

1. 修正顶层App-of-Apps配置 #

将core-services-development的Application配置修改为部署在控制集群，而非开发集群：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: core-services-development
  namespace: argocd  # 取消注释，确保部署在控制集群的argocd命名空间
spec:
  project: default
  destination:
    name: in-cluster  # 改为控制集群的集群名称，通常是in-cluster
  source:
    repoURL: git@gitlab.com:REDACTED/gitops/argocd.git
    path: environments/development/apps/core-services
    targetRevision: main
  syncPolicy:
    automated:
      allowEmpty: true
      prune: true
      selfHeal: false

• destination.name: in-cluster：指定该Application资源部署在ArgoCD所在的控制集群，ArgoCD会监听这个集群的argocd命名空间下的Application资源，进而管理子应用。
• 恢复namespace: argocd：ArgoCD默认仅监听自身所在的argocd命名空间内的Application资源，确保顶层App-of-Apps被ArgoCD正确识别。

2. 确认子应用配置的正确性 #

你的external-dns子Application配置是符合预期的：

• 它的destination指向开发集群japasp-development-cluster，子应用需要部署到开发集群的逻辑没问题。
• 子应用的spec.source指向Helm chart、通过插件注入敏感信息、同步选项CreateNamespace=true的配置均合理。

3. 恢复控制集群的命名空间配置 #

如果你之前修改了控制集群的argocd命名空间或相关资源，需要恢复到修改前的状态：

• 确保控制集群的argocd命名空间存在，且ArgoCD的所有组件（argocd-server、argocd-application-controller等）都运行在该命名空间。
• 若误删除或修改了命名空间的标签、注解，需重新添加（可参考ArgoCD初始安装时的命名空间配置）。

4. 重新同步验证 #

1. 在控制集群中应用修正后的core-services-development配置：

kubectl apply -f core-services-development.yaml -n argocd

2. 登录ArgoCD UI或使用CLI触发同步：

argocd app sync core-services-development

此时ArgoCD会在控制集群中创建所有子Application资源（如external-dns），并将这些子应用的业务资源同步到开发集群，不会再触发CRD缺失的错误。

• 控制集群：仅需部署ArgoCD组件及用于管理应用的Application资源，必须存在argoproj.io/Application CRD。
• 目标集群（开发集群）：无需安装ArgoCD组件或其CRD，仅需确保控制集群的ArgoCD能通过K8s API访问目标集群即可。
• App-of-Apps模式的核心逻辑是：控制集群中的顶层Application指向Git仓库中存放的子Application清单，ArgoCD读取这些子Application并将其业务资源同步到目标集群。

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