Argo CD 多源应用怎样改变配置组合方式

Argo CD 多源应用改变的不是“一个 Application 管多少个应用”，而是“一个 Application 的清单可以由哪些来源共同组成”。官方文档中的 spec.sources 会让每个来源独立生成资源，再把结果合并后交给同一个 Application 管理。这样，Helm 图表可以保持上游形态，团队自己的 Git 仓库只维护环境值或少量覆盖资源。

官方地址：https://argo-cd.readthedocs.io/en/latest/user-guide/multiple_sources/

从 source 到 sources，配置组合从哪里发生

单源 Application 把仓库、路径或图表写在 spec.source 中。多源 Application 改用 spec.sources 数组，Argo CD 会先分别为每个来源生成清单，再把清单合并为同一个应用的资源集合。只要清单里出现了 sources，source 字段就不再参与配置。

这里的“组合”不是把两个仓库目录简单拼接，也不是把多个业务应用变成一个部署单元。它更接近“一个应用的图表、环境配置和受控覆盖共同描述最终资源”。如果不同来源生成了相同的 Group、Kind、Name、Namespace 资源，后出现的来源拥有更高优先级，Argo CD 仍会同步，但会产生 RepeatedResourceWarning。

用 ref 和 $values 拆开 Helm 图表与环境配置

最实用的变化是：Helm 图表不必和团队自己的 values 文件放在同一个仓库。图表来源继续指向公开或内部 Helm 仓库，第二个来源指向 Git 配置仓库，并设置一个 ref 名称。图表的 valueFiles 再用 $values/ 引用这个仓库的根目录。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: billing-api
  namespace: argocd
spec:
  project: default
  sources:
    - repoURL: https://charts.example.com
      chart: billing-api
      targetRevision: 1.8.0
      helm:
        valueFiles:
          - $values/envs/prod/billing.yaml
        # 图表来源只声明如何读取外部配置，不复制 values 文件
    - repoURL: https://git.example.com/platform/config.git
      targetRevision: main
      ref: values
      # ref 把这个 Git 来源映射成可供 $values 使用的根目录
  destination:
    server: https://kubernetes.default.svc
    namespace: billing
    # 目标集群和命名空间仍属于同一个 Application 的部署边界

$values 只能出现在 value file 路径的开头，后面的路径相对于被引用仓库的根目录。设置了 ref 的来源不能同时设置 chart；如果该来源还设置了 path，Argo CD 还会尝试从这个 Git 路径生成资源，否则它只作为 values 文件来源。

同名资源覆盖与 Helm 参数优先级不是一回事

多源配置里有两套容易混淆的规则。第一套是 Kubernetes 资源层面的来源顺序：相同资源由后面的来源生成时，后面的资源覆盖前面的资源，并伴随重复资源警告。这适合做明确、少量的覆盖，但不应该把大量资源的优先级藏在数组顺序里。

第二套是 Helm 值注入顺序。官方文档给出的优先级从低到高是：helm.repository values.yaml、valueFiles、values、valuesObject、parameters。同一组 valueFiles 中，后列出的文件优先级更高。因此，环境文件可以覆盖公共文件，但应把顺序写得直观，并把最终负责修改某个键的仓库记录清楚。

何时应该停用多源思路

多源最适合一个应用需要“上游图表加本地配置”或“主清单加少量覆盖”的场景。官方文档特别提醒，不要把它当成通用的应用分组器；如果 sources 已经超过两三个来源，通常应该重新检查职责是否混在一起。

如果目标是根据集群、目录或环境批量生成一组 Application，应优先考虑 ApplicationSet；如果目标是让一个入口管理多个相互独立的应用，可以考虑 app-of-apps。多源应用的价值在于拆开同一应用的配置责任，而不是扩大单个 Application 的管理半径。

创建时也要注意命令行边界：多源应用不能只靠 --repo、--path 这类单源参数创建，应把完整 Application manifest 交给 argocd app create --file，参数化流水线则可以把渲染后的 manifest 从标准输入传入。使用完整 manifest 时，与来源相关的单源 flags 会被忽略。

常见问题

配置了 sources 后还要保留 source 吗？

不需要依赖它。官方行为是优先使用 sources，单数 source 会被忽略；为了避免误解，建议只保留实际使用的字段。

重复资源警告会阻止同步吗？

官方文档说明后出现的资源会取得优先级并继续同步，同时生成 RepeatedResourceWarning。这不是可以无限覆盖的理由，应该把重复资源限制在有明确意图的少数对象。

多源能否替代 ApplicationSet？

不能直接替代。多源解决一个 Application 的多个配置来源，ApplicationSet 解决批量生成和管理多个 Application，二者的边界不同。

Argo CD 多源应用真正改变的是配置组合方式：图表、环境值和局部覆盖可以保持各自的仓库边界，再由一个 Application 组合结果。只要控制来源数量、明确覆盖顺序，并把不相关应用交给更合适的编排模式，sources 才会带来可维护性，而不是新的隐藏依赖。