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


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

19.2.1. Telco RAN 4.13 検証済みソリューションソフトウェアバージョン

Red Hat Telco Radio Access Network (RAN) バージョン 4.13 ソリューションは、次の Red Hat ソフトウェア製品を使用して検証されています。

表19.2 Telco RAN 4.13 検証済みソリューションソフトウェア
Productソフトウェアバージョン

Hub クラスターの OpenShift Container Platform のバージョン

4.13

GitOps ZTP プラグイン

4.11、4.12、または 4.13

Red Hat Advanced Cluster Management (RHACM)

2.7

Red Hat OpenShift GitOps

1.9、1.10

Topology Aware Lifecycle Manager (TALM)

4.11、4.12、または 4.13

19.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 クラスターとネットワーク仕様を開発します。

重要

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

表19.3 代表的な 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 ネットワークを表しており、テスト中にスケールラボ環境に適用されます。

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

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

50 ms

パケットロス

0.02% のパケットロス

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

20 Mbps

19.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 バックアップおよび事前キャッシュイメージのバージョンが含まれている必要があります。スポーククラスターは、切断されたミラーレジストリーでこれらのイメージを解決できる必要があります。

手順

19.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.13.1-x86_64-live.x86_64.iso)
      1
      RootFS イメージ名 (例: rhcos-4.13.1-x86_64-live-rootfs.x86_64.img)
      1
      OpenShift Container Platform バージョン (例: 4.13.1)
    2. 必要なイメージをダウンロードします。

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

検証手順

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

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

    出力例

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

19.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.13"
        rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
        url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso

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

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

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

19.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 サーバーが使用可能であり、切断されたネットワークを介してインストール済みクラスターからアクセスできることを確認してください。

19.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!

19.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 へのパスを指定します。
  2. GitOps ZTP プラグインをインストールするには、以前に out/argocd/deployment/ ディレクトリーに抽出されたパッチファイルを使用して、ハブクラスター内の ArgoCD インスタンスにパッチを適用する必要があります。以下のコマンドを実行します。

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

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

    $ oc apply -k out/argocd/deployment

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

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

前提条件

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

手順

  1. SiteConfig CR と PolicyGenTemplate CR の個別のパスを持つディレクトリー構造を作成します。
  2. 以下のコマンドを使用して ztp-site-generate コンテナーイメージから argocd ディレクトリーをエクスポートします。

    $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.13
    $ mkdir -p ./out
    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.13 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 ファイルのサンプルが含まれています。

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

example
├── policygentemplates
│   ├── common-ranGen.yaml
│   ├── example-sno-site.yaml
│   ├── group-du-sno-ranGen.yaml
│   ├── group-du-sno-validator-ranGen.yaml
│   ├── kustomization.yaml
│   └── ns.yaml
└── siteconfig
    ├── example-sno.yaml
    ├── KlusterletAddonConfigOverride.yaml
    └── kustomization.yaml

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

このディレクトリー構造と kustomization.yaml ファイルはコミットされ、Git リポジトリーにプッシュされる必要があります。Git への最初のプッシュには、kustomization.yaml ファイルが含まれている必要があります。SiteConfig (example-sno.yaml) および PolicyGenTemplate (common-ranGen.yamlgroup-du-sno*.yaml、および example-sno-site.yaml) ファイルは省略され、後でサイトをデプロイする際にプッシュできます。

KlusterletAddonConfigOverride.yaml ファイルは、その CR を参照する 1 つ以上の SiteConfig CR がコミットされ、Git にプッシュされている場合にのみ必要です。これがどのように使用されるかについては、example-sno.yaml を参照してください。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.