19.3. RHACM および SiteConfig リソースを使用したマネージドクラスターのインストール
Red Hat Advanced Cluster Management (RHACM) を使用して OpenShift Container Platform クラスターを大規模にプロビジョニングするには、アシストサービスと、コア削減テクノロジーが有効になっている GitOps プラグインポリシージェネレーターを使用します。ゼロタッチプライオビジョン (ZTP) パイプラインがクラスターのインストールを実行します。ZTP は、切断された環境で使用できます。
19.3.1. GitOps ZTP および Topology Aware Lifecycle Manager
GitOps ゼロタッチプロビジョニング (ZTP) は、Git に格納されたマニフェストからインストールと設定の CR を生成します。これらのアーティファクトは、Red Hat Advanced Cluster Management (RHACM)、アシストサービス、および Topology Aware Lifecycle Manager (TALM) が CR を使用してマネージドクラスターをインストールおよび設定する中央ハブクラスターに適用されます。ZTP パイプラインの設定フェーズでは、TALM を使用してクラスターへの設定 CR の適用をオーケストレートします。GitOps ZTP と TALM の間には、いくつかの重要な統合ポイントがあります。
- Inform ポリシー
-
デフォルトでは、GitOps ZTP は、
inform
の修復アクションですべてのポリシーを作成します。これらのポリシーにより、RHACM はポリシーに関連するクラスターのコンプライアンスステータスを報告しますが、必要な設定は適用されません。ZTP プロセス中、OpenShift のインストール後、TALM は作成されたinform
ポリシーをステップスルーし、ターゲットのマネージドクラスターに適用します。これにより、設定がマネージドクラスターに適用されます。クラスターライフサイクルの ZTP フェーズ以外では、影響を受けるマネージドクラスターに変更をすぐにロールアウトするリスクなしに、ポリシーを変更できます。TALM を使用して、修正されたクラスターのタイミングとセットを制御できます。 - ClusterGroupUpgrade CR の自動作成
新しくデプロイされたクラスターの初期設定を自動化するために、TALM はハブクラスター上のすべての
ManagedCluster
CR の状態を監視します。新規に作成されたManagedCluster
CR を含むztp-done
ラベルを持たないManagedCluster
CR が適用されると、TALM は以下の特性でClusterGroupUpgrade
CR を自動的に作成します。-
ClusterGroupUpgrade
CR がztp-install
namespace に作成され、有効にされます。 -
ClusterGroupUpgrade
CR の名前はManagedCluster
CR と同じになります。 -
クラスターセレクターには、その
ManagedCluster
CR に関連付けられたクラスターのみが含まれます。 -
管理ポリシーのセットには、
ClusterGroupUpgrade
の作成時に RHACM がクラスターにバインドされているすべてのポリシーが含まれます。 - 事前キャッシュは無効です。
- タイムアウトを 4 時間 (240 分) に設定。
有効な
ClusterGroupUpgrade
の自動生成により、ユーザーの介入を必要としないゼロタッチのクラスターデプロイメントが可能になります。さらに、ztp-done
ラベルのないManagedCluster
に対してClusterGroupUpgrade
CR が自動的に作成されるため、失敗した ZTP インストールを、そのクラスターのClusterGroupUpgrade
CR を削除するだけで再開することができます。-
- Waves
PolicyGenTemplate
CR から生成される各ポリシーには、ztp-deploy-wave
アノテーションが含まれます。このアノテーションは、そのポリシーに含まれる各 CR と同じアノテーションに基づいています。wave アノテーションは、自動生成されたClusterGroupUpgrade
CR でポリシーを順序付けするために使用されます。wave アノテーションは、自動生成されたClusterGroupUpgrade
CR 以外には使用されません。注記同じポリシーのすべての CR には
ztp-deploy-wave
アノテーションに同じ設定が必要です。各 CR のこのアノテーションのデフォルト値はPolicyGenTemplate
で上書きできます。ソース CR の wave アノテーションは、ポリシーの wave アノテーションを判別し、設定するために使用されます。このアノテーションは、実行時に生成されるポリシーに含まれるビルドされる各 CR から削除されます。TALM は、wave アノテーションで指定された順序で設定ポリシーを適用します。TALM は、各ポリシーが準拠しているのを待ってから次のポリシーに移動します。各 CR の wave アノテーションは、それらの CR がクラスターに適用されるための前提条件を確実に考慮することが重要である。たとえば、Operator は Operator の設定前後にインストールする必要があります。同様に、Operator 用
CatalogSource
は、Operator 用サブスクリプションの前または同時にウェーブにインストールする必要があります。各 CR のデフォルトの波動値は、これらの前提条件を考慮したものです。複数の CR およびポリシーは同じアンブ番号を共有できます。ポリシーの数を少なくすることで、デプロイメントを高速化し、CPU 使用率を低減させることができます。多くの CR を比較的少なくするのがベストプラクティスです。
各ソース CR でデフォルトの wave 値を確認するには、ztp-site-generate
コンテナーイメージからデプロイメントした out/source-crs
ディレクトリーに対して以下のコマンドを実行します。
$ grep -r "ztp-deploy-wave" out/source-crs
- フェーズラベル
ClusterGroupUpgrade
CR は自動的に作成され、ZTP プロセスの開始時と終了時にManagedCluster
CR をラベルでアノテートするディレクティブが含まれています。インストール後の ZTP 設定開始時には、
ManagedCluster に
ztp-running という
ラベルが貼られています。すべてのポリシーがクラスターに修復され、完全に準拠されると、TALM はztp-running
ラベルを削除し、ztp-done
ラベルを適用します。informDuValidator
ポリシーを使用するデプロイメントでは、クラスターが完全にアプリケーションをデプロイするための準備が整った時点でztp-done
ラベルが適用されます。これには、ZTP が適用される設定 CR のすべての調整および影響が含まれます。ztp-done
ラベルは、TALM によるClusterGroupUpgrade
CR の自動作成に影響します。クラスターの最初の ZTP インストール後は、このラベルを操作しないでください。- リンクされた CR
-
自動的に作成された
ClusterGroupUpgrade
CR には所有者の参照が、そこから派生したManagedCluster
として設定されます。この参照により、ManagedCluster
CR を削除すると、ClusterGroupUpgrade
のインスタンスがサポートされるリソースと共に削除されるようにします。
19.3.2. ZTP を使用したマネージドクラスターのデプロイの概要
Red Hat Advanced Cluster Management (RHACM) は、ゼロタッチプロビジョニング (ZTP) を使用して、単一ノードの OpenShift Container Platform クラスター、3 ノードのクラスター、および標準クラスターをデプロイします。サイト設定データは、Git リポジトリーで OpenShift Container Platform カスタムリソース (CR) として管理します。ZTP は、宣言的な GitOps アプローチを使用して、一度開発すればどこにでもデプロイメントするモデルを使用して、マネージドクラスターをデプロイメントします。
クラスターのデプロイメントには、以下が含まれます。
- ホストオペレーティングシステム (RHCOS) の空のサーバーへのインストール。
- OpenShift Container Platform のデプロイ
- クラスターポリシーおよびサイトサブスクリプションの作成
- サーバーオペレーティングシステムに必要なネットワーク設定を行う
- プロファイル Operator をデプロイし、パフォーマンスプロファイル、PTP、SR-IOV などの必要なソフトウェア関連の設定を実行します。
マネージドサイトのインストールプロセスの概要
マネージドサイトのカスタムリソース (CR) をハブクラスターに適用すると、次のアクションが自動的に実行されます。
- Discovery イメージの ISO ファイルが生成され、ターゲットホストで起動します。
- ISO ファイルがターゲットホストで正常に起動すると、ホストのハードウェア情報が RHACM にレポートされます。
- すべてのホストの検出後に、OpenShift Container Platform がインストールされます。
-
OpenShift Container Platform のインストールが完了すると、ハブは
klusterlet
サービスをターゲットクラスターにインストールします。 - 要求されたアドオンサービスがターゲットクラスターにインストールされている。
マネージドクラスターの Agent
CR がハブクラスター上に作成されると、検出イメージ ISO プロセスが完了します。
ターゲットのベアメタルホストは、vDU アプリケーションワークロードに推奨される単一ノード OpenShift クラスター設定 に記載されているネットワーク、ファームウェア、およびハードウェアの要件を満たす必要があります。
19.3.3. マネージドベアメタルホストシークレットの作成
マネージドベアメタルホストに必要な Secret
カスタムリソース (CR) をハブクラスターに追加します。ZTP パイプラインが Baseboard Management Controller (BMC) にアクセスするためのシークレットと、アシストインストーラーサービスがレジストリーからクラスターインストールイメージを取得するためのシークレットが必要です。
シークレットは、SiteConfig
CR から名前で参照されます。namespace は SiteConfig
namespace と一致する必要があります。
手順
ホスト Baseboard Management Controller (BMC) の認証情報と、OpenShift およびすべてのアドオンクラスター Operator のインストールに必要なプルシークレットを含む YAML シークレットファイルを作成します。
次の YAML をファイル
example-sno-secret.yaml
として保存します。apiVersion: v1 kind: Secret metadata: name: example-sno-bmc-secret namespace: example-sno 1 data: 2 password: <base64_password> username: <base64_username> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: pull-secret namespace: example-sno 3 data: .dockerconfigjson: <pull_secret> 4 type: kubernetes.io/dockerconfigjson
-
example-sno-secret.yaml
への相対パスを、クラスターのインストールに使用するkustomization.yaml
ファイルに追加します。
19.3.4. SiteConfig と ZTP を使用したマネージドクラスターのデプロイ
次の手順を使用して、SiteConfig
カスタムリソース (CR) と関連ファイルを作成し、ゼロタッチプロビジョニング (ZTP) クラスターのデプロイメントを開始します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていることを確認します。 - 必要なインストール CR とポリシー CR を生成するためにハブクラスターを設定している。
カスタムサイトの設定データを管理する Git リポジトリーを作成しています。リポジトリーはハブクラスターからアクセスできる必要があり、ArgoCD アプリケーションのソースリポジトリーとして設定する必要があります。詳細は、「GitOps ZTP サイト設定リポジトリーの準備」を参照してください。
注記ソースリポジトリーを作成するときは、
ztp-site-generate
コンテナーから抽出したargocd/deployment/argocd-openshift-gitops-patch.json
パッチファイルを使用して ArgoCD アプリケーションにパッチを適用してください。「ArgoCD を使用したハブクラスターの設定」を参照してください。マネージドクラスターをプロビジョニングする準備を整えるには、各ベアメタルホストごとに次のものが必要です。
- ネットワーク接続
- ネットワークには DNS が必要です。マネージドクラスターホストは、ハブクラスターから到達可能である必要があります。ハブクラスターとマネージドクラスターホストの間にレイヤー 3 接続が存在することを確認します。
- Baseboard Management Controller (BMC) の詳細
-
ZTP は、BMC のユーザー名とパスワードの詳細を使用して、クラスターのインストール中に BMC に接続します。GitOps ZTP プラグインは、サイトの Git リポジトリーの
SiteConfig
CR に基づいて、ハブクラスター上のManagedCluster
CR を管理します。ホストごとに個別のBMCSecret
CR を手動で作成します。
手順
ハブクラスターで必要なマネージドクラスターシークレットを作成します。これらのリソースは、クラスター名と一致する名前を持つネームスペースに存在する必要があります。たとえば、
out/argocd/example/siteconfig/example-sno.yaml
では、クラスター名と namespace がexample-sno
になっています。次のコマンドを実行して、クラスター namespace をエクスポートします。
$ export CLUSTERNS=example-sno
namespace を作成します。
$ oc create namespace $CLUSTERNS
マネージドクラスターのプルシークレットと BMC
Secret
CR を作成します。プルシークレットには、OpenShift Container Platform のインストールに必要なすべての認証情報と、必要なすべての Operator を含める必要があります。詳細は、「マネージドベアメタルホストシークレットの作成」を参照してください。注記シークレットは、名前で
SiteConfig
カスタムリソース (CR) から参照されます。namespace はSiteConfig
namespace と一致する必要があります。Git リポジトリーのローカルクローンに、クラスターの
SiteConfig
CR を作成します。out/argocd/example/siteconfig/
フォルダーから CR の適切な例を選択します。フォルダーには、単一ノード、3 ノード、標準クラスターのサンプルファイルが含まれます。-
example-sno.yaml
-
example-3node.yaml
-
example-standard.yaml
-
サンプルファイルのクラスターおよびホスト詳細を、必要なクラスタータイプに一致するように変更します。以下に例を示します。
単一ノードの OpenShift クラスター SiteConfig CR の例
apiVersion: ran.openshift.io/v1 kind: SiteConfig metadata: name: "<site_name>" namespace: "<site_name>" spec: baseDomain: "example.com" pullSecretRef: name: "assisted-deployment-pull-secret" 1 clusterImageSetNameRef: "openshift-4.10" 2 sshPublicKey: "ssh-rsa AAAA..." 3 clusters: - clusterName: "<site_name>" networkType: "OVNKubernetes" clusterLabels: 4 common: true group-du-sno: "" sites : "<site_name>" clusterNetwork: - cidr: 1001:1::/48 hostPrefix: 64 machineNetwork: - cidr: 1111:2222:3333:4444::/64 serviceNetwork: - 1001:2::/112 additionalNTPSources: - 1111:2222:3333:4444::2 #crTemplates: # KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5 nodes: - hostName: "example-node.example.com" 6 role: "master" #biosConfigRef: # filePath: "example-hw.profile" 7 bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 8 bmcCredentialsName: name: "bmh-secret" 9 bootMACAddress: "AA:BB:CC:DD:EE:11" bootMode: "UEFI" 10 rootDeviceHints: wwn: "0x11111000000asd123" cpuset: "0-1,52-53" nodeNetwork: 11 interfaces: - name: eno1 macAddress: "AA:BB:CC:DD:EE:11" config: interfaces: - name: eno1 type: ethernet state: up ipv4: enabled: false ipv6: 12 enabled: true address: - ip: 1111:2222:3333:4444::aaaa:1 prefix-length: 64 dns-resolver: config: search: - example.com server: - 1111:2222:3333:4444::2 routes: config: - destination: ::/0 next-hop-interface: eno1 next-hop-address: 1111:2222:3333:4444::1 table-id: 254
- 1
SiteConfig
CR と同じ namespace を使用して、assisted-deployment-pull-secret
CR を作成します。- 2
clusterImageSetNameRef
は、ハブクラスターで使用可能なイメージセットを定義します。ハブクラスターでサポートされるバージョンの一覧を表示するには、oc get clusterimagesets
を実行します。- 3
- クラスターへのアクセスに使用する SSH 公開鍵を設定します。
- 4
- クラスターラベルは、定義した
PolicyGenTemplate
CR のbindingRules
フィールドに対応している必要があります。たとえば、policygentemplates/common-ranGen.yaml
はcommon: true
が設定されたすべてのクラスターに適用され、policygentemplates/group-du-sno-ranGen.yaml
はgroup-du-sno: ""
が設定されたすべてのクラスターに適用されます。 - 5
- オプション:
KlusterletAddonConfig
で指定された CR は、クラスター用に作成されたデフォルトのKlusterletAddonConfig
をオーバーライドするために使用されます。 - 6
- 単一ノードの導入では、単一のホストを定義します。3 ノードのデプロイメントの場合、3 台のホストを定義します。標準のデプロイメントでは、
role: master
と、role: worker
で定義される 2 つ以上のホストを持つ 3 つのホストを定義します。 - 7
- オプション:
biosConfigRef
を使用して、ホストに必要なファームウェアを設定します。 - 8
- すべてのクラスタータイプに適用されます。BMC アドレスを指定します。
- 9
- BMC 認証情報を指定する
bmh-secret
CR を作成します。SiteConfig
CR と同じ namespace を使用します。 - 10
UEFISecureBoot
を使用して、ホストでセキュアブートを有効にします。- 11
- ノードのネットワーク設定を指定します。
- 12
- ホストの IPv6 アドレスを設定します。静的 IP アドレスを持つ単一ノードの OpenShift クラスターの場合、ノード固有の API と Ingress IP は同じである必要があります。
注記BMC アドレッシングの詳細については、「関連情報」セクションを参照してください。
-
out/argocd/extra-manifest
で extra-manifestMachineConfig
CR のデフォルトセットを検査できます。これは、インストール時にクラスターに自動的に適用されます。 -
オプション: プロビジョニングされたクラスターに追加のインストール時マニフェストをプロビジョニングするには、Git リポジトリーに
sno-extra-manifest/
などのディレクトリーを作成し、このディレクトリーにカスタムマニフェストの CR を追加します。SiteConfig.yaml
がextraManifestPath
フィールドでこのディレクトリーを参照する場合、この参照ディレクトリーの CR はすべて、デフォルトの追加マニフェスト セットに追加されます。
-
out/argocd/example/siteconfig/kustomization.yaml
に示す例のように、generators
セクションのkustomization.yaml
ファイルにSiteConfig
CR を追加してください。 SiteConfig
CR と関連するkustomization.yaml
の変更を Git リポジトリーにコミットし、変更をプッシュします。ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。
19.3.5. マネージドクラスターのインストールの進行状況の監視
ArgoCD パイプラインは、SiteConfig
CR を使用してクラスター設定 CR を生成し、それをハブクラスターと同期します。ArgoCD ダッシュボードでこの同期の進捗をモニターできます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていることを確認します。
手順
同期が完了すると、インストールは一般的に以下のように行われます。
Assisted Service Operator は OpenShift Container Platform をクラスターにインストールします。次のコマンドを実行して、RHACM ダッシュボードまたはコマンドラインからクラスターのインストールの進行状況を監視できます。
クラスター名をエクスポートします。
$ export CLUSTER=<clusterName>
マネージドクラスターの
AgentClusterInstall
CR をクエリーします。$ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq
クラスターのインストールイベントを取得します。
$ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}') | jq '.[-2,-1]'
19.3.6. インストール CR の検証による GitOps ZTP のトラブルシューティング
ArgoCD パイプラインは SiteConfig
と PolicyGenTemplate
カスタムリソース (CR) を使用して、クラスター設定 CR と Red Hat Advanced Cluster Management (RHACM) ポリシーを生成します。以下の手順に従って、このプロセス時に発生する可能性のある問題のトラブルシューティングを行います。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていることを確認します。
手順
インストール CR が作成されたことは、以下のコマンドで確認することができます。
$ oc get AgentClusterInstall -n <cluster_name>
オブジェクトが返されない場合は、以下の手順を使用して ArgoCD パイプラインフローを
SiteConfig
ファイルからインストール CR にトラブルシューティングします。ハブクラスターで
SiteConfig
CR を使用してManagedCluster
CR が生成されたことを確認します。$ oc get managedcluster
ManagedCluster
が見つからない場合は、clusters
アプリケーションが Git リポジトリーからハブクラスターへのファイルの同期に失敗したかどうかを確認します。$ oc describe -n openshift-gitops application clusters
Status.Conditions
フィールドを確認して、マネージドクラスターのエラーログを表示します。たとえば、SiteConfig
CR でextraManifestPath:
に無効な値を設定すると、次のエラーが発生します。Status: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1 Type: ComparisonError
Status.Sync
フィールドを確認します。ログエラーがある場合、Status.Sync
フィールドはUnknown
エラーを示している可能性があります。Status: Sync: Compared To: Destination: Namespace: clusters-sub Server: https://kubernetes.default.svc Source: Path: sites-config Repo URL: https://git.com/ran-sites/siteconfigs/.git Target Revision: master Status: Unknown
19.3.7. ZTP パイプラインからマネージドクラスターサイトを削除
ZTP パイプラインから、マネージドサイトと、関連するインストールおよび設定ポリシーの CR を削除できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていることを確認します。
手順
関連する
SiteConfig
ファイルとPolicyGenTemplate
ファイルをkustomization.yaml
ファイルから削除して、サイトと関連する CR を削除します。ZTP パイプラインを再度実行すると、生成された CR が削除されます。
-
任意: サイトを永続的に削除する場合は、Git リポジトリーから
SiteConfig
ファイルおよびサイト固有のPolicyGenTemplate
ファイルも削除する必要があります。 -
任意: たとえば、サイトを再デプロイする際にサイトを一時的に削除する場合には、Git リポジトリーに
SiteConfig
およびサイト固有のPolicyGenTemplate
CR を残しておくことができます。
Git リポジトリーから SiteConfig
ファイルを削除した後、対応するクラスターがデタッチプロセスで停止する場合は、デタッチされたクラスターのクリーンアップに関する情報について、ハブクラスターの Red Hat Advanced Cluster Management (RHACM) を確認してください。
関連情報
- クラスターの削除は、管理からクラスターを削除する を参照してください。
19.3.8. 古いコンテンツを ZTP パイプラインから削除する
ポリシーの名前を変更した場合など、PolicyGenTemplate
設定を変更した結果、古いポリシーが作成された場合は、次の手順を使用して古いポリシーを削除します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていることを確認します。
手順
-
Git リポジトリーから影響を受ける
PolicyGenTemplate
ファイルを削除し、コミットしてリモートリポジトリーにプッシュしてください。 - アプリケーションを介して変更が同期され、影響を受けるポリシーがハブクラスターから削除されるのを待ちます。
更新された
PolicyGenTemplate
ファイルを Git リポジトリーに再び追加し、リモートリポジトリーにコミットし、プッシュします。注記Git リポジトリーからゼロタッチプロビジョニング (ZTP) ポリシーを削除し、その結果、ハブクラスターからもポリシーを削除しても、マネージドクラスターの設定には影響しません。ポリシーとそのポリシーによって管理される CR は、マネージドクラスターに残ります。
任意: 別の方法として、
PolicyGenTemplate
CR に変更を加えて古いポリシーを作成した後、これらのポリシーをハブクラスターから手動で削除することができます。ポリシーの削除は、RHACM コンソールから Governance タブを使用するか、以下のコマンドを使用して行うことができます。$ oc delete policy -n <namespace> <policy_name>
19.3.9. ZTP パイプラインの解体
ArgoCD パイプラインと生成されたすべての ZTP アーティファクトを削除できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてクラスターにログインしていることを確認します。
手順
- ハブクラスターの Red Hat Advanced Cluster Management (RHACM) からすべてのクラスターを切り離します。
次のコマンドを使用して、
deployment
ディレクトリーのkustomization.yaml
ファイルを削除します。$ oc delete -k out/argocd/deployment
- 変更をコミットして、サイトリポジトリーにプッシュします。