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 ソフトウェア製品を使用して検証されています。
コンポーネント | ソフトウェアバージョン |
---|---|
マネージドクラスターのバージョン | 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 |
コンポーネント | ソフトウェアバージョン |
---|---|
ハブクラスターのバージョン | 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 クラスターとネットワーク仕様を開発します。
次のガイドラインは、社内のラボのベンチマークテストのみに基づいており、完全なベアメタルホストの仕様を表すものではありません。
要件 | 説明 |
---|---|
OpenShift Container Platform | バージョン 4.13 |
RHACM | バージョン 2.7 |
Topology Aware Lifecycle Manager (TALM) | バージョン 4.13 |
サーバーハードウェア | Dell PowerEdge R650 ラックサーバー 3 台 |
NVMe ハードディスク |
|
SSD ハードディスク |
|
適用された DU プロファイルポリシーの数 | 5 |
次のネットワーク仕様は、典型的な実際の RAN ネットワークを表しており、テスト中にスケールラボ環境に適用されます。
仕様 | 説明 |
---|---|
ラウンドトリップタイム (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 バックアップおよび事前キャッシュイメージのバージョンが含まれている必要があります。スポーククラスターは、切断されたミラーレジストリーでこれらのイメージを解決できる必要があります。
手順
- ハブクラスターに RHACM をインストールします。非接続環境での RHACM のインストール を参照してください。
- ハブクラスターに GitOps と 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 イメージは、このインストールタイプではサポートされません。
手順
- ミラーホストにログインします。
mirror.openshift.com から RHCOS ISO イメージおよび RootFS イメージを取得します。以下は例になります。
必要なイメージ名と 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
必要なイメージをダウンロードします。
$ 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 が有効になっている。
手順
-
Provisioning
リソースを有効にして、すべての namespace を監視し、非接続環境のミラーを設定します。詳細は、Central Infrastructure Management サービスの有効化 を参照してください。 以下のコマンドを実行して、
AgentServiceConfig
CR を更新します。$ oc edit AgentServiceConfig
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 サーバーの使用はサポートされていません。
手順
ミラーレジストリー設定を含む
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
クラスターのインストール時には、有効な NTP サーバーが必要です。適切な NTP サーバーが使用可能であり、切断されたネットワークを介してインストール済みクラスターからアクセスできることを確認してください。
18.2.7. 非認証レジストリーを使用するためのハブクラスターの設定
非認証レジストリーを使用するようにハブクラスターを設定できます。非認証レジストリーは、イメージへのアクセスとダウンロードに認証を必要としません。
前提条件
- ハブクラスターがインストールおよび設定され、ハブクラスターに Red Hat Advanced Cluster Management (RHACM) がインストールされている。
- OpenShift Container Platform CLI (oc) がインストールされている。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - ハブクラスターで使用するために非認証レジストリーを設定している。
手順
次のコマンドを実行して、
AgentServiceConfig
カスタムリソース (CR) を更新します。$ oc edit AgentServiceConfig agent
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
の下に追加する必要はありません。ConfigMap
で PUBLIC_CONTAINER_REGISTRIES
環境変数を指定すると、デフォルト値が指定した値でオーバーライドされます。PUBLIC_CONTAINER_REGISTRIES
のデフォルトは quay.io および registry.svc.ci.openshift.org です。
検証
次のコマンドを実行して、ハブクラスターから新しく追加されたレジストリーにアクセスできることを確認します。
ハブクラスターへのデバッグシェルプロンプトを開きます。
$ oc debug node/<node_name>
次のコマンドを実行して、非認証レジストリーへのアクセスをテストします。
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
ディレクトリーが作成されます。
手順
ArgoCD パイプライン設定を準備します。
- example ディレクトリーと同様にディレクトリー構造で Git リポジトリーを作成します。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。
ArgoCD UI を使用して、リポジトリーへのアクセスを設定します。Settings で以下を設定します。
-
リポジトリー: 接続情報を追加します。URL は
.git
などで終わっている必要があります。https://repo.example.com/repo.git
と認証情報を指定します。 - Certificates - 必要に応じて、リポジトリーのパブリック証明書を追加します。
-
リポジトリー: 接続情報を追加します。URL は
2 つの ArgoCD アプリケーション、
out/argocd/deployment/clusters-app.yaml
とout/argocd/deployment/policies-app.yaml
を、Git リポジトリーに基づいて修正します。-
Git リポジトリーを参照するように URL を更新します。URL は
.git
で終わります (例:https://repo.example.com/repo.git
)。 -
targetRevision
は、監視する Git リポジトリーブランチを示します。 -
path
は、それぞれSiteConfig
CR およびPolicyGenTemplate
CR へのパスを指定します。
-
Git リポジトリーを参照するように URL を更新します。URL は
GitOps ZTP プラグインをインストールするには、ハブクラスター内の ArgoCD インスタンスに、関連するマルチクラスターエンジン (MCE) サブスクリプションイメージをパッチ適用します。以前に
out/argocd/deployment/
ディレクトリーに展開したパッチファイルを環境に合わせてカスタマイズします。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
イメージのベースイメージです。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" } ] }
ArgoCD インスタンスにパッチを適用します。以下のコマンドを実行します。
$ oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
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
次のコマンドを実行して、パイプライン設定をハブクラスターに適用します。
$ oc apply -k out/argocd/deployment
18.2.9. GitOps ZTP サイト設定リポジトリーの準備
GitOps Zero Touch Provisioning (ZTP) パイプラインを使用する前に、サイト設定データをホストする Git リポジトリーを準備する必要があります。
前提条件
- 必要なインストールおよびポリシーのカスタムリソース (CR) を生成するためのハブクラスター GitOps アプリケーションを設定している。
- GitOps ZTP を使用してマネージドクラスターをデプロイしている。
手順
SiteConfig
CR とPolicyGenTemplate
CR の個別のパスを持つディレクトリー構造を作成します。注記SiteConfig
およびPolicyGenTemplate
CR を個別のディレクトリーで保持します。SiteConfig
ディレクトリーおよびPolicyGenTemplate
ディレクトリーには、そのディレクトリー内のファイルを明示的に含めるkustomization.yaml
ファイルが含まれている必要があります。以下のコマンドを使用して
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
out
ディレクトリーに以下のサブディレクトリーが含まれていることを確認します。-
out/extra-manifest
には、SiteConfig
が追加の manifestconfigMap
の生成に使用するソース CR ファイルが含まれます。 -
out/source-crs
には、PolicyGenTemplate が
Red Hat Advanced Cluster Management (RHACM) ポリシーを生成するために使用するソース CR ファイルが含まれています。 -
out/argocd/deployment
には、この手順の次のステップで使用するハブクラスターに適用するパッチおよび YAML ファイルが含まれます。 -
out/argocd/example
には、推奨の設定を表すSiteConfig
ファイルおよびPolicyGenTemplate
ファイルのサンプルが含まれています。
-
-
out/source-crs
フォルダーとその内容をPolicyGentemplate
ディレクトリーにコピーします。 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
-
ディレクトリー構造と
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
18.2.9.1. バージョンに依存しないように GitOps ZTP サイト設定リポジトリーを準備する
GitOps ZTP を使用して、OpenShift Container Platform のさまざまなバージョンを実行しているマネージドクラスターのソースカスタムリソース (CR) を管理できます。これは、ハブクラスター上で実行している OpenShift Container Platform のバージョンが、マネージドクラスター上で実行しているバージョンから独立している可能性があることを意味します。
手順
-
SiteConfig
CR とPolicyGenTemplate
CR の個別のパスを持つディレクトリー構造を作成します。 PolicyGenTemplate
ディレクトリー内に、使用可能にする OpenShift Container Platform バージョンごとにディレクトリーを作成します。バージョンごとに、次のリソースを作成します。-
そのディレクトリー内のファイルを明示的に含む
kustomization.yaml
ファイル source-crs
ディレクトリーには、ztp-site-generate
コンテナーからの参照 CR 設定ファイルが含まれます。ユーザー提供の CR を使用する場合は、CR 用に別のディレクトリーを作成する必要があります。
-
そのディレクトリー内のファイルを明示的に含む
/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 を含むディレクトリーである必要があります。SiteConfig
CR を編集して、作成したディレクトリーの検索パスを含めます。extraManifests.searchPaths
の下にリストされる最初のディレクトリーは、参照マニフェストを含むディレクトリーである必要があります。ディレクトリーがリストされている順序を考慮してください。ディレクトリーに同じ名前のファイルが含まれている場合は、最後のディレクトリーにあるファイルが優先されます。SiteConfig CR の例
extraManifests: searchPaths: - extra-manifest/ 1 - custom-manifest/ 2
トップレベルの
kustomization.yaml
ファイルを編集して、アクティブな OpenShift Container Platform バージョンを制御します。以下は、最上位レベルのkustomization.yaml
ファイルの例です。resources: - version_4.13 1 #- version_4.14 2