手順

1. 調整された有効なマニフェストを含む設定マップを作成し、ノードプールでマニフェストを参照します。次の例では、Tuned マニフェストは、任意の値を持つ tuned-1-node-label ノードラベルを含むノードで vm.dirty_ratio を 55 に設定するプロファイルを定義します。次の ConfigMap マニフェストを tuned-1.yaml という名前のファイルに保存します。

       apiVersion: v1
       kind: ConfigMap
       metadata:
         name: tuned-1
         namespace: clusters
       data:
         tuning: |
           apiVersion: tuned.openshift.io/v1
           kind: Tuned
           metadata:
             name: tuned-1
             namespace: openshift-cluster-node-tuning-operator
           spec:
             profile:
             - data: |
                 [main]
                 summary=Custom OpenShift profile
                 include=openshift-node
                 [sysctl]
                 vm.dirty_ratio="55"
               name: tuned-1-profile
             recommend:
             - priority: 20
               profile: tuned-1-profile

   注記

   Tuned 仕様の spec.recommend セクションのエントリーにラベルを追加しない場合は、ノードプールベースのマッチングが想定されるため、spec.recommend セクションの最も優先度の高いプロファイルがプール内のノードに適用されます。Tuned .spec.recommend.match セクションでラベル値を設定することにより、よりきめ細かいノードラベルベースのマッチングを実現できますが、ノードプールの .spec.management.upgradeType 値を InPlace に 設定しない限り、ノードラベルはアップグレード中に保持されません。

2. 管理クラスターに ConfigMap オブジェクトを作成します。

   $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml

3. ノードプールを編集するか作成して、ノードプールの spec.tuningConfig フィールドで ConfigMap オブジェクトを参照します。この例では、2 つのノードを含む nodepool-1 という名前の NodePool が 1 つしかないことを前提としています。

       apiVersion: hypershift.openshift.io/v1alpha1
       kind: NodePool
       metadata:
         ...
         name: nodepool-1
         namespace: clusters
       ...
       spec:
         ...
         tuningConfig:
         - name: tuned-1
       status:
       ...

   注記

   複数のノードプールで同じ設定マップを参照できます。ホストされたコントロールプレーンでは、Node Tuning Operator はノードプール名と namespace のハッシュを Tuned CR の名前に追加してそれらを区別します。このケース以外では、同じホストクラスターの異なる Tuned CR に同じ名前の複数の Tuned プロファイルを作成しないでください。

1. ホストされたクラスター内の Tuned オブジェクトを一覧表示します。

   $ oc --kubeconfig="$HC_KUBECONFIG" get Tuneds -n openshift-cluster-node-tuning-operator

   出力例

   NAME       AGE
   default    7m36s
   rendered   7m36s
   tuned-1    65s

2. ホストされたクラスター内の Profile オブジェクトを一覧表示します。

   $ oc --kubeconfig="$HC_KUBECONFIG" get Profiles -n openshift-cluster-node-tuning-operator

   出力例

   NAME                           TUNED            APPLIED   DEGRADED   AGE
   nodepool-1-worker-1            tuned-1-profile  True      False      7m43s
   nodepool-1-worker-2            tuned-1-profile  True      False      7m14s

   注記

   カスタムプロファイルが作成されていない場合は、openshift-node プロファイルがデフォルトで適用されます。

3. チューニングが正しく適用されたことを確認するには、ノードでデバッグシェルを開始し、sysctl 値を確認します。

   $ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio

   出力例

   vm.dirty_ratio = 55

手順

1. サイズが 2 MB の 10 個の Huge Page を作成するための Tuned オブジェクトマニフェストを含む ConfigMap オブジェクトを作成します。この ConfigMap マニフェストを tuned-hugepages.yaml という名前のファイルに保存します。

       apiVersion: v1
       kind: ConfigMap
       metadata:
         name: tuned-hugepages
         namespace: clusters
       data:
         tuning: |
           apiVersion: tuned.openshift.io/v1
           kind: Tuned
           metadata:
             name: hugepages
             namespace: openshift-cluster-node-tuning-operator
           spec:
             profile:
             - data: |
                 [main]
                 summary=Boot time configuration for hugepages
                 include=openshift-node
                 [bootloader]
                 cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50
               name: openshift-node-hugepages
             recommend:
             - priority: 20
               profile: openshift-node-hugepages

   注記

   .spec.recommend.match フィールドは意図的に空白のままにしています。この場合、この Tuned オブジェクトは、この ConfigMap オブジェクトが参照されているノードプール内のすべてのノードに適用されます。同じハードウェア設定を持つノードを同じノードプールにグループ化します。そうしないと、TuneD オペランドは、同じノードプールを共有する 2 つ以上のノードに対して競合するカーネルパラメーターを計算する可能性があります。

2. 管理クラスターに ConfigMap オブジェクトを作成します。

   $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-hugepages.yaml

3. NodePool マニフェスト YAML ファイルを作成し、NodePool のアップグレードタイプをカスタマイズして、spec.tuningConfig セクションで作成した ConfigMap オブジェクトを参照します。hypershift CLI を使用して NodePool マニフェストを作成し、hugepages-nodepool.yaml という名前のファイルに保存します。

       NODEPOOL_NAME=hugepages-example
       INSTANCE_TYPE=m5.2xlarge
       NODEPOOL_REPLICAS=2
   
       hypershift create nodepool aws \
         --cluster-name $CLUSTER_NAME \
         --name $NODEPOOL_NAME \
         --node-count $NODEPOOL_REPLICAS \
         --instance-type $INSTANCE_TYPE \
         --render > hugepages-nodepool.yaml

4. hugepages-nodepool.yaml ファイルで、.spec.management.upgradeType を InPlace に設定し、作成した tuned-hugepages ConfigMap オブジェクトを参照するように .spec.tuningConfig を設定します。

       apiVersion: hypershift.openshift.io/v1alpha1
       kind: NodePool
       metadata:
         name: hugepages-nodepool
         namespace: clusters
         ...
       spec:
         management:
           ...
           upgradeType: InPlace
         ...
         tuningConfig:
         - name: tuned-hugepages

   注記

   新しい MachineConfig オブジェクトを適用するときに不要なノードの再作成を回避するには、.spec.management.upgradeType を InPlace に設定します。Replace アップグレードタイプを使用する場合、ノードは完全に削除され、TuneD オペランドが計算した新しいカーネルブートパラメーターを適用すると、新しいノードでノードを置き換えることができます。

5. 管理クラスターに NodePool を作成します。

   $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f hugepages-nodepool.yaml

1. ホストされたクラスター内の Tuned オブジェクトを一覧表示します。

   $ oc --kubeconfig="$HC_KUBECONFIG" get Tuneds -n openshift-cluster-node-tuning-operator

   出力例

   NAME                 AGE
   default              123m
   hugepages-8dfb1fed   1m23s
   rendered             123m

2. ホストされたクラスター内の Profile オブジェクトを一覧表示します。

   $ oc --kubeconfig="$HC_KUBECONFIG" get Profiles -n openshift-cluster-node-tuning-operator

   出力例

   NAME                           TUNED                      APPLIED   DEGRADED   AGE
   nodepool-1-worker-1            openshift-node             True      False      132m
   nodepool-1-worker-2            openshift-node             True      False      131m
   hugepages-nodepool-worker-1    openshift-node-hugepages   True      False      4m8s
   hugepages-nodepool-worker-2    openshift-node-hugepages   True      False      3m57s

   新しい NodePool の両方のワーカーノードには、openshift-node-hugepages プロファイルが適用されています。

3. チューニングが正しく適用されたことを確認するには、ノードでデバッグシェルを起動し、/proc/cmdline を確認します。

   $ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline

   出力例

   BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50

手順

1. オプション: ノードにラベルを指定します。

   # oc label node perf-node.example.com cpumanager=true

2. CPU マネージャーを有効にする必要のあるノードの MachineConfigPool を編集します。この例では、すべてのワーカーで CPU マネージャーが有効にされています。

   # oc edit machineconfigpool worker

3. ラベルをワーカーのマシン設定プールに追加します。

   metadata:
     creationTimestamp: 2020-xx-xxx
     generation: 3
     labels:
       custom-kubelet: cpumanager-enabled

4. KubeletConfig、cpumanager-kubeletconfig.yaml、カスタムリソース (CR) を作成します。直前の手順で作成したラベルを参照し、適切なノードを新規の kubelet 設定で更新します。machineConfigPoolSelector セクションを参照してください。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static 1
        cpuManagerReconcilePeriod: 5s 2

   1

   ポリシーを指定します。

   • noneこのポリシーは、既存のデフォルト CPU アフィニティースキームを明示的に有効にし、スケジューラーが自動的に実行するもの以外のアフィニティーを提供しません。これはデフォルトポリシーになります。
   • staticこのポリシーは、整数の CPU 要求を持つ保証された Pod 内のコンテナーを許可します。また、ノードの排他的 CPU へのアクセスも制限します。static の場合は、小文字 の s を使用する必要があります。

   2

   オプション:CPU マネージャーの調整頻度を指定します。デフォルトは 5s です。

5. 動的な kubelet 設定を作成します。

   # oc create -f cpumanager-kubeletconfig.yaml

   これにより、CPU マネージャー機能が kubelet 設定に追加され、必要な場合には Machine Config Operator (MCO) がノードを再起動します。CPU マネージャーを有効にするために再起動する必要はありません。

6. マージされた kubelet 設定を確認します。

   # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

   出力例

          "ownerReferences": [
               {
                   "apiVersion": "machineconfiguration.openshift.io/v1",
                   "kind": "KubeletConfig",
                   "name": "cpumanager-enabled",
                   "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
               }
           ]

7. ワーカーで更新された kubelet.conf を確認します。

   # oc debug node/perf-node.example.com
   sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

   出力例

   cpuManagerPolicy: static        1
   cpuManagerReconcilePeriod: 5s   2

   1 2

   これらの設定は、KubeletConfig CR を作成する際に定義されたものです。

8. コア 1 つまたは複数を要求する Pod を作成します。制限および要求の CPU の値は整数にする必要があります。これは、対象の Pod 専用のコア数です。

   # cat cpumanager-pod.yaml

   出力例

   apiVersion: v1
   kind: Pod
   metadata:
     generateName: cpumanager-
   spec:
     containers:
     - name: cpumanager
       image: gcr.io/google_containers/pause-amd64:3.0
       resources:
         requests:
           cpu: 1
           memory: "1G"
         limits:
           cpu: 1
           memory: "1G"
     nodeSelector:
       cpumanager: "true"

9. Pod を作成します。

   # oc create -f cpumanager-pod.yaml

10. Pod がラベル指定されたノードにスケジュールされていることを確認します。

    # oc describe pod cpumanager

    出力例

    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true

11. cgroups が正しく設定されていることを確認します。pause プロセスのプロセス ID (PID) を取得します。

    # ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
    └─kubepods.slice
      ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
      │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
      │ └─32706 /pause

    QoS (quality of service) 層 Guaranteed の Pod は、kubepods.slice に配置されます。他の QoS 層の Pod は、kubepods の子である cgroups に配置されます。

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done

    出力例

    cpuset.cpus 1
    tasks 32706

12. 対象のタスクで許可される CPU 一覧を確認します。

    # grep ^Cpus_allowed_list /proc/32706/status

    出力例

     Cpus_allowed_list:    1

13. システム上の別の Pod (この場合は burstable QoS 層にある Pod) が、Guaranteed Pod に割り当てられたコアで実行できないことを確認します。

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    0
    # oc describe node perf-node.example.com

    出力例

    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)

    この仮想マシンには、2 つの CPU コアがあります。system-reserved 設定は 500 ミリコアを予約し、Node Allocatable の量になるようにノードの全容量からコアの半分を引きます。ここで Allocatable CPU は 1500 ミリコアであることを確認できます。これは、それぞれがコアを 1 つ受け入れるので、CPU マネージャー Pod の 1 つを実行できることを意味します。1 つのコア全体は 1000 ミリコアに相当します。2 つ目の Pod をスケジュールしようとする場合、システムは Pod を受け入れますが、これがスケジュールされることはありません。

    NAME                    READY   STATUS    RESTARTS   AGE
    cpumanager-6cqz7        1/1     Running   0          33m
    cpumanager-7qc2t        0/1     Pending   0          11s

1. cpumanager-enabled カスタムリソース (CR) で Topology Manager 割り当てポリシーを設定します。

   $ oc edit KubeletConfig cpumanager-enabled

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static 1
        cpuManagerReconcilePeriod: 5s
        topologyManagerPolicy: single-numa-node 2

   1

   このパラメーターは、小文字の s で static にする必要があります。

   2

   選択した Topology Manager 割り当てポリシーを指定します。このポリシーは single-numa-node になります。使用できる値は、default、best-effort、restricted、single-numa-node です。

手順

1. ワーカーノードのカスタム kubelet 設定を有効にする MachineConfigPool カスタムリソースを作成します。

   1. 以下の YAML を nro-machineconfig.yaml ファイルに保存します。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        labels:
          cnf-worker-tuning: enabled
          machineconfiguration.openshift.io/mco-built-in: ""
          pools.operator.machineconfiguration.openshift.io/worker: ""
        name: worker
      spec:
        machineConfigSelector:
          matchLabels:
            machineconfiguration.openshift.io/role: worker
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""

   2. 以下のコマンドを実行して MachineConfigPool CR を作成します。

      $ oc create -f nro-machineconfig.yaml

2. NUMAResourcesOperator カスタムリソースを作成します。

   1. 以下の YAML を nrop.yaml ファイルに保存します。

      apiVersion: nodetopology.openshift.io/v1alpha1
      kind: NUMAResourcesOperator
      metadata:
        name: numaresourcesoperator
      spec:
        nodeGroups:
        - machineConfigPoolSelector:
            matchLabels:
              pools.operator.machineconfiguration.openshift.io/worker: "" 1

      1

      関連する MachineConfigPool CR でワーカーノードに適用されるラベルと一致する必要があります。

   2. 以下のコマンドを実行して、NUMAResourcesOperator CR を作成します。

      $ oc create -f nrop.yaml

手順

1. マシンプロファイルの Pod アドミタンスポリシーを設定する KubeletConfig カスタムリソースを作成します。

   1. 以下の YAML を nro-kubeletconfig.yaml ファイルに保存します。

      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      metadata:
        name: cnf-worker-tuning
      spec:
        machineConfigPoolSelector:
          matchLabels:
            cnf-worker-tuning: enabled
        kubeletConfig:
          cpuManagerPolicy: "static" 1
          cpuManagerReconcilePeriod: "5s"
          reservedSystemCPUs: "0,1"
          memoryManagerPolicy: "Static" 2
          evictionHard:
            memory.available: "100Mi"
          kubeReserved:
            memory: "512Mi"
          reservedMemory:
            - numaNode: 0
              limits:
                memory: "1124Mi"
          systemReserved:
            memory: "512Mi"
          topologyManagerPolicy: "single-numa-node" 3
          topologyManagerScope: "pod"

      1

      cpuManagerPolicy の場合、static は小文字の s を使用する必要があります。

      2

      memoryManagerPolicy の場合、Static は大文字の S を使用する必要があります。

      3

      topologyManagerPolicy は single-numa-node に設定する必要があります。

   2. 次のコマンドを実行して、KubeletConfig カスタムリソース (CR) を作成します。

      $ oc create -f nro-kubeletconfig.yaml

2. NUMA 対応のカスタム Pod スケジューラーをデプロイする NUMAResourcesScheduler カスタムリソースを作成します。

   1. 以下の YAML を nro-scheduler.yaml ファイルに保存します。

      apiVersion: nodetopology.openshift.io/v1alpha1
      kind: NUMAResourcesScheduler
      metadata:
        name: numaresourcesscheduler
      spec:
        imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.12"

   2. 次のコマンドを実行して、NUMAResourcesScheduler CR を作成します。

      $ oc create -f nro-scheduler.yaml

手順

1. 次のコマンドを実行して、クラスターにデプロイされている NUMA 対応スケジューラーの名前を取得します。

   $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

   出力例

   topo-aware-scheduler

2. topo-aware-scheduler という名前のスケジューラーを使用する Deployment CR を作成します。次に例を示します。

   1. 以下の YAML を nro-deployment.yaml ファイルに保存します。

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: numa-deployment-1
        namespace: openshift-numaresources
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: test
        template:
          metadata:
            labels:
              app: test
          spec:
            schedulerName: topo-aware-scheduler 1
            containers:
            - name: ctnr
              image: quay.io/openshifttest/hello-openshift:openshift
              imagePullPolicy: IfNotPresent
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "10"
                requests:
                  memory: "100Mi"
                  cpu: "10"
            - name: ctnr2
              image: gcr.io/google_containers/pause-amd64:3.0
              imagePullPolicy: IfNotPresent
              command: ["/bin/sh", "-c"]
              args: [ "while true; do sleep 1h; done;" ]
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "8"
                requests:
                  memory: "100Mi"
                  cpu: "8"

      1

      schedulerName は、クラスターにデプロイされている NUMA 対応のスケジューラーの名前 (topo-aware-scheduler など) と一致する必要があります。

   2. 次のコマンドを実行して、Deployment CR を作成します。

      $ oc create -f nro-deployment.yaml

検証

1. デプロイメントが正常に行われたことを確認します。

   $ oc get pods -n openshift-numaresources

   出力例

   NAME                                                READY   STATUS    RESTARTS   AGE
   numa-deployment-1-56954b7b46-pfgw8                  2/2     Running   0          129m
   numaresources-controller-manager-7575848485-bns4s   1/1     Running   0          15h
   numaresourcesoperator-worker-dvj4n                  2/2     Running   0          18h
   numaresourcesoperator-worker-lcg4t                  2/2     Running   0          16h
   secondary-scheduler-56994cf6cf-7qf4q                1/1     Running   0          18h

2. 次のコマンドを実行して、topo-aware-scheduler がデプロイされた Pod をスケジュールしていることを確認します。

   $ oc describe pod numa-deployment-1-56954b7b46-pfgw8 -n openshift-numaresources

   出力例

   Events:
     Type    Reason          Age   From                  Message
     ----    ------          ----  ----                  -------
     Normal  Scheduled       130m  topo-aware-scheduler  Successfully assigned openshift-numaresources/numa-deployment-1-56954b7b46-pfgw8 to compute-0.example.com

   注記

   スケジューリングに使用可能なリソースよりも多くのリソースを要求するデプロイメントは、MinimumReplicasUnavailable エラーで失敗します。必要なリソースが利用可能になると、デプロイメントは成功します。Pod は、必要なリソースが利用可能になるまで Pending 状態のままになります。

3. ノードに割り当てられる予定のリソースが一覧表示されていることを確認します。以下のコマンドを実行します。

   $ oc describe noderesourcetopologies.topology.node.k8s.io

   出力例

   ...
   
   Zones:
     Costs:
       Name:   node-0
       Value:  10
       Name:   node-1
       Value:  21
     Name:     node-0
     Resources:
       Allocatable:  39
       Available:    21 1
       Capacity:     40
       Name:         cpu
       Allocatable:  6442450944
       Available:    6442450944
       Capacity:     6442450944
       Name:         hugepages-1Gi
       Allocatable:  134217728
       Available:    134217728
       Capacity:     134217728
       Name:         hugepages-2Mi
       Allocatable:  262415904768
       Available:    262206189568
       Capacity:     270146007040
       Name:         memory
     Type:           Node

   1

   保証された Pod に割り当てられたリソースが原因で、Available な容量が減少しています。

   保証された Pod によって消費されるリソースは、noderesourcetopologies.topology.node.k8s.io に一覧表示されている使用可能なノードリソースから差し引かれます。

4. Best-effort または Burstable の サービス品質 (qosClass) を持つ Pod のリソース割り当てが、noderesourcetopologies.topology.node.k8s.io の NUMA ノードリソースに反映されていません。Pod の消費リソースがノードリソースの計算に反映されない場合は、次のコマンドを実行して、Pod に Guaranteed の qosClass があることを確認します。

   $ oc get pod <pod_name> -n <pod_namespace> -o jsonpath="{ .status.qosClass }"

   出力例

   Guaranteed

手順

1. 次のコマンドを実行して、noderesourcetopologies CRD がクラスターにデプロイされていることを確認します。

   $ oc get crd | grep noderesourcetopologies

   出力例

   NAME                                                              CREATED AT
   noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z

2. 次のコマンドを実行して、NUMA 対応スケジューラー名が NUMA 対応ワークロードで指定された名前と一致することを確認します。

   $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

   出力例

   topo-aware-scheduler

3. NUMA 対応のスケジュール可能なノードに noderesourcetopologies CR が適用されていることを確認します。以下のコマンドを実行します。

   $ oc get noderesourcetopologies.topology.node.k8s.io

   出力例

   NAME                    AGE
   compute-0.example.com   17h
   compute-1.example.com   17h

   注記

   ノードの数は、マシン設定プール (mcp) ワーカー定義によって設定されているワーカーノードの数と等しくなければなりません。

4. 次のコマンドを実行して、スケジュール可能なすべてのノードの NUMA ゾーンの粒度を確認します。

   $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml

   出力例

   apiVersion: v1
   items:
   - apiVersion: topology.node.k8s.io/v1alpha1
     kind: NodeResourceTopology
     metadata:
       annotations:
         k8stopoawareschedwg/rte-update: periodic
       creationTimestamp: "2022-06-16T08:55:38Z"
       generation: 63760
       name: worker-0
       resourceVersion: "8450223"
       uid: 8b77be46-08c0-4074-927b-d49361471590
     topologyPolicies:
     - SingleNUMANodeContainerLevel
     zones:
     - costs:
       - name: node-0
         value: 10
       - name: node-1
         value: 21
       name: node-0
       resources:
       - allocatable: "38"
         available: "38"
         capacity: "40"
         name: cpu
       - allocatable: "134217728"
         available: "134217728"
         capacity: "134217728"
         name: hugepages-2Mi
       - allocatable: "262352048128"
         available: "262352048128"
         capacity: "270107316224"
         name: memory
       - allocatable: "6442450944"
         available: "6442450944"
         capacity: "6442450944"
         name: hugepages-1Gi
       type: Node
     - costs:
       - name: node-0
         value: 21
       - name: node-1
         value: 10
       name: node-1
       resources:
       - allocatable: "268435456"
         available: "268435456"
         capacity: "268435456"
         name: hugepages-2Mi
       - allocatable: "269231067136"
         available: "269231067136"
         capacity: "270573244416"
         name: memory
       - allocatable: "40"
         available: "40"
         capacity: "40"
         name: cpu
       - allocatable: "1073741824"
         available: "1073741824"
         capacity: "1073741824"
         name: hugepages-1Gi
       type: Node
   - apiVersion: topology.node.k8s.io/v1alpha1
     kind: NodeResourceTopology
     metadata:
       annotations:
         k8stopoawareschedwg/rte-update: periodic
       creationTimestamp: "2022-06-16T08:55:37Z"
       generation: 62061
       name: worker-1
       resourceVersion: "8450129"
       uid: e8659390-6f8d-4e67-9a51-1ea34bba1cc3
     topologyPolicies:
     - SingleNUMANodeContainerLevel
     zones: 1
     - costs:
       - name: node-0
         value: 10
       - name: node-1
         value: 21
       name: node-0
       resources: 2
       - allocatable: "38"
         available: "38"
         capacity: "40"
         name: cpu
       - allocatable: "6442450944"
         available: "6442450944"
         capacity: "6442450944"
         name: hugepages-1Gi
       - allocatable: "134217728"
         available: "134217728"
         capacity: "134217728"
         name: hugepages-2Mi
       - allocatable: "262391033856"
         available: "262391033856"
         capacity: "270146301952"
         name: memory
       type: Node
     - costs:
       - name: node-0
         value: 21
       - name: node-1
         value: 10
       name: node-1
       resources:
       - allocatable: "40"
         available: "40"
         capacity: "40"
         name: cpu
       - allocatable: "1073741824"
         available: "1073741824"
         capacity: "1073741824"
         name: hugepages-1Gi
       - allocatable: "268435456"
         available: "268435456"
         capacity: "268435456"
         name: hugepages-2Mi
       - allocatable: "269192085504"
         available: "269192085504"
         capacity: "270534262784"
         name: memory
       type: Node
   kind: List
   metadata:
     resourceVersion: ""
     selfLink: ""

   1

   zones 以下の各スタンザは、単一の NUMA ゾーンのリソースを記述しています。

   2

   resources は、NUMA ゾーンリソースの現在の状態を記述しています。items.zones.resources.available 以下に記載されているリソースが、保証された各 Pod に割り当てられた排他的な NUMA ゾーンリソースに対応していることを確認します。

1. YAML 設定ファイル cluster-monitoring-config.yml を作成します。以下に例を示します。

   apiVersion: v1
   kind: ConfigMap
   data:
     config.yaml: |
       prometheusK8s:
         retention: {{PROMETHEUS_RETENTION_PERIOD}} 1
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         volumeClaimTemplate:
           spec:
             storageClassName: {{STORAGE_CLASS}} 2
             resources:
               requests:
                 storage: {{PROMETHEUS_STORAGE_SIZE}} 3
       alertmanagerMain:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         volumeClaimTemplate:
           spec:
             storageClassName: {{STORAGE_CLASS}} 4
             resources:
               requests:
                 storage: {{ALERTMANAGER_STORAGE_SIZE}} 5
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring

   1

   標準の値は PROMETHEUS_RETENTION_PERIOD=15d になります。時間は、接尾辞 s、m、h、d のいずれかを使用する単位で測定されます。

   2 4

   クラスターのストレージクラス。

   3

   標準の値は PROMETHEUS_STORAGE_SIZE=2000Gi です。ストレージの値には、接尾辞 E、P、T、G、M、K のいずれかを使用した単純な整数または固定小数点整数を使用できます。 また、2 のべき乗の値 (Ei、Pi、Ti、Gi、Mi、Ki) を使用することもできます。

   5

   標準の値は ALERTMANAGER_STORAGE_SIZE=20Gi です。ストレージの値には、接尾辞 E、P、T、G、M、K のいずれかを使用した単純な整数または固定小数点整数を使用できます。 また、2 のべき乗の値 (Ei、Pi、Ti、Gi、Mi、Ki) を使用することもできます。

2. 保存期間、ストレージクラス、およびストレージサイズの値を追加します。
3. ファイルを保存します。

4. 以下を実行して変更を適用します。

   $ oc create -f cluster-monitoring-config.yaml

1. 一時停止 Pod は、2000 ノードスケールで OpenShift Container Platform のコントロールプレーンコンポーネントにストレスをかけるためにデプロイされました。同様の数値にスケーリングできるかどうかは、特定のデプロイメントとワークロードのパラメーターによって異なります。
2. ここで表示される Pod 数はテスト用の Pod 数です。実際の Pod 数は、アプリケーションのメモリー、CPU、ストレージ要件により異なります。
3. これは、ワーカーノードごとに 500 の Pod を持つ 100 ワーカーノードを含むクラスターでテストされています。デフォルトの maxPods は 250 です。500 maxPods に到達するには、クラスターはカスタム kubelet 設定を使用し、maxPods が 500 に設定された状態で作成される必要があります。500 ユーザー Pod が必要な場合は、ノード上に 10-15 のシステム Pod がすでに実行されているため、hostPrefix が 22 である必要があります。永続ボリューム要求 (PVC) が割り当てられている Pod の最大数は、PVC の割り当て元のストレージバックエンドによって異なります。このテストでは、OpenShift Data Foundation v4 (OCS v4) のみが、本書で説明されているノードごとの Pod 数に対応することができました。
4. 有効なプロジェクトが多数ある場合、キースペースが過剰に拡大し、スペースのクォータを超過すると、etcd はパフォーマンスの低下による影響を受ける可能性があります。etcd ストレージを解放するために、デフラグを含む etcd の定期的なメンテナンスを行うことを強くお勧めします。
5. システムには、状態の変更に対する対応として特定の namespace にある全オブジェクトに対して反復する多数のコントロールループがあります。単一の namespace に特定タイプのオブジェクトの数が多くなると、ループのコストが上昇し、特定の状態変更を処理する速度が低下します。この制限については、アプリケーションの各種要件を満たすのに十分な CPU、メモリー、およびディスクがシステムにあることが前提となっています。
6. 各サービスポートと各サービスのバックエンドには、iptables の対応するエントリーがあります。特定のサービスのバックエンド数は、エンドポイントのオブジェクトサイズに影響があり、その結果、システム全体に送信されるデータサイズにも影響を与えます。
7. OpenShift Container Platform には、OpenShift Container Platform によってインストールされたもの、OpenShift Container Platform と統合された製品、およびユーザー作成の CRD を含め、合計 512 のカスタムリソース定義 (CRD) の制限があります。512 を超える CRD が作成されている場合は、oc コマンドリクエストのスロットリングが適用される可能性があります。

1. NetApp NFS は Trident を使用する場合に動的 PV のプロビジョニングをサポートします。

手順

1. 次の YAML を使用して、mount_namespace_config.yaml という名前のファイルを作成します。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 99-kubens-master
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - enabled: true
           name: kubens.service
   ---
   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: worker
     name: 99-kubens-worker
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - enabled: true
           name: kubens.service

2. 次のコマンドを実行して、マウント namespace MachineConfig CR を適用します。

   $ oc apply -f mount_namespace_config.yaml

   出力例

   machineconfig.machineconfiguration.openshift.io/99-kubens-master created
   machineconfig.machineconfiguration.openshift.io/99-kubens-worker created

3. MachineConfig CR がクラスターに適用されるまで、最大 30 分かかる場合があります。次のコマンドを実行して、MachineConfig CR のステータスをチェックできます。

   $ oc get mcp

   出力例

   NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
   master   rendered-master-03d4bc4befb0f4ed3566a2c8f7636751   False     True       False      3              0                   0                     0                      45m
   worker   rendered-worker-10577f6ab0117ed1825f8af2ac687ddf   False     True       False      3              1                   1

4. 次のコマンドを実行した後、MachineConfig CR がすべてのコントロールプレーンとワーカーノードに正常に適用されるまで待ちます。

   $ oc wait --for=condition=Updated mcp --all --timeout=30m

   出力例

   machineconfigpool.machineconfiguration.openshift.io/master condition met
   machineconfigpool.machineconfiguration.openshift.io/worker condition met

1. クラスターホストへのデバッグシェルを開きます。

   $ oc debug node/<node_name>

2. chroot セッションを開きます。

   sh-4.4# chroot /host

3. systemd マウント namespace を確認します。

   sh-4.4# readlink /proc/1/ns/mnt

   出力例

   mnt:[4026531953]

4. kubelet マウント namespace をチェックします。

   sh-4.4# readlink /proc/$(pgrep kubelet)/ns/mnt

   出力例

   mnt:[4026531840]

5. CRI-O マウント namespace を確認します。

   sh-4.4# readlink /proc/$(pgrep crio)/ns/mnt

   出力例

   mnt:[4026531840]

手順

1. クラスターホストへのリモート SSH シェルを開きます。以下に例を示します。

   $ ssh core@<node_name>

2. root ユーザーとして、提供された kubesenter スクリプトを使用してコマンドを実行します。Kubernetes namespace 内で単一のコマンドを実行するには、コマンドと任意の引数を kubenenter スクリプトに提供します。たとえば、Kubernetes namespace 内で findmnt コマンドを実行するには、次のコマンドを実行します。

   [core@control-plane-1 ~]$ sudo kubensenter findmnt

   出力例

   kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt
   TARGET                                SOURCE                 FSTYPE     OPTIONS
   /                                     /dev/sda4[/ostree/deploy/rhcos/deploy/32074f0e8e5ec453e56f5a8a7bc9347eaa4172349ceab9c22b709d9d71a3f4b0.0]
   |                                                            xfs        rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota
                                         shm                    tmpfs
   ...

3. Kubernetes namespace 内で新しいインタラクティブシェルを開始するには、引数を指定せずに kubesenter スクリプトを実行します。

   [core@control-plane-1 ~]$ sudo kubensenter

   出力例

   kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt

1. ベアメタルホスト CR に cluster.k8s.io/delete-machine: true のアノテーションを付けます。
2. 関連するコンピュートマシンセットをスケールダウンします

手順

1. 以下の例のような hugepages-volume-pod.yaml ファイルを作成します。

   apiVersion: v1
   kind: Pod
   metadata:
     generateName: hugepages-volume-
     labels:
       app: hugepages-example
   spec:
     containers:
     - securityContext:
         capabilities:
           add: [ "IPC_LOCK" ]
       image: rhel7:latest
       command:
       - sleep
       - inf
       name: example
       volumeMounts:
       - mountPath: /dev/hugepages
         name: hugepage
       - mountPath: /etc/podinfo
         name: podinfo
       resources:
         limits:
           hugepages-1Gi: 2Gi
           memory: "1Gi"
           cpu: "1"
         requests:
           hugepages-1Gi: 2Gi
       env:
       - name: REQUESTS_HUGEPAGES_1GI <.>
         valueFrom:
           resourceFieldRef:
             containerName: example
             resource: requests.hugepages-1Gi
     volumes:
     - name: hugepage
       emptyDir:
         medium: HugePages
     - name: podinfo
       downwardAPI:
         items:
           - path: "hugepages_1G_request" <.>
             resourceFieldRef:
               containerName: example
               resource: requests.hugepages-1Gi
               divisor: 1Gi

   <.> では、requests.hugepages-1Gi からリソースの使用を読み取り、REQUESTS_HUGEPAGES_1GI 環境変数としてその値を公開するように指定し、2 つ目の <.> は、requests.hugepages-1Gi からのリソースの使用を読み取り、/etc/podinfo/hugepages_1G_request ファイルとして値を公開するように指定します。

2. hugepages-volume-pod.yaml ファイルから Pod を作成します。

   $ oc create -f hugepages-volume-pod.yaml

検証

1. REQUESTS_HUGEPAGES_1GI 環境 変数の値を確認します。

   $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
        -- env | grep REQUESTS_HUGEPAGES_1GI

   出力例

   REQUESTS_HUGEPAGES_1GI=2147483648

2. /etc/podinfo/hugepages_1G_request ファイルの値を確認します。

   $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
        -- cat /etc/podinfo/hugepages_1G_request

   出力例

   2

手順

1. 以下の内容でファイルを作成し、thp-disable-tuned.yaml という名前を付けます。

   apiVersion: tuned.openshift.io/v1
   kind: Tuned
   metadata:
     name: thp-workers-profile
     namespace: openshift-cluster-node-tuning-operator
   spec:
     profile:
     - data: |
         [main]
         summary=Custom tuned profile for OpenShift to turn off THP on worker nodes
         include=openshift-node
   
         [vm]
         transparent_hugepages=never
       name: openshift-thp-never-worker
   
     recommend:
     - match:
       - label: node-role.kubernetes.io/worker
       priority: 25
       profile: openshift-thp-never-worker

2. Tuned オブジェクトを作成します。

   $ oc create -f thp-disable-tuned.yaml

3. アクティブなプロファイルの一覧を確認します。

   $ oc get profile -n openshift-cluster-node-tuning-operator

1. Node Tuning Operator を使用してパフォーマンスプロファイルを設定しました。
2. 必要なすべての CNF 設定をクラスターに適用しました。
3. クラスターに既存の MachineConfigPool CR が適用されている。デフォルトのワーカープールは worker-cnf です。

手順

1. kubeconfig ファイルを含むディレクトリーでシェルプロンプトを開きます。

   現在のディレクトリーにある kubeconfig ファイルとそれに関連する $KUBECONFIG 環境変数を含むテストイメージを提供し、ボリュームを介してマウントします。これにより、実行中のコンテナーがコンテナー内から kubeconfig ファイルを使用できるようになります。

2. 次のコマンドを入力して、レイテンシーテストを実行します。

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
   /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"

3. オプション: -ginkgo.dryRun を追加して、ドライランモードでレイテンシーテストを実行します。これは、テストの実行内容を確認するのに役立ちます。
4. オプション: -ginkgo.v を追加して、詳細度を上げてテストを実行します。

5. オプション: 特定のパフォーマンスプロファイルに対してレイテンシーテストを実行するには、次のコマンドを実行し、適切な値を置き換えます。

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   -e LATENCY_TEST_RUN=true -e FEATURES=performance -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
   -e PERF_TEST_PROFILE=<performance_profile> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
   /usr/bin/test-run.sh -ginkgo.focus="[performance]\ Latency\ Test"

   ここでは、以下のようになります。

   <performance_profile>

   レイテンシーテストを実行するパフォーマンスプロファイルの名前です。

   重要

   有効なレイテンシーテストの結果を得るには、テストを少なくとも 12 時間実行します。

1. cnf-tests イメージをカスタム切断レジストリーにミラーリングします。
2. カスタムの切断されたレジストリーからイメージを使用するようにテストに指示します。

1. クラスターおよび registry.redhat.io にアクセスできる中間マシンから次のコマンドを実行します。

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \
   /usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -

   ここでは、以下のようになります。

   <disconnected_registry>

   my.local.registry:5000/ など、設定した切断されたミラーレジストリーです。

2. cnf-tests イメージを切断されたレジストリーにミラーリングした場合は、テストの実行時にイメージの取得に使用された元のレジストリーをオーバーライドする必要があります。次に例を示します。

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   -e DISCOVERY_MODE=true -e FEATURES=performance -e IMAGE_REGISTRY="<disconnected_registry>" \
   -e CNF_TESTS_IMAGE="cnf-tests-rhel8:v4.12" \
   /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"

手順

1. レジストリーをルートを使用して公開し、レジストリーへの外部アクセスを取得します。

   $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge

2. 次のコマンドを実行して、レジストリーエンドポイントを取得します。

   $ REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')

3. イメージを公開する namespace を作成します。

   $ oc create ns cnftests

4. イメージストリームを、テストに使用されるすべての namespace で利用可能にします。これは、テスト namespace が cnf-tests イメージストリームからイメージを取得できるようにするために必要です。以下のコマンドを実行します。

   $ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests

   $ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests

5. 次のコマンドを実行して、docker シークレット名と認証トークンを取得します。

   $ SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}

   $ TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')

6. dockerauth.json ファイルを作成します。次に例を示します。

   $ echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json

7. イメージミラーリングを実行します。

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   registry.redhat.io/openshift4/cnf-tests-rhel8:4.12 \
   /usr/bin/mirror -registry $REGISTRY/cnftests |  oc image mirror --insecure=true \
   -a=$(pwd)/dockerauth.json -f -

8. テストを実行します。

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   -e DISCOVERY_MODE=true -e FEATURES=performance -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests \
   cnf-tests-local:latest /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"

手順

1. mirror コマンドは、デフォルトでアップストリームイメージをミラーリングしようとします。これは、以下の形式のファイルをイメージに渡すことで上書きできます。

   [
       {
           "registry": "public.registry.io:5000",
           "image": "imageforcnftests:4.12"
       }
   ]

2. ファイルを mirror コマンドに渡します。たとえば、images.json としてローカルに保存します。以下のコマンドでは、ローカルパスはコンテナー内の /kubeconfig にマウントされ、これを mirror コマンドに渡すことができます。

   $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
   registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 /usr/bin/mirror \
   --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \
   |  oc image mirror -f -

1. 中規模のワーカーのレイテンシープロファイルに移動します。

   1. node.config オブジェクトを編集します。

      $ oc edit nodes.config/cluster

   2. spec.workerLatencyProfile: MediumUpdateAverageReaction を追加します。

      node.config オブジェクトの例

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: MediumUpdateAverageReaction 1
      
       ...

      1

      中規模のワーカーレイテンシーポリシーを指定します。

      変更が適用されると、各ワーカーノードでのスケジューリングは無効になります。

      全ノードが Ready 状態に戻ると、以下のコマンドを使用して Kubernetes Controller Manager を確認し、これが適用されていることを確認できます。

      $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5

      出力例

       ...
          - lastTransitionTime: "2022-07-11T19:47:10Z"
            reason: ProfileUpdated
            status: "False"
            type: WorkerLatencyProfileProgressing
          - lastTransitionTime: "2022-07-11T19:47:10Z" 1
            message: all static pod revision(s) have updated latency profile
            reason: ProfileUpdated
            status: "True"
            type: WorkerLatencyProfileComplete
          - lastTransitionTime: "2022-07-11T19:20:11Z"
            reason: AsExpected
            status: "False"
            type: WorkerLatencyProfileDegraded
          - lastTransitionTime: "2022-07-11T19:20:36Z"
            status: "False"
       ...

      1

      プロファイルが適用され、アクティブであることを指定します。

2. 必要に応じて、ワーカーのレイテンシーが低いプロファイルに移動します。

   1. node.config オブジェクトを編集します。

      $ oc edit nodes.config/cluster

   2. spec.workerLatencyProfile の値を LowUpdateSlowReaction に変更します。

      node.config オブジェクトの例

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: LowUpdateSlowReaction 1
      
       ...

      1

      ワーカーの低レイテンシーポリシーの使用を指定します。

      変更が適用されると、各ワーカーノードでのスケジューリングは無効になります。

手順

1. OpenShift Container Platform Web コンソールで、Operators → OperatorHub ページに移動します。
2. 利用可能な Operator の一覧から Topology Aware Lifecycle Manager を検索し、Install をクリックします。
3. Installation mode ["All namespaces on the cluster (default)"] および Installed Namespace ("openshift-operators") のデフォルトの選択を維持し、Operator が適切にインストールされていることを確認します。
4. Install をクリックします。

1. Operators → Installed Operators ページに移動します。
2. Operator が All Namespaces ネームスペースにインストールされ、そのステータスが Succeeded であることを確認します。

1. Operators → Installed Operators ページに移動し、Status 列でエラーまたは失敗の有無を確認します。
2. Workloads → Pods ページに移動し、問題を報告している cluster-group-upgrades-controller-manager Pod のコンテナーのログを確認します。

手順

1. SubscriptionCR を作成します。

   1. Subscription CR を定義し、YAML ファイルを保存します (例: talm-subscription.yaml)。

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-topology-aware-lifecycle-manager-subscription
        namespace: openshift-operators
      spec:
        channel: "stable"
        name: topology-aware-lifecycle-manager
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. 以下のコマンドを実行して Subscription CR を作成します。

      $ oc create -f talm-subscription.yaml

検証

1. CSV リソースを調べて、インストールが成功したことを確認します。

   $ oc get csv -n openshift-operators

   出力例

   NAME                                                   DISPLAY                            VERSION               REPLACES                           PHASE
   topology-aware-lifecycle-manager.4.12.x   Topology Aware Lifecycle Manager   4.12.x                                      Succeeded

2. TALM が稼働していることを確認します。

   $ oc get deploy -n openshift-operators

   出力例

   NAMESPACE                                          NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
   openshift-operators                                cluster-group-upgrades-controller-manager        1/1     1            1           14s