7.3. 推奨されるクラスター設定が適用されていることの確認
クラスターが正しい設定で実行されていることを確認できます。以下の手順では、DU アプリケーションを OpenShift Container Platform 4.16 クラスターにデプロイするために必要なさまざまな設定を確認する方法を説明します。
前提条件
- クラスターをデプロイし、vDU ワークロード用に調整している。
-
OpenShift CLI (
oc) がインストールされている。 -
cluster-admin権限を持つユーザーとしてログインしている。
手順
デフォルトの OperatorHub ソースが無効になっていることを確認します。以下のコマンドを実行します。
$ oc get operatorhub cluster -o yaml
出力例
spec: disableAllDefaultSources: true次のコマンドを実行して、必要なすべての
CatalogSourceリソースにワークロードのパーティショニング (PreferredDuringScheduling) のアノテーションが付けられていることを確認します。$ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'出力例
certified-operators -- {"effect": "PreferredDuringScheduling"} community-operators -- {"effect": "PreferredDuringScheduling"} ran-operators 1 redhat-marketplace -- {"effect": "PreferredDuringScheduling"} redhat-operators -- {"effect": "PreferredDuringScheduling"}- 1
- アノテーションが付けられていない
CatalogSourceリソースも返されます。この例では、ran-operatorsCatalogSourceリソースにはアノテーションが付けられておらず、PreferredDuringSchedulingアノテーションがありません。
注記適切に設定された vDU クラスターでは、単一のアノテーション付きカタログソースのみがリスト表示されます。
該当するすべての OpenShift Container Platform Operator の namespace がワークロードのパーティショニング用にアノテーションされていることを確認します。これには、コア OpenShift Container Platform とともにインストールされたすべての Operator と、参照 DU チューニング設定に含まれる追加の Operator のセットが含まれます。以下のコマンドを実行します。
$ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'出力例
default -- openshift-apiserver -- management openshift-apiserver-operator -- management openshift-authentication -- management openshift-authentication-operator -- management
重要追加の Operator は、ワークロードパーティショニングのためにアノテーションを付けてはなりません。前のコマンドからの出力では、追加の Operator が
--セパレーターの右側に値なしでリストされている必要があります。ClusterLogging設定が正しいことを確認してください。以下のコマンドを実行します。適切な入力ログと出力ログが設定されていることを確認します。
$ oc get -n openshift-logging ClusterLogForwarder instance -o yaml
出力例
apiVersion: logging.openshift.io/v1 kind: ClusterLogForwarder metadata: creationTimestamp: "2022-07-19T21:51:41Z" generation: 1 name: instance namespace: openshift-logging resourceVersion: "1030342" uid: 8c1a842d-80c5-447a-9150-40350bdf40f0 spec: inputs: - infrastructure: {} name: infra-logs outputs: - name: kafka-open type: kafka url: tcp://10.46.55.190:9092/test pipelines: - inputRefs: - audit name: audit-logs outputRefs: - kafka-open - inputRefs: - infrastructure name: infrastructure-logs outputRefs: - kafka-open ...キュレーションスケジュールがアプリケーションに適していることを確認します。
$ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml
出力例
apiVersion: logging.openshift.io/v1 kind: ClusterLogging metadata: creationTimestamp: "2022-07-07T18:22:56Z" generation: 1 name: instance namespace: openshift-logging resourceVersion: "235796" uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796 spec: collection: logs: fluentd: {} type: fluentd curation: curator: schedule: 30 3 * * * type: curator managementState: Managed ...
次のコマンドを実行して、Web コンソールが無効になっている (
managementState: Removed) ことを確認します。$ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"出力例
Removed
次のコマンドを実行して、クラスターノードで
chronydが無効になっていることを確認します。$ oc debug node/<node_name>
ノードで
chronydのステータスを確認します。sh-4.4# chroot /host
sh-4.4# systemctl status chronyd
出力例
● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:chronyd(8) man:chrony.conf(5)linuxptp-daemonコンテナーへのリモートシェル接続と PTP Management Client (pmc) ツールを使用して、PTP インターフェイスがプライマリークロックに正常に同期されていることを確認します。次のコマンドを実行して、
$PTP_POD_NAME変数にlinuxptp-daemonPod の名前を設定します。$ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)
次のコマンドを実行して、PTP デバイスの同期ステータスを確認します。
$ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'出力例
sending: GET PORT_DATA_SET 3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET portIdentity 3cecef.fffe.7a7020-1 portState SLAVE logMinDelayReqInterval -4 peerMeanPathDelay 0 logAnnounceInterval 1 announceReceiptTimeout 3 logSyncInterval 0 delayMechanism 1 logMinPdelayReqInterval 0 versionNumber 2 3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET portIdentity 3cecef.fffe.7a7020-2 portState LISTENING logMinDelayReqInterval 0 peerMeanPathDelay 0 logAnnounceInterval 1 announceReceiptTimeout 3 logSyncInterval 0 delayMechanism 1 logMinPdelayReqInterval 0 versionNumber 2次の
pmcコマンドを実行して、PTP クロックのステータスを確認します。$ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'出力例
sending: GET TIME_STATUS_NP 3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP master_offset 10 1 ingress_time 1657275432697400530 cumulativeScaledRateOffset +0.000000000 scaledLastGmPhaseChange 0 gmTimeBaseIndicator 0 lastGmPhaseChange 0x0000'0000000000000000.0000 gmPresent true 2 gmIdentity 3c2c30.ffff.670e00/var/run/ptp4l.0.configの値に対応する予期されるmaster offset値がlinuxptp-daemon-containerログにあることを確認します。$ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container
出力例
phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset -1731092 s2 freq -1546242 delay 497 ptp4l[56020.390]: [ptp4l.1.config] master offset -2 s2 freq -5863 path delay 541 ptp4l[56020.390]: [ptp4l.0.config] master offset -8 s2 freq -10699 path delay 533
次のコマンドを実行して、SR-IOV 設定が正しいことを確認します。
SriovOperatorConfigリソースのdisableDrain値がtrueに設定されていることを確認します。$ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"出力例
true
次のコマンドを実行して、
SriovNetworkNodeState同期ステータスがSucceededであることを確認します。$ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"出力例
Succeeded
SR-IOV 用に設定された各インターフェイスの下の仮想機能 (
Vfs) の予想される数と設定が、.status.interfacesフィールドに存在し、正しいことを確認します。以下に例を示します。$ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml
出力例
apiVersion: v1 items: - apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodeState ... status: interfaces: ... - Vfs: - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.0 vendor: "8086" vfID: 0 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.1 vendor: "8086" vfID: 1 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.2 vendor: "8086" vfID: 2 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.3 vendor: "8086" vfID: 3 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.4 vendor: "8086" vfID: 4 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.5 vendor: "8086" vfID: 5 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.6 vendor: "8086" vfID: 6 - deviceID: 154c driver: vfio-pci pciAddress: 0000:3b:0a.7 vendor: "8086" vfID: 7
クラスターパフォーマンスプロファイルが正しいことを確認します。
cpuセクションとhugepagesセクションは、ハードウェア設定によって異なります。以下のコマンドを実行します。$ oc get PerformanceProfile openshift-node-performance-profile -o yaml
出力例
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: creationTimestamp: "2022-07-19T21:51:31Z" finalizers: - foreground-deletion generation: 1 name: openshift-node-performance-profile resourceVersion: "33558" uid: 217958c0-9122-4c62-9d4d-fdc27c31118c spec: additionalKernelArgs: - idle=poll - rcupdate.rcu_normal_after_boot=0 - efi=runtime cpu: isolated: 2-51,54-103 reserved: 0-1,52-53 hugepages: defaultHugepagesSize: 1G pages: - count: 32 size: 1G machineConfigPoolSelector: pools.operator.machineconfiguration.openshift.io/master: "" net: userLevelNetworking: true nodeSelector: node-role.kubernetes.io/master: "" numa: topologyPolicy: restricted realTimeKernel: enabled: true status: conditions: - lastHeartbeatTime: "2022-07-19T21:51:31Z" lastTransitionTime: "2022-07-19T21:51:31Z" status: "True" type: Available - lastHeartbeatTime: "2022-07-19T21:51:31Z" lastTransitionTime: "2022-07-19T21:51:31Z" status: "True" type: Upgradeable - lastHeartbeatTime: "2022-07-19T21:51:31Z" lastTransitionTime: "2022-07-19T21:51:31Z" status: "False" type: Progressing - lastHeartbeatTime: "2022-07-19T21:51:31Z" lastTransitionTime: "2022-07-19T21:51:31Z" status: "False" type: Degraded runtimeClass: performance-openshift-node-performance-profile tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile注記CPU 設定は、サーバーで使用可能なコアの数に依存し、ワークロードパーティショニングの設定に合わせる必要があります。
hugepagesの設定は、サーバーとアプリケーションに依存します。次のコマンドを実行して、
PerformanceProfileがクラスターに正常に適用されたことを確認します。$ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"出力例
Available -- True Upgradeable -- True Progressing -- False Degraded -- False
次のコマンドを実行して、
Tunedパフォーマンスパッチの設定を確認します。$ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml
出力例
apiVersion: tuned.openshift.io/v1 kind: Tuned metadata: creationTimestamp: "2022-07-18T10:33:52Z" generation: 1 name: performance-patch namespace: openshift-cluster-node-tuning-operator resourceVersion: "34024" uid: f9799811-f744-4179-bf00-32d4436c08fd spec: profile: - data: | [main] summary=Configuration changes profile inherited from performance created tuned include=openshift-node-performance-openshift-node-performance-profile [bootloader] cmdline_crash=nohz_full=2-23,26-47 1 [sysctl] kernel.timer_migration=1 [scheduler] group.ice-ptp=0:f:10:*:ice-ptp.* [service] service.stalld=start,enable service.chronyd=stop,disable name: performance-patch recommend: - machineConfigLabels: machineconfiguration.openshift.io/role: master priority: 19 profile: performance-patch- 1
cmdline=nohz_full=の cpu リストは、ハードウェア設定によって異なります。
次のコマンドを実行して、クラスターネットワーク診断が無効になっていることを確認します。
$ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'出力例
true
Kubeletのハウスキーピング間隔が、遅い速度に調整されていることを確認します。これは、containerMountNSマシン設定で設定されます。以下のコマンドを実行します。$ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION
出力例
Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
次のコマンドを実行して、Grafana と
alertManagerMainが無効になっていること、および Prometheus の保持期間が 24 時間に設定されていることを確認します。$ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"出力例
grafana: enabled: false alertmanagerMain: enabled: false prometheusK8s: retention: 24h
次のコマンドを使用して、Grafana および
alertManagerMainルートがクラスター内に見つからないことを確認します。$ oc get route -n openshift-monitoring alertmanager-main
$ oc get route -n openshift-monitoring grafana
どちらのクエリーも
Error from server (NotFound)メッセージを返す必要があります。
次のコマンドを実行して、
PerformanceProfile、Tunedperformance-patch、ワークロードパーティショニング、およびカーネルコマンドライン引数のそれぞれにreservedとして割り当てられた CPU が少なくとも 4 つあることを確認します。$ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"出力例
0-3
注記ワークロードの要件によっては、追加の予約済み CPU の割り当てが必要になる場合があります。
