18.2. ZTP 用のハブクラスターの準備


切断された環境で RHACM を使用するには、OpenShift Container Platform リリースイメージと必要な Operator イメージを含む Operator Lifecycle Manager (OLM) カタログをミラーリングするミラーレジストリーを作成します。OLM は Operator およびそれらの依存関係をクラスターで管理し、インストールし、アップグレードします。切断されたミラーホストを使用して、ベアメタルホストのプロビジョニングに使用される RHCOS ISO および RootFS ディスクイメージを提供することもできます。

18.2.1. Telco RAN DU 4.14 検証済みソフトウェアコンポーネント

Red Hat Telco RAN DU 4.14 ソリューションは、次に示す OpenShift Container Platform のマネージドクラスターおよびハブクラスター用の Red Hat ソフトウェア製品を使用して検証されています。

表18.2 Telco RAN DU マネージドクラスターの検証済みソフトウェアコンポーネント
コンポーネントソフトウェアバージョン

マネージドクラスターのバージョン

4.14

Cluster Logging Operator

5.7

Local Storage Operator

4.14

PTP Operator

4.14

SRIOV Operator

4.14

Node Tuning Operator

4.14

Logging Operator

4.14

SRIOV-FEC Operator

2.7

表18.3 ハブクラスターの検証済みソフトウェアコンポーネント
コンポーネントソフトウェアバージョン

ハブクラスターのバージョン

4.14

GitOps ZTP プラグイン

4.14

Red Hat Advanced Cluster Management (RHACM)

2.9、2.10

Red Hat OpenShift GitOps

1.9、1.10

Topology Aware Lifecycle Manager (TALM)

4.14

18.2.2. GitOps ZTP で推奨されるハブクラスター仕様とマネージドクラスターの制限

GitOps Zero Touch Provisioning (ZTP) を使用すると、地理的に分散した地域やネットワークにある数千のクラスターを管理できます。Red Hat Performance and Scale ラボは、ラボ環境内の単一の Red Hat Advanced Cluster Management (RHACM) ハブクラスターから、より小さな DU プロファイルを使用して 3,500 個の仮想シングルノード OpenShift クラスター作成および管理することに成功しました。

実際の状況では、管理できるクラスター数のスケーリング制限は、ハブクラスターに影響を与えるさまざまな要因によって異なります。以下に例を示します。

ハブクラスターのリソース
利用可能なハブクラスターのホストリソース (CPU、メモリー、ストレージ) は、ハブクラスターが管理できるクラスターの数を決定する重要な要素です。ハブクラスターに割り当てられるリソースが多いほど、対応できるマネージドクラスターの数も多くなります。
ハブクラスターストレージ
ハブクラスターホストのストレージ IOPS 評価と、ハブクラスターホストが NVMe ストレージを使用するかどうかは、ハブクラスターのパフォーマンスと管理できるクラスターの数に影響を与える可能性があります。
ネットワーク帯域幅と遅延
ハブクラスターとマネージドクラスター間のネットワーク接続が遅い、大きく遅延する場合、ハブクラスターによる複数クラスターの管理方法に影響を与える可能性があります。
マネージドクラスターのサイズと複雑さ
マネージドクラスターのサイズと複雑さも、ハブクラスターの容量に影響します。より多くのノード、namespace、リソースを備えた大規模なマネージドクラスターには、追加の処理リソースと管理リソースが必要です。同様に、RAN DU プロファイルや多様なワークロードなどの複雑な設定を持つクラスターは、ハブクラスターからより多くのリソースを必要とする可能性があります。
管理ポリシーの数
ハブクラスターによって管理されるポリシーの数は、それらのポリシーにバインドされているマネージドクラスターの数に対してスケーリングされており、これらは管理できるクラスターの数を決定する重要な要素です。
ワークロードのモニタリングと管理
RHACM は、マネージドクラスターを継続的にモニタリングおよび管理します。ハブクラスター上で実行されるモニタリングおよび管理ワークロードの数と複雑さは、ハブクラスターの容量に影響を与える可能性があります。集中的なモニタリングや頻繁な調整操作には追加のリソースが必要となる場合があり、管理可能なクラスターの数が制限される可能性があります。
RHACM のバージョンと設定
RHACM のバージョンが異なると、パフォーマンス特性やリソース要件も異なる場合があります。さらに、同時リコンシリエーションの数やヘルスチェックの頻度などの RHACM 設定は、ハブクラスターのマネージドクラスター容量に影響を与える可能性があります。

次の代表的な設定とネットワーク仕様を使用して、独自の Hub クラスターとネットワーク仕様を開発します。

重要

次のガイドラインは、社内のラボのベンチマークテストのみに基づいており、完全なベアメタルホストの仕様を表すものではありません。

表18.4 代表的な 3 ノードハブクラスターマシンの仕様
要件説明

OpenShift Container Platform

バージョン 4.13

RHACM

バージョン 2.7

Topology Aware Lifecycle Manager (TALM)

バージョン 4.13

サーバーハードウェア

Dell PowerEdge R650 ラックサーバー 3 台

NVMe ハードディスク

  • /var/lib/etcd 用の 50 GB ディスク
  • /var/lib/containers 用の 2.9 TB ディスク

SSD ハードディスク

  • 1 つの SSD を、15 のシンプロビジョニングされた 200 GB の論理ボリュームに分割して PV CR としてプロビジョニング。
  • 非常に大規模な PV リソースとして機能する 1 つの SSD

適用された DU プロファイルポリシーの数

5

重要

次のネットワーク仕様は、典型的な実際の RAN ネットワークを表しており、テスト中にスケールラボ環境に適用されます。

表18.5 模擬ラボ環境のネットワーク仕様
仕様説明

ラウンドトリップタイム (RTT) 遅延

50 ms

パケットロス

0.02% のパケットロス

ネットワーク帯域幅の制限

20 Mbps

18.2.3. 非接続環境での GitOps ZTP のインストール

非接続環境のハブクラスターで Red Hat Advanced Cluster Management (RHACM)、Red Hat OpenShift GitOps、Topology Aware Lifecycle Manager (TALM) を使用して、複数のマネージドクラスターのデプロイを管理します。

前提条件

  • OpenShift Container Platform CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • クラスターで使用するために、切断されたミラーレジストリーを設定しました。

    注記

    作成する非接続ミラーレジストリーには、ハブクラスターで実行されている TALM のバージョンと一致する TALM バックアップおよび事前キャッシュイメージのバージョンが含まれている必要があります。スポーククラスターは、切断されたミラーレジストリーでこれらのイメージを解決できる必要があります。

手順

18.2.4. RHCOS ISO および RootFS イメージの非接続ミラーホストへの追加

Red Hat Advanced Cluster Management (RHACM) を使用して非接続環境にクラスターのインストールを開始する前に、最初に使用する Red Hat Enterprise Linux CoreOS (RHCOS) イメージをホストする必要があります。切断されたミラーを使用して RHCOS イメージをホストします。

前提条件

  • ネットワーク上で RHCOS イメージリソースをホストするように HTTP サーバーをデプロイして設定します。お使いのコンピューターから HTTP サーバーにアクセスでき、作成するマシンからもアクセスできる必要があります。
重要

RHCOS イメージは OpenShift Container Platform の各リリースごとに変更されない可能性があります。インストールするバージョン以下の最新バージョンのイメージをダウンロードする必要があります。利用可能な場合は、OpenShift Container Platform バージョンに一致するイメージのバージョンを使用します。ホストに RHCOS をインストールするには、ISO および RootFS イメージが必要です。RHCOS QCOW2 イメージは、このインストールタイプではサポートされません。

手順

  1. ミラーホストにログインします。
  2. mirror.openshift.com から RHCOS ISO イメージおよび RootFS イメージを取得します。以下は例になります。

    1. 必要なイメージ名と OpenShift Container Platform のバージョンを環境変数としてエクスポートします。

      $ export ISO_IMAGE_NAME=<iso_image_name> 1
      $ export ROOTFS_IMAGE_NAME=<rootfs_image_name> 1
      $ export OCP_VERSION=<ocp_version> 1
      1
      ISO イメージ名 (例: rhcos-4.14.1-x86_64-live.x86_64.iso)
      1
      RootFS イメージ名 (例: rhcos-4.14.1-x86_64-live-rootfs.x86_64.img)
      1
      OpenShift Container Platform バージョン (例: 4.14.1)
    2. 必要なイメージをダウンロードします。

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.14/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}
      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.14/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}

検証手順

  • イメージが正常にダウンロードされ、非接続ミラーホストで提供されることを確認します。以下に例を示します。

    $ wget http://$(hostname)/${ISO_IMAGE_NAME}

    出力例

    Saving to: rhcos-4.14.1-x86_64-live.x86_64.iso
    rhcos-4.14.1-x86_64-live.x86_64.iso-  11%[====>    ]  10.01M  4.71MB/s

18.2.5. 支援サービスの有効化

Red Hat Advanced Cluster Management (RHACM) は、アシストサービスを使用して OpenShift Container Platform クラスターをデプロイします。Red Hat Advanced Cluster Management (RHACM) で MultiClusterHub Operator を有効にすると、支援サービスが自動的にデプロイされます。その後、すべての namespace を監視し、ミラーレジストリー HTTP サーバーでホストされている ISO および RootFS イメージへの参照を使用して、AgentServiceConfig カスタムリソース (CR) を更新するように Provisioning リソースを設定する必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
  • RHACM で MultiClusterHub が有効になっている。

手順

  1. Provisioning リソースを有効にして、すべての namespace を監視し、非接続環境のミラーを設定します。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。
  2. 以下のコマンドを実行して、AgentServiceConfig CR を更新します。

    $ oc edit AgentServiceConfig
  3. CR の items.spec.osImages フィールドに次のエントリーを追加します。

    - cpuArchitecture: x86_64
        openshiftVersion: "4.14"
        rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
        url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso

    ここでは、以下のようになります。

    <host>
    ターゲットミラーレジストリー HTTP サーバーの完全修飾ドメイン名 (FQDN) です。
    <path>
    ターゲットミラーレジストリー上のイメージへのパスです。

    エディターを保存して終了し、変更を適用します。

18.2.6. 切断されたミラーレジストリーを使用するためのハブクラスターの設定

非接続環境で切断されたミラーレジストリーを使用するようにハブクラスターを設定できます。

前提条件

  • Red Hat Advanced Cluster Management (RHACM) 2.8 がインストールされた切断されたハブクラスターのインストールがあります。
  • HTTP サーバーで rootfs および iso イメージをホストしている。OpenShift Container Platform イメージリポジトリーのミラーリング に関するガイダンスは、関連情報 セクションを参照してください。
警告

HTTP サーバーに対して TLS を有効にする場合、ルート証明書がクライアントによって信頼された機関によって署名されていることを確認し、OpenShift Container Platform ハブおよびマネージドクラスターと HTTP サーバー間の信頼された証明書チェーンを検証する必要があります。信頼されていない証明書で設定されたサーバーを使用すると、イメージがイメージ作成サービスにダウンロードされなくなります。信頼されていない HTTPS サーバーの使用はサポートされていません。

手順

  1. ミラーレジストリー設定を含む ConfigMap を作成します。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: assisted-installer-mirror-config
      namespace: multicluster-engine 1
      labels:
        app: assisted-service
    data:
      ca-bundle.crt: | 2
        -----BEGIN CERTIFICATE-----
        <certificate_contents>
        -----END CERTIFICATE-----
    
      registries.conf: | 3
        unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
    
        [[registry]]
           prefix = ""
           location = "quay.io/example-repository" 4
           mirror-by-digest-only = true
    
           [[registry.mirror]]
           location = "mirror1.registry.corp.com:5000/example-repository" 5
    1
    ConfigMap namespace は multicluster-engine に設定する必要があります。
    2
    ミラーレジストリーの作成時に使用されるミラーレジストリーの証明書。
    3
    ミラーレジストリーの設定ファイル。ミラーレジストリー設定は、検出イメージの /etc/containers/registries.conf ファイルにミラー情報を追加します。ミラー情報は、インストールプログラムに渡される際、install-config.yaml ファイルの imageContentSources セクションに保存されます。ハブクラスターで実行される Assisted Service Pod は、設定されたミラーレジストリーからコンテナーイメージをフェッチします。
    4
    ミラーレジストリーの URL。ミラーレジストリーを設定する場合は、oc adm release mirror コマンドを実行して、imageContentSources セクションの URL を使用する必要があります。詳細は、OpenShift Container Platform イメージリポジトリーのミラーリング セクションを参照してください。
    5
    registries.conf ファイルで定義されるレジストリーは、レジストリーではなくリポジトリーによってスコープが指定される必要があります。この例では、quay.io/example-repository リポジトリーと mirror1.registry.corp.com:5000/example-repository リポジトリーの両方のスコープが example-repository リポジトリーにより指定されます。

    これにより、以下のように AgentServiceConfig カスタムリソースの mirrorRegistryRef が更新されます。

    出力例

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
      name: agent
      namespace: multicluster-engine 1
    spec:
      databaseStorage:
        volumeName: <db_pv_name>
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <db_storage_size>
      filesystemStorage:
        volumeName: <fs_pv_name>
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <fs_storage_size>
      mirrorRegistryRef:
        name: assisted-installer-mirror-config 2
      osImages:
        - openshiftVersion: <ocp_version>
          url: <iso_url> 3

    1
    ConfigMap namespace と一致するように、AgentServiceConfig namespace を multicluster-engine に設定します。
    2
    関連する ConfigMap CR で指定された定義と一致するように、mirrorRegistryRef.name を設定します。
    3
    httpd サーバーでホストされる ISO の URL を設定します。
重要

クラスターのインストール時には、有効な NTP サーバーが必要です。適切な NTP サーバーが使用可能であり、切断されたネットワークを介してインストール済みクラスターからアクセスできることを確認してください。

18.2.7. 非認証レジストリーを使用するためのハブクラスターの設定

非認証レジストリーを使用するようにハブクラスターを設定できます。非認証レジストリーは、イメージへのアクセスとダウンロードに認証を必要としません。

前提条件

  • ハブクラスターがインストールおよび設定され、ハブクラスターに Red Hat Advanced Cluster Management (RHACM) がインストールされている。
  • OpenShift Container Platform CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • ハブクラスターで使用するために非認証レジストリーを設定している。

手順

  1. 次のコマンドを実行して、AgentServiceConfig カスタムリソース (CR) を更新します。

    $ oc edit AgentServiceConfig agent
  2. CR に unauthenticatedRegistries フィールドを追加します。

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
      name: agent
    spec:
      unauthenticatedRegistries:
      - example.registry.com
      - example.registry2.com
      ...

    非認証レジストリーは、AgentServiceConfig リソースの spec.unauthenticatedRegistries の下に一覧表示されます。このリストにあるレジストリーのエントリーは、スポーククラスターのインストールに使用されるプルシークレットに含める必要はありません。assisted-service は、インストールに使用されるすべてのイメージレジストリーの認証情報がプルシークレットに含まれていることを確認して、プルシークレットを検証します。

注記

ミラーレジストリーは自動的に無視リストに追加されるため、spec.unauthenticatedRegistries の下に追加する必要はありません。ConfigMapPUBLIC_CONTAINER_REGISTRIES 環境変数を指定すると、デフォルト値が指定した値でオーバーライドされます。PUBLIC_CONTAINER_REGISTRIES のデフォルトは quay.io および registry.svc.ci.openshift.org です。

検証

次のコマンドを実行して、ハブクラスターから新しく追加されたレジストリーにアクセスできることを確認します。

  1. ハブクラスターへのデバッグシェルプロンプトを開きます。

    $ oc debug node/<node_name>
  2. 次のコマンドを実行して、非認証レジストリーへのアクセスをテストします。

    sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>

    ここでは、以下のようになります。

    <unauthenticated_registry>
    unauthenticated-image-registry.openshift-image-registry.svc:5000 などの新しいレジストリーです。

    出力例

    Login Succeeded!

18.2.8. ArgoCD を使用したハブクラスターの設定

GitOps Zero Touch Provisioning (ZTP) を使用して、サイトごとに必要なインストールおよびポリシーカスタムリソース (CR) を生成する一連の ArgoCD アプリケーションでハブクラスターを設定できます。

注記

Red Hat Advanced Cluster Management (RHACM) は SiteConfig CR を使用して、ArgoCD の Day 1 マネージドクラスターインストール CR を生成します。各 ArgoCD アプリケーションは、最大 300 個の SiteConfig CR を管理できます。

前提条件

  • Red Hat Advanced Cluster Management (RHACM) と Red Hat OpenShift GitOps がインストールされた OpenShift Container Platform ハブクラスターがあります。
  • 「GitOps ZTP サイト設定リポジトリーの準備」セクションで説明されているように、GitOps ZTP プラグインコンテナーから参照デプロイメントを抽出しました。参照デプロイメントを抽出すると、次の手順で参照される out/argocd/deployment ディレクトリーが作成されます。

手順

  1. ArgoCD パイプライン設定を準備します。

    1. example ディレクトリーと同様にディレクトリー構造で Git リポジトリーを作成します。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。
    2. ArgoCD UI を使用して、リポジトリーへのアクセスを設定します。Settings で以下を設定します。

      • リポジトリー: 接続情報を追加します。URL は .git などで終わっている必要があります。https://repo.example.com/repo.git と認証情報を指定します。
      • Certificates - 必要に応じて、リポジトリーのパブリック証明書を追加します。
    3. 2 つの ArgoCD アプリケーション、out/argocd/deployment/clusters-app.yamlout/argocd/deployment/policies-app.yaml を、Git リポジトリーに基づいて修正します。

      • Git リポジトリーを参照するように URL を更新します。URL は .git で終わります (例: https://repo.example.com/repo.git)。
      • targetRevision は、監視する Git リポジトリーブランチを示します。
      • path は、それぞれ SiteConfig CR および PolicyGenTemplate CR へのパスを指定します。
  1. GitOps ZTP プラグインをインストールするには、ハブクラスター内の ArgoCD インスタンスに、関連するマルチクラスターエンジン (MCE) サブスクリプションイメージをパッチ適用します。以前に out/argocd/deployment/ ディレクトリーに展開したパッチファイルを環境に合わせてカスタマイズします。

    1. RHACM バージョンに一致する multicluster-operators-subscription イメージを選択します。

      表18.6 multicluster-operators-subscription イメージバージョン
      OpenShift Container Platform バージョンRHACM バージョンMCE バージョンMCE RHEL バージョンMCE イメージ

      4.14、4.15、4.16

      2.8、2.9

      2.8、2.9

      RHEL 8

      registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.8

      registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.9

      4.14、4.15、4.16

      2.10

      2.10

      RHEL 9

      registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10

      重要

      multicluster-operators-subscription イメージのバージョンは、RHACM バージョンと一致する必要があります。MCE 2.10 リリース以降、RHEL 9 は multicluster-operators-subscription イメージのベースイメージです。

    2. out/argocd/deployment/argocd-openshift-gitops-patch.json ファイルに次の設定を追加します。

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 1
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 2 3
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }
      1
      オプション: RHEL 9 イメージの場合、ArgoCD バージョンの /policy-generator/PolicyGenerator-not-fips-compliant フォルダーに必要なユニバーサル実行可能ファイルをコピーします。
      2
      multicluster-operators-subscription イメージを RHACM バージョンに一致させます。
      3
      非接続環境では、multicluster-operators-subscription イメージの URL を、ご使用の環境の非接続レジストリーに相当するものに置き換えます。
    3. ArgoCD インスタンスにパッチを適用します。以下のコマンドを実行します。

      $ oc patch argocd openshift-gitops \
      -n openshift-gitops --type=merge \
      --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
  2. RHACM 2.7 以降では、マルチクラスターエンジンはデフォルトで cluster-proxy-addon 機能を有効にします。次のパッチを適用して、cluster-proxy-addon 機能を無効にし、このアドオンに関連するハブクラスターとマネージド Pod を削除します。以下のコマンドを実行します。

    $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json
  3. 次のコマンドを実行して、パイプライン設定をハブクラスターに適用します。

    $ oc apply -k out/argocd/deployment

18.2.9. GitOps ZTP サイト設定リポジトリーの準備

GitOps Zero Touch Provisioning (ZTP) パイプラインを使用する前に、サイト設定データをホストする Git リポジトリーを準備する必要があります。

前提条件

  • 必要なインストールおよびポリシーのカスタムリソース (CR) を生成するためのハブクラスター GitOps アプリケーションを設定している。
  • GitOps ZTP を使用してマネージドクラスターをデプロイしている。

手順

  1. SiteConfig CR と PolicyGenTemplate CR の個別のパスを持つディレクトリー構造を作成します。

    注記

    SiteConfig および PolicyGenTemplate CR を個別のディレクトリーで保持します。SiteConfig ディレクトリーおよび PolicyGenTemplate ディレクトリーには、そのディレクトリー内のファイルを明示的に含める kustomization.yaml ファイルが含まれている必要があります。

  2. 以下のコマンドを使用して ztp-site-generate コンテナーイメージから argocd ディレクトリーをエクスポートします。

    $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.14
    $ mkdir -p ./out
    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.14 extract /home/ztp --tar | tar x -C ./out
  3. out ディレクトリーに以下のサブディレクトリーが含まれていることを確認します。

    • out/extra-manifest には、SiteConfig が追加の manifest configMap の生成に使用するソース CR ファイルが含まれます。
    • out/source-crs には、PolicyGenTemplate が Red Hat Advanced Cluster Management (RHACM) ポリシーを生成するために使用するソース CR ファイルが含まれています。
    • out/argocd/deployment には、この手順の次のステップで使用するハブクラスターに適用するパッチおよび YAML ファイルが含まれます。
    • out/argocd/example には、推奨の設定を表す SiteConfig ファイルおよび PolicyGenTemplate ファイルのサンプルが含まれています。
  4. out/source-crs フォルダーとその内容を PolicyGentemplate ディレクトリーにコピーします。
  5. out/extra-manifests ディレクトリーには、RAN DU クラスターの参照マニフェストが含まれています。out/extra-manifests ディレクトリーを SiteConfig フォルダーにコピーします。このディレクトリーには、ztp-site-generate コンテナーからの CR のみを含める必要があります。ユーザー提供の CR をここに追加しないでください。ユーザー提供の CR を使用する場合は、そのコンテンツ用に別のディレクトリーを作成する必要があります。以下に例を示します。

    example/
      ├── policygentemplates
      │   ├── kustomization.yaml
      │   └── source-crs/
      └── siteconfig
            ├── extra-manifests
            └── kustomization.yaml
  6. ディレクトリー構造と kustomization.yaml ファイルをコミットし、Git リポジトリーにプッシュします。Git への最初のプッシュには、kustomization.yaml ファイルが含まれている必要があります。

out/argocd/example のディレクトリー構造は、Git リポジトリーの構造およびコンテンツの参照として使用します。この構造には、単一ノード、3 ノード、標準クラスターの SiteConfig および PolicyGenTemplate の参照 CR が含まれます。使用されていないクラスタータイプの参照を削除します。

すべてのクラスタータイプについて、次のことを行う必要があります。

  • source-crs サブディレクトリーを policygentemplate ディレクトリーに追加します。
  • extra-manifests ディレクトリーを siteconfig ディレクトリーに追加します。

以下の例では、シングルノードクラスターのネットワークの CR のセットを説明しています。

example/
  ├── policygentemplates
  │   ├── common-ranGen.yaml
  │   ├── example-sno-site.yaml
  │   ├── group-du-sno-ranGen.yaml
  │   ├── group-du-sno-validator-ranGen.yaml
  │   ├── kustomization.yaml
  │   ├── source-crs/
  │   └── ns.yaml
  └── siteconfig
        ├── example-sno.yaml
        ├── extra-manifests/ 1
        ├── custom-manifests/ 2
        ├── KlusterletAddonConfigOverride.yaml
        └── kustomization.yaml
1
ztp-container からの参照マニフェストが含まれます。
2
カスタムマニフェストが含まれます。

18.2.9.1. バージョンに依存しないように GitOps ZTP サイト設定リポジトリーを準備する

GitOps ZTP を使用して、OpenShift Container Platform のさまざまなバージョンを実行しているマネージドクラスターのソースカスタムリソース (CR) を管理できます。これは、ハブクラスター上で実行している OpenShift Container Platform のバージョンが、マネージドクラスター上で実行しているバージョンから独立している可能性があることを意味します。

手順

  1. SiteConfig CR と PolicyGenTemplate CR の個別のパスを持つディレクトリー構造を作成します。
  2. PolicyGenTemplate ディレクトリー内に、使用可能にする OpenShift Container Platform バージョンごとにディレクトリーを作成します。バージョンごとに、次のリソースを作成します。

    • そのディレクトリー内のファイルを明示的に含む kustomization.yaml ファイル
    • source-crs ディレクトリーには、ztp-site-generate コンテナーからの参照 CR 設定ファイルが含まれます。

      ユーザー提供の CR を使用する場合は、CR 用に別のディレクトリーを作成する必要があります。

  3. /siteconfig ディレクトリーに、使用可能にする OpenShift Container Platform バージョンごとにサブディレクトリーを作成します。バージョンごとに、コンテナーからコピーされる参照 CR 用のディレクトリーを少なくとも 1 つ作成します。ディレクトリーの名前や参照ディレクトリーの数に制限はありません。カスタムマニフェストを使用する場合は、個別のディレクトリーを作成する必要があります。

    次の例では、OpenShift Container Platform のさまざまなバージョンのユーザー提供のマニフェストと CR を使用した構造を説明します。

    ├── policygentemplates
    │   ├── kustomization.yaml 1
    │   ├── version_4.13 2
    │   │   ├── common-ranGen.yaml
    │   │   ├── group-du-sno-ranGen.yaml
    │   │   ├── group-du-sno-validator-ranGen.yaml
    │   │   ├── helix56-v413.yaml
    │   │   ├── kustomization.yaml 3
    │   │   ├── ns.yaml
    │   │   └── source-crs/ 4
    │   │      └── reference-crs/ 5
    │   │      └── custom-crs/ 6
    │   └── version_4.14 7
    │       ├── common-ranGen.yaml
    │       ├── group-du-sno-ranGen.yaml
    │       ├── group-du-sno-validator-ranGen.yaml
    │       ├── helix56-v414.yaml
    │       ├── kustomization.yaml 8
    │       ├── ns.yaml
    │       └── source-crs/ 9
    │         └── reference-crs/ 10
    │         └── custom-crs/ 11
    └── siteconfig
        ├── kustomization.yaml
        ├── version_4.13
        │   ├── helix56-v413.yaml
        │   ├── kustomization.yaml
        │   ├── extra-manifest/ 12
        │   └── custom-manifest/ 13
        └── version_4.14
            ├── helix57-v414.yaml
            ├── kustomization.yaml
            ├── extra-manifest/ 14
            └── custom-manifest/ 15
    1
    最上位の kustomization YAML ファイルを作成します。
    2 7
    カスタム /policygentemplates ディレクトリー内にバージョン固有のディレクトリーを作成します。
    3 8
    バージョンごとに kustomization.yaml ファイルを作成します。
    4 9
    ztp-site-generate コンテナーからの参照 CR を含めるために、バージョンごとに source-crs ディレクトリーを作成します。
    5 10
    ZTP コンテナーから展開されるポリシー CR の reference-crs ディレクトリーを作成します。
    6 11
    オプション: ユーザー提供の CR 用に custom-crs ディレクトリーを作成します。
    12 14
    カスタム /siteconfig ディレクトリー内にディレクトリーを作成し、ztp-site-generate コンテナーからの追加のマニフェストを含めます。
    13 15
    ユーザーによって提供されるマニフェストを保持するフォルダーを作成します。
    注記

    前の例では、カスタム /siteconfig ディレクトリー内の各バージョンサブディレクトリーにはさらに 2 つのサブディレクトリーが含まれており、1 つはコンテナーからコピーされた参照マニフェストを含み、もう 1 つは提供するカスタムマニフェスト用です。これらのディレクトリーに割り当てられた名前は一例です。ユーザー提供の CR を使用する場合は、SiteConfig CR の extraManifests.searchPaths の下にリストされている最後のディレクトリーが、ユーザー提供の CR を含むディレクトリーである必要があります。

  4. SiteConfig CR を編集して、作成したディレクトリーの検索パスを含めます。extraManifests.searchPaths の下にリストされる最初のディレクトリーは、参照マニフェストを含むディレクトリーである必要があります。ディレクトリーがリストされている順序を考慮してください。ディレクトリーに同じ名前のファイルが含まれている場合は、最後のディレクトリーにあるファイルが優先されます。

    SiteConfig CR の例

    extraManifests:
        searchPaths:
        - extra-manifest/ 1
        - custom-manifest/ 2

    1
    参照マニフェストを含むディレクトリーは、extraManifests.searchPaths の下に最初にリストされる必要があります。
    2
    ユーザー提供の CR を使用している場合は、SiteConfig CR の extraManifests.searchPaths の下にリストされている最後のディレクトリーが、ユーザー提供の CR を含むディレクトリーである必要があります。
  5. トップレベルの kustomization.yaml ファイルを編集して、アクティブな OpenShift Container Platform バージョンを制御します。以下は、最上位レベルの kustomization.yaml ファイルの例です。

    resources:
    - version_4.13 1
    #- version_4.14 2
    1
    バージョン 4.13 をアクティブ化します。
    2
    コメントを使用してバージョンを非アクティブ化します。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.