サポートコンソール開発者トライアルの開始お問い合わせ

1.4. プッシュアンドプルモデルを使用した Argo CD の導入

Push モデル 使用して、ハブクラスター上の Argo CD サーバーは、マネージドクラスターにアプリケーションリソースをデプロイします。Pull model (テクノロジープレビュー) の場合、アプリケーションリソースは、manifestWork を使用して、Propagation controller によってマネージドクラスターに伝播されます。

テクノロジープレビュー: プルモデルは、このリリースのサポートが限定されています。

どちらのモデルでも、同じ 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 アプリケーションがデプロイされる各マネージドクラスター上にすべての namespace を作成します。

    2. managed-by ラベルを各 namespace に追加します。Argo CD アプリケーションが複数の namespace にデプロイされている場合、各 namespace は Argo CD によって管理される必要があります。

      managed-by ラベルを使用した次の例を参照してください。 

    apiVersion: v1
kind: Namespace
metadata:
  name: mortgage2
  labels:
    argocd.argoproj.io/managed-by: openshift-gitops
    1. すべてのアプリケーション宛先 namespace をアプリケーションのリポジトリー内で宣言し、namespace に managed ラベルを含める必要があります。namespace を宣言する方法は、Additional resources を参照してください。

Argo CD Pull モデルを使用するには、次の要件を参照してください。

  • GitOps Operator はハブクラスターに、ターゲットのマネージドクラスターを openshift-gitops namespace にインストールする必要があります。
  • 必要なハブクラスター OpenShift Container Platform GitOps operator はバージョン 1.9.0 以降である必要があります。
  • 必要なマネージドクラスター OpenShift Container Platform GitOps Operator はハブクラスターと同じバージョンである必要があります。
  • マネージドクラスターの Argo CD アプリケーションテンプレートを伝播するには、ApplicationSet コントローラー が必要です。

  • すべてのマネージドクラスターは、ハブクラスター上の Argo CD サーバー namespace にクラスターシークレットを持っている必要があります。これは、ArgoCD アプリケーションセットコントローラーがマネージドクラスターの Argo CD アプリケーションテンプレートを伝播するために必要です。

    クラスターシークレットを作成するには、placement リソースへの参照が含まれる gitOpsCluster リソースを作成します。placement リソースは、プルモデルをサポートする必要があるすべてのマネージドクラスターを選択します。GitOps クラスターコントローラーが調整すると、Argo CD サーバーの namespace にマネージドクラスターのクラスターシークレットが作成されます。

1.4.2. アーキテクチャー

Push および Pull モデルの両方で、ハブクラスター上の Argo CD ApplicationSet コントローラー が調整して、ターゲットのマネージドクラスターごとにアプリケーションリソースを作成します。両方のモデルのアーキテクチャーに関する以下の情報を参照してください。

1.4.2.1. アーキテクチャープッシュモデル

  • Push モデルを使用すると、OpenShift Container Platform GitOps は、一元化されたハブクラスターからマネージドクラスターにリソースを 直接 適用します。
  • ハブクラスター上で実行されている Argo CD アプリケーションは、GitHub リポジトリーと通信し、マニフェストをマネージドクラスターに直接デプロイします。
  • Push モデルの実装には、マネージドクラスターの認証情報を持つハブクラスター上の Argo CD アプリケーションのみが含まれます。ハブクラスター上の Argo CD アプリケーションは、アプリケーションをマネージドクラスターにデプロイできます。
  • 重要: リソースアプリケーションを必要とする多数のマネージドクラスターでは、OpenShift Container Platform GitOps コントローラーのメモリーと CPU 使用率に負荷がかかる可能性があることを検討してください。リソース管理を最適化するには、リソースクォータまたは要求の設定 を参照してください。
  • デフォルトでは、apps.open-cluster-management.io/ocm-managed-cluster および apps.open-cluster-management.io/pull-to-ocm-managed-cluster を追加しない限り、アプリケーションのデプロイには Push モデルが使用されます。ApplicationSet のテンプレートセクションに cluster アノテーションを追加します。

1.4.2.2. アーキテクチャープルモデル (テクノロジープレビュー)

  • プルモデルでは、ハブクラスター内のコントローラーのストレスが軽減されるため、プッシュモデルと比較してスケーラビリティーが軽減されますが、より多くのリクエストとステータスレポートが必要になります。
  • プルモデルの場合、OpenShift Container Platform GitOps は、一元化されたハブクラスターからマネージドクラスターにリソースを直接適用 しません。Argo CD アプリケーションは、ハブクラスターからマネージドクラスターに伝播されます。
  • Pull モデルの実装では、OpenShift Cluster Manager の登録、配置、manifestWork API が適用され、ハブクラスターがハブクラスターとマネージドクラスター間の安全な通信チャネルを使用してリソースをデプロイできるようになります。
  • 各マネージドクラスターは個別に GitHub リポジトリーと通信してリソースマニフェストをローカルにデプロイするため、各マネージドクラスターに GitOps オペレーターをインストールして設定する必要があります。
  • Argo CD サーバーは、各ターゲットのマネージドクラスター上で実行されている必要があります。Argo CD アプリケーションリソースはマネージドクラスター上に複製され、ローカルの Argo CD サーバーによってデプロイされます。マネージドクラスター上の分散 Argo CD アプリケーションは、ハブクラスター上の単一の Argo CD ApplicationSet リソースを使用して作成されます。
  • マネージドクラスターは、ocm-managed-cluster アノテーションの値によって決定されます。
  • Pull モデルを正常に実装するには、Argo CD アプリケーションコントローラーは、ApplicationSet のテンプレートセクションにある argocd.argoproj.io/skip-reconcile アノテーションを持つプッシュモデルアプリケーションリソースを 無視 する必要があります。
  • Pull モデルの場合、マネージドクラスター上の Argo CD アプリケーションコントローラー が調整してアプリケーションをデプロイします。
  • ハブクラスター上の Pull モデル Resource sync controller は、各マネージドクラスター上の OpenShift Cluster Manager 検索 V2 コンポーネントに定期的にクエリーを実行し、各 Argo CD アプリケーションのリソースリストとエラーメッセージを取得します。
  • ハブクラスターの Aggregation controller はリソース同期コントローラーからのデータと、manifestWork からのステータス情報を使用して、クラスター全体から MulticlusterApplicationSetReport を作成および更新します。
  • デプロイメントのステータスはハブクラスターに収集されますが、すべての詳細情報が送信されるわけではありません。概要を提供するために、追加のステータス更新が定期的に収集されます。ステータスのフィードバックはリアルタイムではなく、各マネージドクラスターの GitOps operator は Git リポジトリーと通信する必要があるため、複数のリクエストが発生します。

1.4.3. ApplicationSet カスタムリソースの作成

Argo CD ApplicationSet リソースは、マネージドクラスターのリストを取得するために使用されるジェネレーターフィールド内の placement リソースを含むプッシュまたはプルモデルを使用して、マネージドクラスターにアプリケーションをデプロイするために使用されます。

  1. プルモデルの場合、次の例に示すように、アプリケーションの宛先をデフォルトのローカル Kubernetes サーバーに設定します。アプリケーションは、マネージドクラスター上のアプリケーションコントローラーによってローカルにデプロイされます。

  2. 以下の ApplicationSet YAML の例に示されるように、デフォルトの Push モデルを上書きするために必要なアノテーションを追加します。これは、テンプレートアノテーションで 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
    Push モデルリソースを無視するには、argocd.argoproj.io/skip-reconcile が必要です。
    3
    apps.open-cluster-management.io/pull-to-ocm-managed-cluster: "true" も Pull モデルに必要です。

1.4.4. MulticlusterApplicationSetReport

  • Pull モデルの場合、MulticlusterApplicationSetReport はマネージドクラスター全体からアプリケーションステータスを集約します。
  • レポートには、リソースのリストと、各マネージドクラスターからのアプリケーションの全体的なステータスが含まれます。
  • Argo CD ApplicationSet リソースごとに個別のレポートリソースが作成されます。レポートは ApplicationSet と同じ namespace に作成されます。

  • レポートには次の項目が含まれます。

    1. Argo CD アプリケーションのリソースのリスト
    2. 各 Argo CD アプリケーションの全体的な同期およびヘルスステータス
    3. 全体的なステータスが out of sync、または unhealthy 各クラスターのエラーメッセージ
    4. 管理対象クラスタのすべての状態を示すサマリーステータス
  • Resource sync controller と Aggregation controller は両方とも 10 秒ごとに実行され、レポートを作成します。

  • 次の出力例に示すように、2 つのコントローラーと 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"

Note: リソースがデプロイに失敗した場合、リソースはリソース一覧に含まれません。詳細は、エラーメッセージを参照してください。

1.4.5. 関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.