1.4. 使用 Push 和 Pull 模型部署 Argo CD

使用 Push 模型，hub 集群上的 Argo CD 服务器会在受管集群中部署应用程序资源。对于 Pull 模型，应用程序资源由 Propagation 控制器传播到受管集群，使用 manifestWork 。

对于这两种模型，相同的 ApplicationSet CRD 用于将应用程序部署到受管集群。

需要的访问权限：集群管理员

1.4.1. 先决条件

查看 Argo CD Pull 模型的以下先决条件：

重要：

如果您的 openshift-gitops-ArgoCD-application-controller 服务帐户 没有分配 为集群管理员，则 GitOps 应用程序控制器可能无法部署资源。应用程序状态可能会发送类似以下错误的错误：

cannot create resource "services" in API group "" in the namespace
"mortgage",deployments.apps is forbidden: User
"system:serviceaccount:openshift-gitops:openshift-gitops-Argo CD-application-controller"

在受管集群中安装 OpenShift Gitops Operator 后，您必须在同一受管集群中创建 ClusterRoleBinding 集群管理员特权。

要将 ClusterRoleBinding 集群管理员特权添加到受管集群，请参阅以下 YAML 示例：

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: argo-admin
subjects:
  - kind: ServiceAccount
    name: openshift-gitops-argocd-application-controller
    namespace: openshift-gitops
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

如果您不是集群管理员，需要解决这个问题，请完成以下步骤：
1. 在部署 Argo CD 应用程序的每个受管集群中创建所有命名空间。
2. 将 managed-by 标签添加到每个命名空间。如果 Argo CD 应用程序部署到多个命名空间，则每个命名空间都应该由 Argo CD 管理。
  请参见以下带有 managed-by 标签的示例：
```
apiVersion: v1
kind: Namespace
metadata:
  name: mortgage2
  labels:
    argocd.argoproj.io/managed-by: openshift-gitops
```
1. 您必须在存储库中声明应用程序的所有应用程序目的地命名空间，并在命名空间中包含 managed-by 标签。请参阅附加资源以了解如何声明命名空间。

请参阅以下要求来使用 Argo CD Pull 模型：

GitOps Operator 必须安装到 hub 集群和 openshift-gitops 命名空间中的目标受管集群。
所需的 hub 集群 OpenShift Container Platform GitOps operator 必须是版本 1.9.0 或更高版本。
所需的受管集群 OpenShift Container Platform GitOps Operator 必须与 hub 集群相同。
您需要 ApplicationSet 控制器 为受管集群传播 Argo CD 应用程序模板。
每个受管集群都必须在 hub 集群上的 Argo CD 服务器命名空间中有一个集群 secret，而 ArgoCD 应用程序设置控制器需要该 secret 来为受管集群传播 Argo CD 应用程序模板。
要创建集群 secret，请创建一个 gitOpsCluster 资源，其中包含对 placement 资源的引用。placement 资源选择所有需要支持 Pull 模型的受管集群。当 GitOps 集群控制器协调时，它会在 Argo CD 服务器命名空间中为受管集群创建集群 secret。

1.4.2. 架构

对于 Push 和 Pull 模型，hub 集群上的 Argo CD ApplicationSet 控制器会协调为每个目标受管集群创建应用程序资源。有关这两种模型的架构，请查看以下信息：

1.4.2.1. 架构推送模型

使用 Push 模型时，OpenShift Container Platform GitOps 将资源直接从集中 hub 集群应用到受管集群。
在 hub 集群上运行的 Argo CD 应用程序与 GitHub 存储库通信，并将清单直接部署到受管集群。
推送模型实现仅包含 hub 集群上的 Argo CD 应用程序，其中包含受管集群的凭证。hub 集群上的 Argo CD 应用程序可将应用程序部署到受管集群。
重要： 对于需要资源应用程序的大量受管集群，请考虑 OpenShift GitOps GitOps 控制器内存和 CPU 用量的潜在压力。要优化资源管理，请参阅 Red Hat OpenShift GitOps 文档中的配置资源配额或请求。
默认情况下，Push 模型用于部署应用程序，除非您将 apps.open-cluster-management.io/ocm-managed-cluster 和 apps.open-cluster-management.io/pull-to-ocm-managed-cluster 注解添加到 ApplicationSet 的 template 部分。

1.4.2.2. 架构 Pull 模型

拉取模型可以通过减少 hub 集群中的控制器的压力与推送模型提供可扩展性，但需要更多请求和状态报告。
使用 Pull 模型时，OpenShift Container Platform GitOps 不会将资源直接从集中 hub 集群应用到受管集群。Argo CD Application 从 hub 集群传播到受管集群。
拉取模型实现应用 OpenShift Cluster Manager 注册、放置和 manifestWork API，以便 hub 集群和受管集群之间可以使用安全通信频道来部署资源。
每个受管集群都单独与 GitHub 存储库通信，以便在本地部署资源清单，因此您必须在每个受管集群中安装和配置 GitOps operator。
Argo CD 服务器必须在每个目标受管集群中运行。Argo CD 应用程序资源在受管集群中复制，然后由本地 Argo CD 服务器部署。受管集群中的分布式 Argo CD 应用程序使用 hub 集群上的单个 Argo CD ApplicationSet 资源创建。
受管集群由 ocm-managed-cluster 注解的值决定。
要成功实现 Pull 模型，Argo CD 应用程序控制器必须在 ApplicationSet 的 template 部分中忽略带有 argocd.argoproj.io/skip-reconcile 注解的 Push 模型应用程序资源。
对于 Pull 模型，受管集群中的 Argo CD Application 控制器会 协调以部署应用程序。
hub 集群上的 Pull model Resource sync 控制器 会定期查询 OpenShift Cluster Manager 在每个受管集群上搜索 V2 组件，以检索每个 Argo CD 应用程序的资源列表和错误消息。
hub 集群上的 聚合控制器 使用资源同步控制器的数据以及 manifestWork 的状态信息，从集群间创建和更新 MulticlusterApplicationSetReport。
部署的状态被收集回 hub 集群，但不会传输所有详细信息。定期提取其他状态更新以提供概述。状态反馈不是实时的，每个受管集群 GitOps operator 需要与 Git 存储库通信，这会导致多个请求。

1.4.3. 创建 ApplicationSet 自定义资源

Argo CD ApplicationSet 资源用于使用用于获取受管集群列表的 Push 或 Pull 模型在受管集群中部署应用程序。

对于 Pull 模型，将应用程序的目的地设置为默认本地 Kubernetes 服务器，如下例所示。应用程序由受管集群上的应用程序控制器在本地部署。

添加覆盖默认 Push 模型所需的注解，如下例所示 ApplicationSet YAML，该 YAML 使用带有模板注解的 Pull 模型：

apiVersion: argoproj.io/v1alpha1
kind: `ApplicationSet`
metadata:
  name: guestbook-allclusters-app-set
  namespace: openshift-gitops
spec:
  generators:
  - clusterDecisionResource:
      configMapRef: ocm-placement-generator
      labelSelector:
        matchLabels:
          cluster.open-cluster-management.io/placement: aws-app-placement
      requeueAfterSeconds: 30
  template:
    metadata:
      annotations:
        apps.open-cluster-management.io/ocm-managed-cluster: '{{name}}'1
        apps.open-cluster-management.io/ocm-managed-cluster-app-namespace: openshift-gitops
        argocd.argoproj.io/skip-reconcile: "true" 2
      labels:
        apps.open-cluster-management.io/pull-to-ocm-managed-cluster: "true" 3
      name: '{{name}}-guestbook-app'
    spec:
      destination:
        namespace: guestbook
        server: https://kubernetes.default.svc
      project: default
      sources: [
      {
        repoURL: https://github.com/argoproj/argocd-example-apps.git
        targetRevision: main
        path: guestbook
         }
      ]
      syncPolicy:
        automated: {}
        syncOptions:
        - CreateNamespace=true

1: Pull 模型需要 apps.open-cluster-management.io/ocm-managed-cluster。
2: argocd.argoproj.io/skip-reconcile 需要忽略 Push 模型资源。
3: Pull 模型还需要 apps.open-cluster-management.io/pull-to-ocm-managed-cluster: "true "。

1.4.4. MulticlusterApplicationSetReport

对于 Pull 模型，MulticlusterApplicationSetReport 聚合受管集群中的应用程序状态。
该报告包括资源列表以及每个受管集群的应用程序的整体状态。
为每个 Argo CD ApplicationSet 资源创建一个单独的报告资源。该报告与 ApplicationSet 在同一命名空间中创建。
该报告包括以下项目：
1. Argo CD 应用程序的资源列表
2. 每个 Argo CD 应用程序的整体同步和健康状况
3. 每个集群的出错信息，其中整个状态为 sync 或 unhealthy
4. 受管集群的所有状态概述状态
资源同步控制器和聚合控制器每 10 秒运行一次，以创建报告。

两个控制器以及 Propagation 控制器，在同一 multicluster-integrations pod 中的独立容器中运行，如下例所示：

NAMESPACE               NAME                                       READY   STATUS
open-cluster-management multicluster-integrations-7c46498d9-fqbq4  3/3     Running

以下是 guestbook 应用程序的 MulticlusterApplicationSetReport YAML 文件示例：

apiVersion: apps.open-cluster-management.io/v1alpha1
kind: MulticlusterApplicationSetReport
metadata:
  labels:
    apps.open-cluster-management.io/hosting-applicationset: openshift-gitops.guestbook-allclusters-app-set
  name: guestbook-allclusters-app-set
  namespace: openshift-gitops
statuses:
  clusterConditions:
  - cluster: cluster1
    conditions:
    - message: 'Failed sync attempt: one or more objects failed to apply, reason: services is forbidden: User "system:serviceaccount:openshift-gitops:openshift-gitops-Argo CD-application-controller" cannot create resource "services" in API group "" in the namespace "guestbook",deployments.apps is forbidden: User <name> cannot create resource "deployments" in API group "apps" in the namespace "guestboo...'
      type: SyncError
    healthStatus: Missing
    syncStatus: OutOfSync
  - cluster: pcluster1
    healthStatus: Progressing
    syncStatus: Synced
  - cluster: pcluster2
    healthStatus: Progressing
    syncStatus: Synced
  summary:
    clusters: "3"
    healthy: "0"
    inProgress: "2"
    notHealthy: "3"
    notSynced: "1"
    synced: "2"

注：如果资源无法部署，则资源不会包含在资源列表中。如需更多信息，请参阅错误消息。

1.4.5. 其他资源

请参阅 Red Hat OpenShift GitOps 文档中的使用集群配置部署应用程序来配置 OpenShift 集群。
请参阅 Red Hat OpenShift GitOps 文档中的设置 Argo CD 实例。

1.4. 使用 Push 和 Pull 模型部署 Argo CD

1.4.1. 先决条件

1.4.2. 架构

1.4.2.1. 架构推送模型

1.4.2.2. 架构 Pull 模型

1.4.3. 创建 ApplicationSet 自定义资源

1.4.4. MulticlusterApplicationSetReport

1.4.5. 其他资源

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links