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}' | jqCopy 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}' | jqCopy 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 汎用の
MachineConfigCR を使用して、ワーカーノードでワークロードパーティションを設定します。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.yamlSiteConfigマニフェストを使用してクラスターをデプロイした場合は、新しいワーカーノードを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-snoCopy 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 ImageCreatedCopy to Clipboard Copied! Toggle word wrap Toggle overflow ベアメタルホストの状態を確認します。
oc get bmh -n example-sno
$ oc get bmh -n example-snoCopy 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 4m50s1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
provisioningステータスは、インストールメディアからのノードの起動が進行中であることを示します。
インストールプロセスを継続的に監視します。
次のコマンドを実行して、エージェントのインストールプロセスを監視します。
oc get agent -n example-sno --watch
$ oc get agent -n example-sno --watchCopy 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