4.5. SiteConfig と GitOps ZTP を使用したマネージドクラスターのデプロイ
次の手順を使用して、SiteConfig
カスタムリソース (CR) と関連ファイルを作成し、GitOps Zero Touch Provisioning (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) の詳細
-
GitOps 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
$ export CLUSTERNS=example-sno
Copy to Clipboard Copied! Toggle word wrap Toggle overflow namespace を作成します。
oc create namespace $CLUSTERNS
$ oc create namespace $CLUSTERNS
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
マネージドクラスターのプルシークレットと 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 の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。この例では、読みやすくするために、
installConfigOverrides
フィールドとignitionConfigOverride
フィールドが展開されています。-
out/argocd/extra-manifest
で extra-manifestMachineConfig
CR のデフォルトセットを検査できます。これは、インストール時にクラスターに自動的に適用されます。 オプション: プロビジョニングされたクラスターに追加のインストール時マニフェストをプロビジョニングするには、Git リポジトリーに
sno-extra-manifest/
などのディレクトリーを作成し、このディレクトリーにカスタムマニフェストの CR を追加します。SiteConfig.yaml
がextraManifestPath
フィールドでこのディレクトリーを参照する場合、この参照ディレクトリーの CR はすべて、デフォルトの追加マニフェストセットに追加されます。crun OCI コンテナーランタイムの有効化クラスターのパフォーマンスを最適化するには、シングルノード OpenShift、追加のワーカーノードを備えたシングルノード OpenShift、3 ノード OpenShift、および標準クラスターのマスターノードとワーカーノードで crun を有効にします。
クラスターの再起動を回避するには、追加の Day 0 インストール時マニフェストとして
ContainerRuntimeConfig
CR で crun を有効にします。enable-crun-master.yaml
およびenable-crun-worker.yaml
CR ファイルは、ztp-site-generate
コンテナーから抽出できるout/source-crs/optional-extra-manifest/
フォルダーにあります。詳細は、「GitOps ZTP パイプラインでの追加インストールマニフェストのカスタマイズ」を参照してください。
-
out/argocd/example/siteconfig/kustomization.yaml
に示す例のように、generators
セクションのkustomization.yaml
ファイルにSiteConfig
CR を追加してください。 SiteConfig
CR と関連するkustomization.yaml
の変更を Git リポジトリーにコミットし、変更をプッシュします。ArgoCD パイプラインが変更を検出し、マネージドクラスターのデプロイを開始します。
検証
ノードのデプロイ後にカスタムのロールとラベルが適用されていることを確認します。
oc describe node example-node.example.com
$ oc describe node example-node.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
出力例
- 1
- カスタムラベルがノードに適用されます。
4.5.1. シングルノード OpenShift SiteConfig CR インストールリファレンス リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig CR フィールド | 説明 |
---|---|
|
注記
|
|
|
|
サイト内のすべてのクラスターのハブクラスターで使用できるイメージセットを設定します。ハブクラスターでサポートされるバージョンの一覧を表示するには、 |
|
クラスターのインストール前に、 重要
|
|
個々のクラスターをデプロイするために使用されるクラスターイメージセットを指定します。定義されている場合、サイトレベルで |
|
定義した |
|
オプション: |
|
シングルノードの導入では、単一のホストを定義します。3 ノードのデプロイメントの場合、3 台のホストを定義します。標準のデプロイメントでは、 |
| マネージドクラスター内のノードのカスタムロールを指定します。これらは追加のロールであり、OpenShift Container Platform コンポーネントでは使用されず、ユーザーによってのみ使用されます。カスタムロールを追加すると、そのロールの特定の設定を参照するカスタムマシン設定プールに関連付けることができます。インストール中にカスタムラベルまたはロールを追加すると、デプロイメントプロセスがより効率的になり、インストール完了後に追加の再起動が必要なくなります。 |
|
オプション: コメントを解除して値を |
| ホストへのアクセスに使用する BMC アドレス。すべてのクラスタータイプに適用されます。GitOps ZTP は、Redfish または IPMI プロトコルを使用して iPXE および仮想メディアの起動をサポートします。iPXE ブートを使用するには、RHACM 2.8 以降を使用する必要があります。BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。 |
| ホストへのアクセスに使用する BMC アドレス。すべてのクラスタータイプに適用されます。GitOps ZTP は、Redfish または IPMI プロトコルを使用して iPXE および仮想メディアの起動をサポートします。iPXE ブートを使用するには、RHACM 2.8 以降を使用する必要があります。BMC アドレッシングの詳細は、「関連情報」セクションを参照してください。 注記 ファーエッジ通信会社のユースケースでは、GitOps ZTP では仮想メディアの使用のみがサポートされます。 |
|
ホスト BMC 認証情報を使用して、別途作成した |
|
ホストのブートモードを |
|
導入するデバイスを指定します。再起動後も安定した識別子が推奨されます。たとえば、 |
| オプション: このフィールドを使用して、永続ストレージのパーティションを割り当てます。ディスク ID とサイズを特定のハードウェアに合わせて調整します。 |
| ノードのネットワーク設定を行います。 |
| ホストの IPv6 アドレスを設定します。静的 IP アドレスを持つシングルノード OpenShift クラスターの場合、ノード固有の API と Ingress IP は同じである必要があります。 |