9.2. PolicyGenerator リソースを使用した高度なマネージドクラスター設定
PolicyGenerator CR を使用して、マネージドクラスターにカスタム機能をデプロイできます。
GitOps ZTP での PolicyGenerator リソースの使用は、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
PolicyGenerator リソースの詳細は、RHACM Policy Generator のドキュメントを参照してください。
9.2.1. 追加の変更のクラスターへのデプロイ リンクのコピーリンクがクリップボードにコピーされました!
基本の GitOps Zero Touch Provisioning (ZTP) パイプライン設定以外のクラスター設定を変更する必要がある場合、次の 3 つのオプションを実行できます。
- GitOps ZTP パイプラインの完了後に追加設定を適用する
- GitOps ZTP パイプラインのデプロイが完了すると、デプロイされたクラスターはアプリケーションのワークロードに対応できるようになります。この時点で、Operator を追加インストールし、お客様の要件に応じた設定を適用することができます。追加のコンフィギュレーションがプラットフォームのパフォーマンスや割り当てられた CPU バジェットに悪影響を与えないことを確認する。
- GitOps ZTP ライブラリーにコンテンツを追加する
- GitOps ZTP パイプラインでデプロイするベースソースのカスタムリソース (CR) は、必要に応じてカスタムコンテンツで拡張できます。
- クラスターインストール用の追加マニフェストの作成
- インストール時に余分なマニフェストが適用され、インストール作業を効率化することができます。
追加のソース CR を提供したり、既存のソース CR を変更したりすると、OpenShift Container Platform のパフォーマンスまたは CPU プロファイルに大きな影響を与える可能性があります。
9.2.2. PolicyGenerator CR を使用したソース CR コンテンツのオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenerator カスタムリソース (CR) を使用すると、ztp-site-generate コンテナー内の GitOps プラグインで提供されるベースソース CR の上に追加の設定の詳細をオーバーレイできます。PolicyGenerator CR は、ベース CR への論理的なマージまたはパッチと考えることができます。PolicyGenerator CR を使用して、ベース CR のシングルフィールドを更新するか、ベース CR の内容全体をオーバーレイします。ベース CR にない値の更新やフィールドの挿入が可能です。
以下の手順の例では、acm-group-du-sno-ranGen.yaml ファイルの PolicyGenerator CR に基づいて、参照設定用に生成された PerformanceProfile CR のフィールドを更新する方法を説明します。この手順を元に、PolicyGenerator の他の部分をお客様のご要望に応じて変更してください。
前提条件
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD のソースリポジトリーとして定義されている必要があります。
手順
既存のコンテンツのベースラインソース CR を確認します。参照
PolicyGeneratorCR にリストされているソース CR を GitOps Zero Touch Provisioning (ZTP) コンテナーから抽出し、確認できます。/outフォルダーを作成します。mkdir -p ./out
$ mkdir -p ./outCopy to Clipboard Copied! Toggle word wrap Toggle overflow ソース CR を抽出します。
podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.17.1 extract /home/ztp --tar | tar x -C ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.17.1 extract /home/ztp --tar | tar x -C ./outCopy to Clipboard Copied! Toggle word wrap Toggle overflow
./out/source-crs/PerformanceProfile.yamlにあるベースラインPerformanceProfileCR を確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ソース CR のフィールドで
$...を含むものは、PolicyGeneratorCR で提供されない場合、生成された CR から削除されます。acm-group-du-sno-ranGen.yaml参照ファイル内のPerformanceProfileのPolicyGeneratorエントリーを更新します。以下の例のPolicyGeneratorCR スタンザは、適切な CPU 仕様を指定し、hugepagesを設定して、globallyDisableIrqLoadBalancingを false に設定する新しいフィールドを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git で
PolicyGenerator変更をコミットし、GitOps ZTP argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。出力例
GitOps ZTP アプリケーションは、生成された
PerformanceProfileCR を含む RHACM ポリシーを生成します。その CR の内容は、PolicyGeneratorのPerformanceProfileエントリーのmetadataおよびspec内容をソース CR にマージすることによって生成されます。作成される CR には以下のコンテンツが含まれます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ztp-site-generate コンテナーからデプロイメントした /source-crs フォルダーでは、$ 構文が暗示するテンプレート置換は使用されません。むしろ、policyGen ツールが文字列の $ 接頭辞を認識し、関連する PolicyGenerator CR でそのフィールドの値を指定しない場合、そのフィールドは出力 CR から完全に省略されます。
例外として、/source-crs YAML ファイル内の $mcp 変数は、PolicyGenerator CR から mcp の指定値で代用されます。たとえば、example/policygentemplates/acm-group-du-standard-ranGen.yaml では、mcp の値は worker になります。
spec:
bindingRules:
group-du-standard: ""
mcp: "worker"
spec:
bindingRules:
group-du-standard: ""
mcp: "worker"
policyGen ツールは、$mcp のインスタンスを出力 CR の worker に置き換えます。
9.2.3. GitOps ZTP パイプラインへのカスタムコンテンツの追加 リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP パイプラインに新しいコンテンツを追加するには、次の手順を実行します。
手順
-
PolicyGeneratorカスタムリソース (CR) のkustomization.yamlファイルが含まれるディレクトリーに、source-crsという名前のサブディレクトリーを作成します。 次の例に示すように、ユーザー提供の CR を
source-crsサブディレクトリーに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
source-crsサブディレクトリーは、kustomization.yamlファイルと同じディレクトリーにある必要があります。
必要な
PolicyGeneratorCR を更新して、source-crs/custom-crsおよびsource-crs/elasticsearchディレクトリーに追加したコンテンツへの参照を含めます。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git で
PolicyGenerator変更をコミットしてから、GitOps ZTP Argo CD ポリシーアプリケーションが監視する Git リポジトリーにプッシュします。 変更された
PolicyGeneratorを含めるようにClusterGroupUpgradeCR を更新し、cgu-test.yamlとして保存します。次の例は、生成されたcgu-test.yamlファイルを示しています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、更新された
ClusterGroupUpgradeCR を適用します。oc apply -f cgu-test.yaml
$ oc apply -f cgu-test.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、更新が成功したことを確認します。
oc get cgu -A
$ oc get cgu -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAMESPACE NAME AGE STATE DETAILS ztp-clusters custom-source-cr 6s InProgress Remediating non-compliant policies ztp-install cluster1 19h Completed All clusters are compliant with all the managed policies
NAMESPACE NAME AGE STATE DETAILS ztp-clusters custom-source-cr 6s InProgress Remediating non-compliant policies ztp-install cluster1 19h Completed All clusters are compliant with all the managed policiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.4. PolicyGenerator CR のポリシーコンプライアンス評価タイムアウトの設定 リンクのコピーリンクがクリップボードにコピーされました!
ハブクラスターにインストールされた Red Hat Advanced Cluster Management (RHACM) を使用して、マネージドクラスターが適用されたポリシーに準拠しているかどうかを監視および報告します。RHACM は、ポリシーテンプレートを使用して、定義済みのポリシーコントローラーとポリシーを適用します。ポリシーコントローラーは Kubernetes のカスタムリソース定義 (CRD) インスタンスです。
PolicyGenerator カスタムリソース (CR) を使用して、デフォルトのポリシー評価間隔をオーバーライドできます。RHACM が適用されたクラスターポリシーを再評価する前に、ConfigurationPolicy CR がポリシー準拠または非準拠の状態を維持できる期間を定義する期間設定を設定します。
GitOps Zero Touch Provisioning (ZTP) ポリシージェネレーターは、事前定義されたポリシー評価間隔で ConfigurationPolicy CR ポリシーを生成します。noncompliant 状態のデフォルト値は 10 秒です。compliant 状態のデフォルト値は 10 分です。評価間隔を無効にするには、値を never に設定します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてハブクラスターにログインしている。 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。
手順
PolicyGeneratorCR 内のすべてのポリシーの評価間隔を設定するには、evaluationIntervalフィールドに適切なcompliantとnoncompliant値を設定します。以下に例を示します。policyDefaults: evaluationInterval: compliant: 30m noncompliant: 45spolicyDefaults: evaluationInterval: compliant: 30m noncompliant: 45sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記また、
compliantフィールドとnoncompliantフィールドをneverに設定して、特定の準拠状態に達した後にポリシーの評価を停止することもできます。PolicyGeneratorCR 内の個々のポリシーオブジェクトの評価間隔を設定するには、evaluationIntervalフィールドを追加し、適切な値を設定します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git リポジトリー内の
PolicyGeneratorCR ファイルをコミットし、変更をプッシュします。
検証
マネージドスポーククラスターポリシーが予想される間隔で監視されていることを確認します。
-
マネージドクラスターで
cluster-admin権限を持つユーザーとしてログインします。 open-cluster-management-agent-addonnamespace で実行されている Pod を取得します。以下のコマンドを実行します。oc get pods -n open-cluster-management-agent-addon
$ oc get pods -n open-cluster-management-agent-addonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 10d
NAME READY STATUS RESTARTS AGE config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 10dCopy to Clipboard Copied! Toggle word wrap Toggle overflow config-policy-controllerPod のログで、適用されたポリシーが予想される間隔で評価されていることを確認します。oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb
$ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdbCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-common-compute-1-catalog-policy-config"}2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-common-compute-1-catalog-policy-config"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.5. バリデーターインフォームポリシーを使用した GitOps ZTP クラスターデプロイメントの完了のシグナリング リンクのコピーリンクがクリップボードにコピーされました!
デプロイされたクラスターの GitOps Zero Touch Provisioning (ZTP) のインストールと設定が完了したときに通知するバリデーター通知ポリシーを作成します。このポリシーは、シングルノード OpenShift クラスター、3 ノードクラスター、および標準クラスターのデプロイメントに使用できます。
手順
ソースファイル
validatorCRs/informDuValidator.yamlを含むスタンドアロンのPolicyGeneratorカスタムリソース (CR) を作成します。クラスタータイプごとにスタンドアロンPolicyGeneratorCR が 1 つだけ必要です。たとえば、次の CR は、シングルノード OpenShift クラスターにバリデータ通知ポリシーを適用します。シングルノードクラスターバリデーター通知ポリシー CR の例 (acm-group-du-sno-validator-ranGen.yaml)
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git リポジトリー内の
PolicyGeneratorCR ファイルをコミットし、変更をプッシュします。
9.2.6. PolicyGenerator CR を使用した電源状態の設定 リンクのコピーリンクがクリップボードにコピーされました!
低レイテンシーで高パフォーマンスのエッジデプロイメントでは、C ステートと P ステートを無効にするか制限する必要があります。この設定では、CPU は一定の周波数 (通常は最大ターボ周波数) で実行されます。これにより、CPU が常に最大速度で実行され、高いパフォーマンスと低レイテンシーが実現されます。これにより、ワークロードのレイテンシーが最適化されます。ただし、これは最大の電力消費にもつながり、すべてのワークロードに必要ではない可能性があります。
ワークロードはクリティカルまたは非クリティカルとして分類できます。クリティカルなワークロードでは、高パフォーマンスと低レイテンシーのために C ステートと P ステートの設定を無効にする必要があります。クリティカルでないワークロードでは、C ステートと P ステートの設定を使用して、いくらかのレイテンシーとパフォーマンスを犠牲にします。GitOps Zero Touch Provisioning (ZTP) を使用して、次の 3 つの電源状態を設定できます。
- 高性能モードは、最大の消費電力で超低遅延を提供します。
- パフォーマンスモードは、比較的高い電力消費で低遅延を提供します。
- 省電力は、消費電力の削減と遅延の増加のバランスをとります。
デフォルトの設定は、低遅延のパフォーマンスモードです。
PolicyGenerator カスタムリソース (CR) を使用すると、ztp-site-generate コンテナー内の GitOps プラグインで提供されるベースソース CR の上に追加の設定の詳細をオーバーレイできます。
acm-group-du-sno-ranGen.yaml の PolicyGenerator CR に基づいて、参照設定用に生成された PerformanceProfile CR の workloadHints フィールドを更新して、電源状態を設定します。
次の共通の前提条件は、3 つの電源状態すべての設定に適用されます。
前提条件
- カスタムサイトの設定データを管理する Git リポジトリーを作成している。リポジトリーはハブクラスターからアクセス可能で、Argo CD のソースリポジトリーとして定義されている必要があります。
- 「GitOps ZTP サイト設定リポジトリーの準備」で説明されている手順に従っている。
9.2.6.1. PolicyGenerator CR を使用したパフォーマンスモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
この例に従って、acm-group-du-sno-ranGen.yaml の PolicyGenerator CR に基づき、参照設定用に生成された PerformanceProfile CR の workloadHints フィールドを更新して、パフォーマンスモードを設定します。
パフォーマンスモードは、比較的高い電力消費で低遅延を提供します。
前提条件
- 「低遅延および高パフォーマンスのためのホストファームウェアの設定」のガイダンスに従って、パフォーマンス関連の設定で BIOS を設定している。
手順
パフォーマンスモードを設定するには、
out/argocd/example/acmpolicygenerator//のacm-group-du-sno-ranGen.yaml参照ファイルでPerformanceProfileのPolicyGeneratorエントリーを以下のように更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git で
PolicyGenerator変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
9.2.6.2. PolicyGenerator CR を使用した高パフォーマンスモードの設定 リンクのコピーリンクがクリップボードにコピーされました!
この例に従って、acm-group-du-sno-ranGen.yaml の PolicyGenerator CR に基づき、参照設定用に生成された PerformanceProfile CR の workloadHints フィールドを更新して、高パフォーマンスモードを設定します。
高パフォーマンスモードは、最大の消費電力で超低遅延を提供します。
前提条件
- 「低遅延および高パフォーマンスのためのホストファームウェアの設定」のガイダンスに従って、パフォーマンス関連の設定で BIOS を設定している。
手順
高パフォーマンスモードを設定するには、
out/argocd/example/acmpolicygenerator/のacm-group-du-sno-ranGen.yaml参照ファイルでPerformanceProfileのPolicyGeneratorエントリーを次のように更新します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git で
PolicyGenerator変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
9.2.6.3. PolicyGenerator CR を使用した省電力モードの設定 リンクのコピーリンクがクリップボードにコピーされました!
この例に従って、acm-group-du-sno-ranGen.yaml の PolicyGenerator CR に基づき、参照設定用に生成された PerformanceProfile CR の workloadHints フィールドを更新して、省電力モードを設定します。
省電力モードは、消費電力の削減と遅延の増加のバランスをとります。
前提条件
- BIOS で C ステートと OS 制御の P ステートを有効化している。
手順
省電力モードを設定するには、
out/argocd/example/acmpolicygenerator/のacm-group-du-sno-ranGen.yaml参照ファイルでPerformanceProfileのPolicyGeneratorエントリーを次のように更新します。追加のカーネル引数オブジェクトを使用して、省電力モード用に CPU ガバナーを設定することを推奨します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
schedutilガバナーが推奨されますが、ondemandやpowersaveなどの他のガバナーを使用することもできます。
-
Git で
PolicyGenerator変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
検証
次のコマンドを使用して、識別されたノードのリストから、デプロイされたクラスター内のワーカーノードを選択します。
oc get nodes
$ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを使用して、ノードにログインします。
oc debug node/<node-name>
$ oc debug node/<node-name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <node-name>を、電源状態を確認するノードの名前に置き換えます。/hostをデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/hostにホストの root ファイルシステムをマウントします。次の例に示すように、ルートディレクトリーを/hostに変更すると、ホストの実行可能パスに含まれるバイナリーを実行できます。chroot /host
# chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、適用された電源状態を確認します。
cat /proc/cmdline
# cat /proc/cmdlineCopy to Clipboard Copied! Toggle word wrap Toggle overflow
予想される出力
-
省電力モードの
intel_pstate=passive。
9.2.6.4. 省電力の最大化 リンクのコピーリンクがクリップボードにコピーされました!
最大の CPU 周波数を制限して、最大の電力節約を実現することを推奨します。最大 CPU 周波数を制限せずに重要でないワークロード CPU で C ステートを有効にすると、重要な CPU の周波数が高くなるため、消費電力の節約の多くが無効になります。
sysfs プラグインフィールドを更新し、リファレンス設定の TunedPerformancePatch CR で max_perf_pct に適切な値を設定することで、電力の節約を最大化します。acm-group-du-sno-ranGen.yaml に基づくこの例では、最大 CPU 周波数を制限するための手順を説明します。
前提条件
- 「PolicyGenerator CR を使用した省電力モードの設定」の説明に従って、省電力モードを設定している。
手順
out/argocd/example/acmpolicygenerator/のacm-group-du-sno-ranGen.yaml参照ファイルで、TunedPerformancePatchのPolicyGeneratorエントリーを更新します。電力を最大限に節約するには、次の例に示すようにmax_perf_pctを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
max_perf_pctは、cpufreqドライバーが設定できる最大周波数を、サポートされている最大 CPU 周波数のパーセンテージとして制御します。この値はすべての CPU に適用されます。サポートされている最大周波数は/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freqで確認できます。開始点として、All Cores Turbo周波数ですべての CPU を制限する割合を使用できます。All Cores Turbo周波数は、コアがすべて使用されているときにすべてのコアが実行される周波数です。
注記省電力を最大化するには、より低い値を設定します。
max_perf_pctの値を低く設定すると、最大 CPU 周波数が制限されるため、消費電力が削減されますが、パフォーマンスに影響を与える可能性もあります。さまざまな値を試し、システムのパフォーマンスと消費電力を監視して、ユースケースに最適な設定を見つけてください。-
Git で
PolicyGenerator変更をコミットしてから、GitOps ZTP Argo CD アプリケーションによって監視される Git リポジトリーにプッシュします。
9.2.7. PolicyGenerator CR を使用した LVM Storage の設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) を使用して、デプロイするマネージドクラスターの論理ボリュームマネージャー (LVM) ストレージを設定できます。
HTTP トランスポートで PTP イベントまたはベアメタルハードウェアイベントを使用する場合、LVM Storage を使用してイベントサブスクリプションを永続化します。
分散ユニットでローカルボリュームを使用する永続ストレージには、Local Storage Operator を使用します。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。
手順
新しいマネージドクラスターの LVM Storage を設定するには、
acm-common-ranGen.yamlファイルのpolicies.manifestsに次の YAML を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Storage LVMO サブスクリプションは非推奨になりました。OpenShift Container Platform の将来のリリースでは、ストレージ LVMO サブスクリプションは利用できなくなります。代わりに、Storage LVMS サブスクリプションを使用する必要があります。
OpenShift Container Platform 4.17 では、LVMO サブスクリプションの代わりに Storage LVMS サブスクリプションを使用できます。LVMS サブスクリプションでは、
acm-common-ranGen.yamlファイルを手動でオーバーライドする必要はありません。Storage LVMS サブスクリプションを使用するには、acm-common-ranGen.yamlファイルのpolicies.manifestsに次の YAML を追加します。- path: source-crs/StorageLVMSubscriptionNS.yaml - path: source-crs/StorageLVMSubscriptionOperGroup.yaml - path: source-crs/StorageLVMSubscription.yaml
- path: source-crs/StorageLVMSubscriptionNS.yaml - path: source-crs/StorageLVMSubscriptionOperGroup.yaml - path: source-crs/StorageLVMSubscription.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 特定のグループまたは個々のサイト設定ファイルの
policies.manifestsにLVMClusterCR を追加します。たとえば、acm-group-du-sno-ranGen.yamlファイルに以下を追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この設定例では、OpenShift Container Platform がインストールされているディスクを除く、使用可能なすべてのデバイスを含むボリュームグループ (
vg1) を作成します。シンプール論理ボリュームも作成されます。- 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
-
Git で
PolicyGeneratorの変更をコミットしてから、その変更をサイト設定リポジトリーにプッシュし、GitOps ZTP を使用して LVM Storage を新しいサイトにデプロイします。
9.2.8. PolicyGenerator CR を使用した PTP イベントの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps ZTP パイプラインを使用して、HTTP トランスポートを使用する PTP イベントを設定できます。
9.2.8.1. HTTP トランスポートを使用する PTP イベントの設定 リンクのコピーリンクがクリップボードにコピーされました!
GitOps Zero Touch Provisioning (ZTP) パイプラインを使用してデプロイしたマネージドクラスター上で、HTTP トランスポートを使用する PTP イベントを設定できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。 - カスタムサイトの設定データを管理する Git リポジトリーを作成している。
手順
要件に応じて、次の
PolicyGenerator変更をacm-group-du-3node-ranGen.yaml、acm-group-du-sno-ranGen.yaml、またはacm-group-du-standard-ranGen.yamlファイルに適用します。policies.manifestsに、トランスポートホストを設定するPtpOperatorConfigCR ファイルを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記OpenShift Container Platform 4.13 以降では、PTP イベントに HTTP トランスポートを使用するときに、
PtpOperatorConfigリソースのtransportHostフィールドを設定する必要はありません。PTP クロックの種類とインターフェイスに
linuxptpとphc2sysを設定します。たとえば、次の YAML をpolicies.manifestsに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 要件に応じて、
PtpConfigMaster.yamlまたはPtpConfigSlave.yamlを指定できます。acm-group-du-sno-ranGen.yamlまたはacm-group-du-3node-ranGen.yamlに基づいて設定する場合は、PtpConfigSlave.yamlを使用します。 - 2
- デバイス固有のインターフェイス名。
- 3
- PTP 高速イベントを有効にするには、
.spec.sourceFiles.spec.profileのptp4lOptsに--summary_interval -4値を追加する必要があります。 - 4
phc2sysOptsの値が必要です。-mはメッセージをstdoutに出力します。linuxptp-daemonDaemonSetはログを解析し、Prometheus メトリックを生成します。- 5
- オプション:
ptpClockThresholdスタンザが存在しない場合は、ptpClockThresholdフィールドにデフォルト値が使用されます。スタンザは、デフォルトのptpClockThreshold値を示します。ptpClockThreshold値は、PTP マスタークロックが PTP イベントが発生する前に切断されてからの期間を設定します。holdOverTimeoutは、PTP マスタークロックが切断されたときに、PTP クロックイベントの状態がFREERUNに変わるまでの時間値 (秒単位) です。maxOffsetThresholdおよびminOffsetThreshold設定は、CLOCK_REALTIME(phc2sys) またはマスターオフセット (ptp4l) の値と比較するナノ秒単位のオフセット値を設定します。ptp4lまたはphc2sysのオフセット値がこの範囲外の場合、PTP クロックの状態がFREERUNに設定されます。オフセット値がこの範囲内にある場合、PTP クロックの状態がLOCKEDに設定されます。
- 必要なその他の変更およびファイルをカスタムサイトリポジトリーにマージします。
- 変更をサイト設定リポジトリーにプッシュし、GitOps ZTP を使用して PTP 高速イベントを新規サイトにデプロイします。
9.2.9. イメージをローカルにキャッシュするための Image Registry Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、ローカルレジストリーを使用してイメージのキャッシュを管理します。エッジコンピューティングのユースケースでは、クラスターは集中型のイメージレジストリーと通信するときに帯域幅の制限を受けることが多く、イメージのダウンロード時間が長くなる可能性があります。
初期デプロイメント中はダウンロードに時間がかかることは避けられません。時間の経過とともに、予期しないシャットダウンが発生した場合に CRI-O が /var/lib/containers/storage ディレクトリーを消去するリスクがあります。イメージのダウンロード時間が長い場合の対処方法として、GitOps Zero Touch Provisioning (ZTP) を使用してリモートマネージドクラスター上にローカルイメージレジストリーを作成できます。これは、クラスターをネットワークのファーエッジにデプロイするエッジコンピューティングシナリオで役立ちます。
GitOps ZTP を使用してローカルイメージレジストリーをセットアップする前に、リモートマネージドクラスターのインストールに使用する SiteConfig CR でディスクパーティショニングを設定する必要があります。インストール後、PolicyGenerator CR を使用してローカルイメージレジストリーを設定します。次に、GitOps ZTP パイプラインは永続ボリューム (PV) と永続ボリューム要求 (PVC) CR を作成し、imageregistry 設定にパッチを適用します。
ローカルイメージレジストリーは、ユーザーアプリケーションイメージにのみ使用でき、OpenShift Container Platform または Operator Lifecycle Manager Operator イメージには使用できません。
9.2.9.1. SiteConfig を使用したディスクパーティショニングの設定 リンクのコピーリンクがクリップボードにコピーされました!
SiteConfig CR と GitOps Zero Touch Provisioning (ZTP) を使用して、マネージドクラスターのディスクパーティションを設定します。SiteConfig CR のディスクパーティションの詳細は、基になるディスクと一致する必要があります。
この手順はインストール時に完了する必要があります。
前提条件
- Butane をインストールしている。
手順
storage.buファイルを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
storage.buを Ignition ファイルに変換します。butane storage.bu
$ butane storage.buCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
{"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}{"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - JSON Pretty Print などのツールを使用して、出力を JSON 形式に変換します。
出力を
SiteConfigCR の.spec.clusters.nodes.ignitionConfigOverrideフィールドにコピーします。例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記.spec.clusters.nodes.ignitionConfigOverrideフィールドが存在しない場合は、作成します。
検証
インストール中またはインストール後に、次のコマンドを実行して、ハブクラスターで
BareMetalHostオブジェクトにアノテーションが表示されていることを確認します。oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]
$ oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
"{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}""{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow インストール後、シングルノード OpenShift ディスクのステータスを確認します。
次のコマンドを実行して、シングルノード OpenShift ノードでデバッグセッションを開始します。この手順は、
<node_name>-debugというデバッグ Pod をインスタンス化します。oc debug node/my-sno-node
$ oc debug node/my-sno-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、デバッグシェル内で
/hostをルートディレクトリーとして設定します。デバッグ Pod は、Pod 内の/hostにホストの root ファイルシステムをマウントします。root ディレクトリーを/hostに変更すると、ホストの実行パスに含まれるバイナリーを実行できます。chroot /host
# chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、使用可能なすべてのブロックデバイスに関する情報をリスト表示します。
lsblk
# lsblkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ファイルシステムのディスク領域の使用状況に関する情報を表示します。
df -h
# df -hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.2.9.2. PolicyGenerator CR を使用したイメージレジストリーの設定 リンクのコピーリンクがクリップボードにコピーされました!
PolicyGenerator (PGT) CR を使用して、イメージレジストリーを設定するために必要な CR を適用し、imageregistry 設定にパッチを適用します。
前提条件
- マネージドクラスターでディスクパーティションを設定しました。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてハブクラスターにログインしている。 - GitOps Zero Touch Provisioning (ZTP) で使用するカスタムサイト設定データを管理する Git リポジトリーを作成している。
手順
適切な
PolicyGeneratorCR で、ストレージクラス、永続ボリューム要求、永続ボリューム、およびイメージレジストリー設定を設定します。たとえば、個々のサイトを設定するには、次の YAML をacm-example-sno-site.yamlファイルに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要- fileName: ImageRegistryConfig.yaml設定には、complianceType: mustonlyhaveを設定しないでください。これにより、レジストリー Pod のデプロイが失敗する可能性があります。-
Git で
PolicyGenerator変更をコミットしてから、GitOps ZTP ArgoCD アプリケーションによって監視される Git リポジトリーにプッシュします。
検証
次の手順を使用して、マネージドクラスターのローカルイメージレジストリーに関するエラーをトラブルシューティングします。
マネージドクラスターにログインしているときに、レジストリーへのログインが成功したことを確認します。以下のコマンドを実行します。
マネージドクラスター名をエクスポートします。
cluster=<managed_cluster_name>
$ cluster=<managed_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスター
kubeconfigの詳細を取得します。oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster$ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow クラスター
kubeconfigをダウンロードしてエクスポートします。oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster$ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow - マネージドクラスターからイメージレジストリーへのアクセスを確認します。「レジストリーへのアクセス」を参照してください。
imageregistry.operator.openshift.ioグループインスタンスのConfigCRD がエラーを報告していないことを確認します。マネージドクラスターにログインしているときに、次のコマンドを実行します。oc get image.config.openshift.io cluster -o yaml
$ oc get image.config.openshift.io cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターの
PersistentVolumeClaimにデータが入力されていることを確認します。マネージドクラスターにログインしているときに、次のコマンドを実行します。oc get pv image-registry-sc
$ oc get pv image-registry-scCopy to Clipboard Copied! Toggle word wrap Toggle overflow registry*Pod が実行中であり、openshift-image-registrynamespace にあることを確認します。oc get pods -n openshift-image-registry | grep registry*
$ oc get pods -n openshift-image-registry | grep registry*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d image-registry-5f8987879-6nx6h 1/1 Running 0 8d
cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d image-registry-5f8987879-6nx6h 1/1 Running 0 8dCopy to Clipboard Copied! Toggle word wrap Toggle overflow マネージドクラスターのディスクパーティションが正しいことを確認します。
マネージドクラスターへのデバッグシェルを開きます。
oc debug node/sno-1.example.com
$ oc debug node/sno-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow lsblkを実行して、ホストディスクパーティションを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/var/imageregistryは、ディスクが正しくパーティショニングされていることを示します。