19.13. GitOps ZTP を使用した単一ノードの OpenShift クラスターの拡張
GitOps ZTP を使用して、単一ノードの OpenShift クラスターを拡張できます。単一ノードの OpenShift クラスターにワーカーノードを追加すると、元の単一ノードの OpenShift クラスターがコントロールプレーンノードのロールを保持します。ワーカーノードを追加しても、既存のシングルノード OpenShift クラスターのダウンタイムは必要ありません。
シングルノード OpenShift クラスターに追加できるワーカーノードの数に指定された制限はありませんが、追加のワーカーノード用にコントロールプレーンノードで予約されている CPU 割り当てを再評価する必要があります。
ワーカーノードでワークロードパーティショニングが必要な場合は、ノードをインストールする前に、ハブクラスターでマネージドクラスターポリシーをデプロイして修復する必要があります。そうすることで、GitOps ZTP ワークフローが MachineConfig
イグニッションファイルをワーカーノードに適用する前に、ワークロードパーティショニング MachineConfig
オブジェクトがレンダリングされ、worker
マシン設定プールに関連付けられます。
最初にポリシーを修復してから、ワーカーノードをインストールすることを推奨します。ワーカーノードのインストール後にワークロードパーティショニングマニフェストを作成する場合は、ノードを手動でドレインし、デーモンセットによって管理されるすべての Pod を削除する必要があります。管理デーモンセットが新しい Pod を作成すると、新しい Pod はワークロードパーティショニングプロセスを実行します。
GitOps ZTP を使用したシングルノード OpenShift クラスターへのワーカーノードの追加は、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
19.13.1. ワーカーノードへのプロファイルの適用 リンクのコピーリンクがクリップボードにコピーされました!
DU プロファイルを使用して、追加のワーカーノードを設定できます。
ZTP GitOps 共通、グループ、およびサイト固有の PolicyGenTemplate
リソースを使用して、RAN 分散ユニット (DU) プロファイルをワーカーノードクラスターに適用できます。ArgoCD policies
アプリケーションにリンクされている GitOps ZTP パイプラインには、ztp-site-generate
コンテナーを抽出するときに out/argocd/example/policygentemplates
フォルダーにある次の CR が含まれています。
-
common-ranGen.yaml
-
group-du-sno-ranGen.yaml
-
example-sno-site.yaml
-
ns.yaml
-
kustomization.yaml
ワーカーノードでの DU プロファイルの設定は、アップグレードと見なされます。アップグレードフローを開始するには、既存のポリシーを更新するか、追加のポリシーを作成する必要があります。次に、ClusterGroupUpgrade
CR を作成して、クラスターのグループ内のポリシーを調整する必要があります。
19.13.2. (オプション) PTP および SR-IOV デーモンセレクターの互換性の確保 リンクのコピーリンクがクリップボードにコピーされました!
DU プロファイルが GitOps ZTP プラグインバージョン 4.11 以前を使用してデプロイされた場合、PTP および SR-IOV Operator は、master
というラベルの付いたノードにのみデーモンを配置するように設定されている可能性があります。この設定により、PTP および SR-IOV デーモンがワーカーノードで動作しなくなります。システムで PTP および SR-IOV デーモンノードセレクターが正しく設定されていない場合は、ワーカー DU プロファイル設定に進む前にデーモンを変更する必要があります。
手順
スポーククラスターの 1 つで PTP Operator のデーモンノードセレクター設定を確認します。
oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jq
$ oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PTP Operator の出力例
{"daemonNodeSelector":{"node-role.kubernetes.io/master":""}}
{"daemonNodeSelector":{"node-role.kubernetes.io/master":""}}
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ノードセレクターが
master
に設定されている場合、スポークは、変更が必要なバージョンの ZTP プラグインでデプロイされています。
スポーククラスターの 1 つで SR-IOV Operator のデーモンノードセレクター設定を確認します。
oc get sriovoperatorconfig/default -n \ openshift-sriov-network-operator -ojsonpath='{.spec}' | jq
$ oc get sriovoperatorconfig/default -n \ openshift-sriov-network-operator -ojsonpath='{.spec}' | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Operator の出力例
{"configDaemonNodeSelector":{"node-role.kubernetes.io/worker":""},"disableDrain":false,"enableInjector":true,"enableOperatorWebhook":true}
{"configDaemonNodeSelector":{"node-role.kubernetes.io/worker":""},"disableDrain":false,"enableInjector":true,"enableOperatorWebhook":true}
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ノードセレクターが
master
に設定されている場合、スポークは、変更が必要なバージョンの ZTP プラグインでデプロイされています。
グループポリシーで、次の
ComplianceType
およびspec
エントリーを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要daemonNodeSelector
フィールドを変更すると、一時的な PTP 同期が失われ、SR-IOV 接続が失われます。- Git で変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。
19.13.3. PTP および SR-IOV ノードセレクターの互換性 リンクのコピーリンクがクリップボードにコピーされました!
PTP 設定リソースと SR-IOV ネットワークノードポリシーは、ノードセレクターとして node-role.kubernetes.io/master: ""
を使用します。追加のワーカーノードの NIC 設定がコントロールプレーンノードと同じである場合、コントロールプレーンノードの設定に使用されたポリシーをワーカーノードに再利用できます。ただし、両方のノードタイプを選択するようにノードセレクターを変更する必要があります (たとえば、node-role.kubernetes.io/worker
ラベルを使用)。
19.13.4. PolicyGenTemplate CR を使用してワーカーノードポリシーをワーカーノードに適用する リンクのコピーリンクがクリップボードにコピーされました!
ワーカーノードのポリシーを作成できます。
手順
次のポリシーテンプレートを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 汎用の
MachineConfig
CR を使用して、ワーカーノードでワークロードパーティションを設定します。crio
およびkubelet
設定ファイルのコンテンツを生成できます。-
作成したポリシーテンプレートを、ArgoCD
policies
アプリケーションによってモニターされている Git リポジトリーに追加します。 -
ポリシーを
kustomization.yaml
ファイルに追加します。 - Git で変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。
新しいポリシーをスポーククラスターに修復するには、TALM カスタムリソースを作成します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.13.5. GitOps ZTP を使用してシングルノード OpenShift クラスターにワーカーノードを追加する リンクのコピーリンクがクリップボードにコピーされました!
1 つ以上のワーカーノードを既存のシングルノード OpenShift クラスターに追加して、クラスターで使用可能な CPU リソースを増やすことができます。
前提条件
- OpenShift Container Platform 4.11 以降のベアメタルハブクラスターに RHACM 2.6 以降をインストールして設定する
- ハブクラスターに Topology Aware Lifecycle Manager をインストールする
- ハブクラスターに Red Hat OpenShift GitOps をインストールする
-
GitOps ZTP
ztp-site-generate
コンテナーイメージバージョン 4.12 以降を使用する - GitOps ZTP を使用して管理対象のシングルノード OpenShift クラスターをデプロイする
- RHACM ドキュメントの説明に従って、中央インフラストラクチャー管理を設定する
-
内部 API エンドポイント
api-int.<cluster_name>.<base_domain>
を解決するようにクラスターにサービスを提供する DNS を設定する
手順
example-sno.yaml
SiteConfig
マニフェストを使用してクラスターをデプロイした場合は、新しいワーカーノードをspec.clusters['example-sno'].nodes
リストに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfig
ファイルのspec.nodes
セクションのbmcCredentialsName
フィールドで参照されるように、新しいホストの BMC 認証シークレットを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git で変更をコミットし、GitOps ZTP ArgoCD アプリケーションによって監視されている Git リポジトリーにプッシュします。
ArgoCD
cluster
アプリケーションが同期すると、ZTP プラグインによって生成されたハブクラスターに 2 つの新しいマニフェストが表示されます。-
BareMetalHost
NMStateConfig
重要cpuset
フィールドは、ワーカーノードに対して設定しないでください。ワーカーノードのワークロードパーティショニングは、ノードのインストールが完了した後、管理ポリシーを通じて追加されます。
-
検証
インストールプロセスは、いくつかの方法でモニターできます。
次のコマンドを実行して、事前プロビジョニングイメージが作成されているかどうかを確認します。
oc get ppimg -n example-sno
$ oc get ppimg -n example-sno
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME READY REASON example-sno example-sno True ImageCreated example-sno example-node2 True ImageCreated
NAMESPACE NAME READY REASON example-sno example-sno True ImageCreated example-sno example-node2 True ImageCreated
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ベアメタルホストの状態を確認します。
oc get bmh -n example-sno
$ oc get bmh -n example-sno
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME STATE CONSUMER ONLINE ERROR AGE example-sno provisioned true 69m example-node2 provisioning true 4m50s
NAME STATE CONSUMER ONLINE ERROR AGE example-sno provisioned true 69m example-node2 provisioning true 4m50s
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
provisioning
ステータスは、インストールメディアからのノードの起動が進行中であることを示します。
インストールプロセスを継続的に監視します。
次のコマンドを実行して、エージェントのインストールプロセスを監視します。
oc get agent -n example-sno --watch
$ oc get agent -n example-sno --watch
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ワーカーノードのインストールが完了すると、ワーカーノードの証明書が自動的に承認されます。この時点で、ワーカーは
ManagedClusterInfo
ステータスで表示されます。次のコマンドを実行して、ステータスを確認します。oc get managedclusterinfo/example-sno -n example-sno -o \ jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"\n"}{end}'
$ oc get managedclusterinfo/example-sno -n example-sno -o \ jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"\n"}{end}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
example-sno [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/master":"","node-role.kubernetes.io/worker":""} example-node2 [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/worker":""}
example-sno [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/master":"","node-role.kubernetes.io/worker":""} example-node2 [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/worker":""}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow