19.5. ZTP を使用した単一ノード OpenShift クラスターの手動インストール
Red Hat Advanced Cluster Management (RHACM) とアシストサービスを使用して、管理対象の単一ノード OpenShift クラスターをデプロイできます。
複数のマネージドクラスターを作成する場合は、ZTP を使用したファーエッジサイトのデプロイメント で説明されている SiteConfig メソッドを使用します。
ターゲットのベアメタルホストは、vDU アプリケーションワークロードの推奨クラスター設定 に記載されているネットワーク、ファームウェア、およびハードウェアの要件を満たす必要があります。
19.5.1. ZTP のインストールと設定の CR を手動で生成する リンクのコピーリンクがクリップボードにコピーされました!
ztp-site-generate コンテナーの generator エントリーポイントを使用して、SiteConfig および PolicyGenTemplate CR に基づいてクラスターのサイトインストールおよび設定カスタムリソース (CR) を生成します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてハブクラスターにログインしている。
手順
次のコマンドを実行して、出力フォルダーを作成します。
$ mkdir -p ./outztp-site-generateコンテナーイメージからargocdディレクトリーをエクスポートします。$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12 extract /home/ztp --tar | tar x -C ./out./outディレクトリーのout/argocd/example/フォルダーには、参照PolicyGenTemplateCR およびSiteConfigCR があります。出力例
out └── argocd └── 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サイトインストール CR の出力フォルダーを作成します。
$ mkdir -p ./site-installインストールするクラスタータイプのサンプル
SiteConfigCR を変更します。example-sno.yamlをsite-1-sno.yamlにコピーし、インストールするサイトとベアメタルホストの詳細に一致するように CR を変更します。次に例を示します。単一ノードの 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.12"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" bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/7 bmcCredentialsName: name: "bmh-secret"8 bootMACAddress: "AA:BB:CC:DD:EE:11" bootMode: "UEFI"9 rootDeviceHints: wwn: "0x11111000000asd123" cpuset: "0-1,52-53"10 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
SiteConfigCR と同じ namespace を使用して、assisted-deployment-pull-secretCR を作成します。- 2
clusterImageSetNameRefは、ハブクラスターで使用可能なイメージセットを定義します。ハブクラスターでサポートされるバージョンの一覧を表示するには、oc get clusterimagesetsを実行します。- 3
- クラスターへのアクセスに使用する SSH 公開鍵を設定します。
- 4
- クラスターラベルは、定義した
PolicyGenTemplateCR の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
- ホストへのアクセスに使用する BMC アドレス。すべてのクラスタータイプに適用されます。
- 8
- ホスト BMC クレデンシャルを使用して個別に作成する
bmh-secretCR の名前。bmh-secretCR を作成するときは、ホストをプロビジョニングするSiteConfigCR と同じ namespace を使用します。 - 9
- ホストのブートモードを設定します。デフォルト値は
UEFIです。UEFISecureBootを使用して、ホストでセキュアブートを有効にします。 - 10
cpusetは、ワークロードの分割のためにクラスターのPerformanceProfileCR.spec.cpu.reservedフィールドに設定された値と同じにする必要があります。- 11
- ノードのネットワーク設定を指定します。
- 12
- ホストの IPv6 アドレスを設定します。静的 IP アドレスを持つ単一ノードの OpenShift クラスターの場合、ノード固有の API と Ingress IP は同じである必要があります。
次のコマンドを実行して、変更された
SiteConfigCRsite-1-sno.yamlを処理し、day-0 インストール CR を生成します。$ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator install site-1-sno.yaml /output出力例
site-install └── site-1-sno ├── site-1_agentclusterinstall_example-sno.yaml ├── site-1-sno_baremetalhost_example-node1.example.com.yaml ├── site-1-sno_clusterdeployment_example-sno.yaml ├── site-1-sno_configmap_example-sno.yaml ├── site-1-sno_infraenv_example-sno.yaml ├── site-1-sno_klusterletaddonconfig_example-sno.yaml ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml ├── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml ├── site-1-sno_managedcluster_example-sno.yaml ├── site-1-sno_namespace_example-sno.yaml └── site-1-sno_nmstateconfig_example-node1.example.com.yamlオプション:
-Eオプションを使用して参照SiteConfigCR を処理することにより、特定のクラスタータイプの day-0MachineConfigインストール CR のみを生成します。たとえば、以下のコマンドを実行します。MachineConfigCR の出力フォルダーを作成します。$ mkdir -p ./site-machineconfigMachineConfigインストール CR を生成します。$ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator install -E site-1-sno.yaml /output出力例
site-machineconfig └── site-1-sno ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml
前のステップの参照
PolicyGenTemplateCR を使用して、day-2 の設定 CR を生成してエクスポートします。以下のコマンドを実行します。day-2 CR の出力フォルダーを作成します。
$ mkdir -p ./refday-2 設定 CR を生成してエクスポートします。
$ podman run -it --rm -v `pwd`/out/argocd/example/policygentemplates:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator config -N . /outputこのコマンドは、単一ノード OpenShift、3 ノードクラスター、および標準クラスター用のサンプルグループおよびサイト固有の
PolicyGenTemplateCR を./refフォルダーに生成します。出力例
ref └── customResource ├── common ├── example-multinode-site ├── example-sno ├── group-du-3node ├── group-du-3node-validator │ └── Multiple-validatorCRs ├── group-du-sno ├── group-du-sno-validator ├── group-du-standard └── group-du-standard-validator └── Multiple-validatorCRs
- クラスターのインストールに使用する CR のベースとして、生成された CR を使用します。「単一のマネージドクラスターのインストール」で説明されているように、インストール CR をハブクラスターに適用します。設定 CR は、クラスターのインストールが完了した後にクラスターに適用できます。
19.5.2. マネージドベアメタルホストシークレットの作成 リンクのコピーリンクがクリップボードにコピーされました!
マネージドベアメタルホストに必要な 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-sno1 data:2 password: <base64_password> username: <base64_username> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: pull-secret namespace: example-sno3 data: .dockerconfigjson: <pull_secret>4 type: kubernetes.io/dockerconfigjson
-
example-sno-secret.yamlへの相対パスを、クラスターのインストールに使用するkustomization.yamlファイルに追加します。
19.5.3. GitOps ZTP を使用した手動インストール用の Discovery ISO カーネル引数の設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP ワークフローは、マネージドベアメタルホストでの OpenShift Container Platform インストールプロセスの一部として Discovery ISO を使用します。InfraEnv リソースを編集して、Discovery ISO のカーネル引数を指定できます。これは、特定の環境要件を持つクラスターのインストールに役立ちます。たとえば、Discovery ISO の rd.net.timeout.carrier カーネル引数を設定して、クラスターの静的ネットワーク設定を容易にしたり、インストール中に root ファイルシステムをダウンロードする前に DHCP アドレスを受信したりできます。
OpenShift Container Platform 4.12 では、カーネル引数の追加のみを行うことができます。カーネル引数を置き換えたり削除したりすることはできません。
前提条件
- OpenShift CLI (oc) がインストールされている。
- cluster-admin 権限を持つユーザーとしてハブクラスターにログインしている。
- インストールと設定カスタムリソース (CR) を手動で生成している。
手順
-
InfraEnvCR のspec.kernelArguments仕様を編集して、カーネル引数を設定します。
apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
name: <cluster_name>
namespace: <cluster_name>
spec:
kernelArguments:
- operation: append
value: audit=0
- operation: append
value: trace=1
clusterRef:
name: <cluster_name>
namespace: <cluster_name>
pullSecretRef:
name: pull-secret
SiteConfig CR は、Day-0 インストール CR の一部として InfraEnv リソースを生成します。
検証
カーネル引数が適用されていることを確認するには、Discovery イメージが OpenShift Container Platform をインストールする準備ができていることを確認した後、インストールプロセスを開始する前にターゲットホストに SSH 接続します。その時点で、/proc/cmdline ファイルで Discovery ISO のカーネル引数を表示できます。
ターゲットホストとの SSH セッションを開始します。
$ ssh -i /path/to/privatekey core@<host_name>次のコマンドを使用して、システムのカーネル引数を表示します。
$ cat /proc/cmdline
19.5.4. 単一のマネージドクラスターのインストール リンクのコピーリンクがクリップボードにコピーされました!
アシストサービスと Red Hat Advanced Cluster Management (RHACM) を使用して、単一のマネージドクラスターを手動でデプロイできます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてハブクラスターにログインしている。 -
ベースボード管理コントローラー (BMC)
SecretとイメージプルシークレットSecretカスタムリソース (CR) を作成しました。詳細は、「管理されたベアメタルホストシークレットの作成」を参照してください。 - ターゲットのベアメタルホストが、マネージドクラスターのネットワークとハードウェアの要件を満たしている。
手順
デプロイする特定のクラスターバージョンごとに
ClusterImageSetを作成します (例:clusterImageSet-4.12.yaml)。ClusterImageSetのフォーマットは以下のとおりです。apiVersion: hive.openshift.io/v1 kind: ClusterImageSet metadata: name: openshift-4.12.01 spec: releaseImage: quay.io/openshift-release-dev/ocp-release:4.12.0-x86_642 clusterImageSetCR を適用します。$ oc apply -f clusterImageSet-4.12.yamlcluster-namespace.yamlファイルにNamespaceCR を作成します。apiVersion: v1 kind: Namespace metadata: name: <cluster_name>1 labels: name: <cluster_name>2 以下のコマンドを実行して
NamespaceCR を適用します。$ oc apply -f cluster-namespace.yamlztp-site-generateコンテナーから抽出し、要件を満たすようにカスタマイズした、生成された day-0 CR を適用します。$ oc apply -R ./site-install/site-sno-1
19.5.5. マネージドクラスターのインストールステータスの監視 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのステータスをチェックして、クラスターのプロビジョニングが正常に行われたことを確認します。
前提条件
-
すべてのカスタムリソースが設定およびプロビジョニングされ、プロビジョニングされ、マネージドクラスターのハブで
Agentカスタムリソースが作成されます。
手順
マネージドクラスターのステータスを確認します。
$ oc get managedclusterTrueはマネージドクラスターの準備が整っていることを示します。エージェントのステータスを確認します。
$ oc get agent -n <cluster_name>describeコマンドを使用して、エージェントの条件に関する詳細な説明を指定します。認識できるステータスには、BackendError、InputError、ValidationsFailing、InstallationFailed、およびAgentIsConnectedが含まれます。これらのステータスは、AgentおよびAgentClusterInstallカスタムリソースに関連します。$ oc describe agent -n <cluster_name>クラスターのプロビジョニングのステータスを確認します。
$ oc get agentclusterinstall -n <cluster_name>describeコマンドを使用して、クラスターのプロビジョニングステータスの詳細な説明を指定します。$ oc describe agentclusterinstall -n <cluster_name>マネージドクラスターのアドオンサービスのステータスを確認します。
$ oc get managedclusteraddon -n <cluster_name>マネージドクラスターの
kubeconfigファイルの認証情報を取得します。$ oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig
19.5.6. マネージドクラスターのトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
以下の手順を使用して、マネージドクラスターで発生する可能性のあるインストール問題を診断します。
手順
マネージドクラスターのステータスを確認します。
$ oc get managedcluster出力例
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE SNO-cluster true True True 2d19hAVAILABLE列のステータスがTrueの場合、マネージドクラスターはハブによって管理されます。AVAILABLE列のステータスがUnknownの場合、マネージドクラスターはハブによって管理されていません。その他の情報を取得するには、以下の手順を使用します。AgentClusterInstallインストールのステータスを確認します。$ oc get clusterdeployment -n <cluster_name>出力例
NAME PLATFORM REGION CLUSTERTYPE INSTALLED INFRAID VERSION POWERSTATE AGE Sno0026 agent-baremetal false Initialized 2d14hINSTALLED列のステータスがfalseの場合、インストールは失敗していました。インストールが失敗した場合は、以下のコマンドを実行して
AgentClusterInstallリソースのステータスを確認します。$ oc describe agentclusterinstall -n <cluster_name> <cluster_name>エラーを解決し、クラスターをリセットします。
クラスターのマネージドクラスターリソースを削除します。
$ oc delete managedcluster <cluster_name>クラスターの namespace を削除します。
$ oc delete namespace <cluster_name>これにより、このクラスター用に作成された namespace スコープのカスタムリソースがすべて削除されます。続行する前に、
ManagedClusterCR の削除が完了するのを待つ必要があります。- マネージドクラスターのカスタムリソースを再作成します。
19.5.7. RHACM によって生成されたクラスターインストール CR リファレンス リンクのコピーリンクがクリップボードにコピーされました!
Red Hat Advanced Cluster Management (RHACM) は、サイトごとに SiteConfig CR を使用して生成する特定のインストールカスタムリソース (CR) のセットを使用して、シングルノードクラスター、3 ノードクラスター、および標準クラスターに OpenShift Container Platform をデプロイすることをサポートします。
すべてのマネージドクラスターには独自の namespace があり、ManagedCluster と ClusterImageSet を除くすべてのインストール CR はその namespace の下にあります。ManagedCluster と ClusterImageSet は、ネームスペーススコープではなく、クラスタースコープです。namespace および CR 名はクラスター名に一致します。
次の表に、設定した SiteConfig CR を使用してクラスターをインストールするときに RHACM アシストサービスによって自動的に適用されるインストール CR を示します。
| CR | 説明 | 使用法 |
|---|---|---|
|
| ターゲットのベアメタルホストの Baseboard Management Controller (BMC) の接続情報が含まれています。 | Redfish プロトコルを使用して、BMC へのアクセスを提供し、ターゲットサーバーで検出イメージをロードおよび開始します。 |
|
| ターゲットのベアメタルホストに OpenShift Container Platform をインストールするための情報が含まれています。 |
|
|
|
ネットワークやコントロールプレーンノードの数など、マネージドクラスター設定の詳細を指定します。インストールが完了すると、クラスター | マネージドクラスターの設定情報を指定し、クラスターのインストール時にステータスを指定します。 |
|
|
使用する |
マネージドクラスターの Discovery ISO を生成するために |
|
|
| マネージドクラスターの Kube API サーバーの静的 IP アドレスを設定します。 |
|
| ターゲットのベアメタルホストに関するハードウェア情報が含まれています。 | ターゲットマシンの検出イメージの起動時にハブ上に自動的に作成されます。 |
|
| クラスターがハブで管理されている場合は、インポートして知られている必要があります。この Kubernetes オブジェクトはそのインターフェイスを提供します。 | ハブは、このリソースを使用してマネージドクラスターのステータスを管理し、表示します。 |
|
|
|
|
|
|
ハブ上にある |
リソースを |
|
|
|
|
|
| リポジトリーおよびイメージ名などの OpenShift Container Platform イメージ情報が含まれます。 | OpenShift Container Platform イメージを提供するためにリソースに渡されます。 |