スケーラビリティーおよびパフォーマンス

前提条件

1. 設定するノードタイプの静的な MachineConfigPool CR に関連付けられたラベルを取得します。以下のいずれかの手順を実行します。

   1. マシン設定プールを表示します。

      $ oc describe machineconfigpool <name>

      以下に例を示します。

      $ oc describe machineconfigpool worker

      出力例

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        creationTimestamp: 2019-02-08T14:52:39Z
        generation: 1
        labels:
          custom-kubelet: set-max-pods 1

      1

      ラベルが追加されると、labels の下に表示されます。

   2. ラベルが存在しない場合は、キー/値のペアを追加します。

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

手順

1. これは、選択可能なマシン設定オブジェクトを表示します。

   $ oc get machineconfig

   デフォルトで、2 つの kubelet 関連の設定である 01-master-kubelet および 01-worker-kubelet を選択できます。

2. ノードあたりの最大 Pod の現在の値を確認します。

   $ oc describe node <node_name>

   以下に例を示します。

   $ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94

   Allocatable スタンザで value: pods: <value> を検索します。

   出力例

   Allocatable:
    attachable-volumes-aws-ebs:  25
    cpu:                         3500m
    hugepages-1Gi:               0
    hugepages-2Mi:               0
    memory:                      15341844Ki
    pods:                        250

3. ワーカーノードでノードあたりの最大の Pod を設定するには、kubelet 設定を含むカスタムリソースファイルを作成します。

   重要

   特定のマシン設定プールをターゲットとする kubelet 設定は、依存するプールにも影響します。たとえば、ワーカーノードを含むプール用の kubelet 設定を作成すると、インフラストラクチャーノードを含むプールを含むすべてのサブセットプールにも設定が適用されます。これを回避するには、ワーカーノードのみを含む選択式を使用して新しいマシン設定プールを作成し、kubelet 設定でこの新しいプールをターゲットにする必要があります。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods 1
     kubeletConfig:
       maxPods: 500 2

   1

   Machine Config Pool からラベルを入力します。

   2

   kubelet 設定を追加します。この例では、maxPods を使用してノードあたりの最大 Pod を設定します。

   注記

   kubelet が API サーバーと通信する速度は、1 秒あたりのクエリー (QPS) およびバースト値により異なります。デフォルト値の 50 (kubeAPIQPS の場合) および 100 (kubeAPIBurst の場合) は、各ノードで制限された Pod が実行されている場合には十分な値です。ノード上に CPU およびメモリーリソースが十分にある場合には、kubelet QPS およびバーストレートを更新することが推奨されます。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: set-max-pods
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods
     kubeletConfig:
       maxPods: <pod_count>
       kubeAPIBurst: <burst_rate>
       kubeAPIQPS: <QPS>

   1. ラベルを使用してワーカーのマシン設定プールを更新します。

      $ oc label machineconfigpool worker custom-kubelet=set-max-pods

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

      $ oc create -f change-maxPods-cr.yaml

   3. KubeletConfig オブジェクトが作成されていることを確認します。

      $ oc get kubeletconfig

      出力例

      NAME                AGE
      set-max-pods        15m

      クラスター内のワーカーノードの数によっては、ワーカーノードが 1 つずつ再起動されるのを待機します。3 つのワーカーノードを持つクラスターの場合は、10 分 から 15 分程度かかる可能性があります。

4. 変更がノードに適用されていることを確認します。

   1. maxPods 値が変更されたワーカーノードで確認します。

      $ oc describe node <node_name>

   2. Allocatable スタンザを見つけます。

       ...
      Allocatable:
        attachable-volumes-gce-pd:  127
        cpu:                        3500m
        ephemeral-storage:          123201474766
        hugepages-1Gi:              0
        hugepages-2Mi:              0
        memory:                     14225400Ki
        pods:                       500 1
       ...

      1

      この例では、pods パラメーターは KubeletConfig オブジェクトに設定した値を報告するはずです。

5. KubeletConfig オブジェクトの変更を確認します。

   $ oc get kubeletconfigs set-max-pods -o yaml

   これは、以下の例のように True および type:Success のステータスを表示します。

   spec:
     kubeletConfig:
       maxPods: 500
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: set-max-pods
   status:
     conditions:
     - lastTransitionTime: "2021-06-30T17:04:07Z"
       message: Success
       status: "True"
       type: Success

手順

1. worker マシン設定プールを編集します。

   $ oc edit machineconfigpool worker

2. maxUnavailable フィールドを追加して、値を設定します。

   spec:
     maxUnavailable: <node_count>

   重要

   値を設定する際に、クラスターで実行されているアプリケーションに影響を与えずに利用不可にできるワーカーノードの数を検討してください。

手順

1. 新しいディスクをクラスターに接続し、デバッグシェルで lsblk コマンドを使用して、ディスクがノード内で検出されることを確認します。

   $ oc debug node/<node_name>

   # lsblk

   lsblk コマンドで報告された新しいディスクのデバイス名をメモします。

2. 次のような内容を含む MachineConfig YAML ファイルを etcd-mc.yml という名前で作成し、<new_disk_name> のインスタンスをメモしたデバイス名に置き換えます。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 98-var-lib-etcd
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - contents: |
             [Unit]
             Description=Make File System on /dev/<new_disk_name>
             DefaultDependencies=no
             BindsTo=dev-<new_disk_name>.device
             After=dev-<new_disk_name>.device var.mount
             Before=systemd-fsck@dev-<new_disk_name>.service
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
             ExecStart=/usr/lib/systemd/systemd-makefs xfs /dev/<new_disk_name>
             TimeoutSec=0
   
             [Install]
             WantedBy=var-lib-containers.mount
           enabled: true
           name: systemd-mkfs@dev-<new_disk_name>.service
         - contents: |
             [Unit]
             Description=Mount /dev/<new_disk_name> to /var/lib/etcd
             Before=local-fs.target
             Requires=systemd-mkfs@dev-<new_disk_name>.service
             After=systemd-mkfs@dev-<new_disk_name>.service var.mount
   
             [Mount]
             What=/dev/<new_disk_name>
             Where=/var/lib/etcd
             Type=xfs
             Options=defaults,prjquota
   
             [Install]
             WantedBy=local-fs.target
           enabled: true
           name: var-lib-etcd.mount
         - contents: |
             [Unit]
             Description=Sync etcd data if new mount is empty
             DefaultDependencies=no
             After=var-lib-etcd.mount var.mount
             Before=crio.service
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
             ExecCondition=/usr/bin/test ! -d /var/lib/etcd/member
             ExecStart=semanage fcontext -a -e /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
             ExecStart=/bin/rsync -ar /sysroot/ostree/deploy/rhcos/var/lib/etcd/ /var/lib/etcd/
             TimeoutSec=0
   
             [Install]
             WantedBy=multi-user.target graphical.target
           enabled: true
           name: sync-var-lib-etcd-to-etcd.service
         - contents: |
             [Unit]
             Description=Restore recursive SELinux security contexts
             DefaultDependencies=no
             After=var-lib-etcd.mount
             Before=crio.service
   
             [Service]
             Type=oneshot
             RemainAfterExit=yes
             ExecStart=/sbin/restorecon -R /var/lib/etcd/
             TimeoutSec=0
   
             [Install]
             WantedBy=multi-user.target graphical.target
           enabled: true
           name: restorecon-var-lib-etcd.service

3. cluster-admin 権限を持つユーザーとしてクラスターにログインし、マシン設定を作成します。

   $ oc login -u <username> -p <password>

   $ oc create -f etcd-mc.yml

   ノードが更新され、再起動されます。再起動が完了すると、次のイベントが発生します。

   • 指定したディスクに XFS ファイルシステムが作成されます。
   • ディスクは /var/lib/etc にマウントされます。
   • /sysroot/ostree/deploy/rhcos/var/lib/etcd のコンテンツは /var/lib/etcd に同期されます。
   • /var/lib/etcd の SELinux ラベルの復元が強制されます。
   • 古いコンテンツは削除されません。

4. ノードが別のディスク上に配置されたら、次のような内容で etcd-mc.yml ファイルを更新し、<new_disk_name> のインスタンスをメモしたデバイス名に置き換えます。

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     labels:
       machineconfiguration.openshift.io/role: master
     name: 98-var-lib-etcd
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
         - contents: |
             [Unit]
             Description=Mount /dev/<new_disk_name> to /var/lib/etcd
             Before=local-fs.target
             Requires=systemd-mkfs@dev-<new_disk_name>.service
             After=systemd-mkfs@dev-<new_disk_name>.service var.mount
   
             [Mount]
             What=/dev/<new_disk_name>
             Where=/var/lib/etcd
             Type=xfs
             Options=defaults,prjquota
   
             [Install]
             WantedBy=local-fs.target
           enabled: true
           name: var-lib-etcd.mount

5. ノードの再起動を防止するため、デバイスの作成と同期に使用するロジックを削除する修正バージョンを適用します。

   $ oc replace -f etcd-mc.yml

手順

1. cluster-monitoring-config 設定マップを編集し、nodeSelector を変更して infra ラベルを使用します。

   $ oc edit configmap cluster-monitoring-config -n openshift-monitoring

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: cluster-monitoring-config
     namespace: openshift-monitoring
   data:
     config.yaml: |+
       alertmanagerMain:
         nodeSelector: 1
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusK8s:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       prometheusOperator:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       k8sPrometheusAdapter:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       kubeStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       telemeterClient:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       openshiftStateMetrics:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute
       thanosQuerier:
         nodeSelector:
           node-role.kubernetes.io/infra: ""
         tolerations:
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoSchedule
         - key: node-role.kubernetes.io/infra
           value: reserved
           effect: NoExecute

   1 1

   適切な値が設定された nodeSelector パラメーターを、移動する必要のあるコンポーネントに追加します。表示されている形式の nodeSelector を使用することも、ノードに指定された値に基づいて <key>: <value> ペアを使用することもできます。インフラストラクチャーノードにテイントを追加した場合は、一致する容認も追加します。

2. モニタリング Pod が新規マシンに移行することを確認します。

   $ watch 'oc get pod -n openshift-monitoring -o wide'

3. コンポーネントが infra ノードに移動していない場合は、このコンポーネントを持つ Pod を削除します。

   $ oc delete pod -n openshift-monitoring <pod>

   削除された Pod からのコンポーネントが infra ノードに再作成されます。

手順

1. config/instance オブジェクトを表示します。

   $ oc get configs.imageregistry.operator.openshift.io/cluster -o yaml

   出力例

   apiVersion: imageregistry.operator.openshift.io/v1
   kind: Config
   metadata:
     creationTimestamp: 2019-02-05T13:52:05Z
     finalizers:
     - imageregistry.operator.openshift.io/finalizer
     generation: 1
     name: cluster
     resourceVersion: "56174"
     selfLink: /apis/imageregistry.operator.openshift.io/v1/configs/cluster
     uid: 36fd3724-294d-11e9-a524-12ffeee2931b
   spec:
     httpSecret: d9a012ccd117b1e6616ceccb2c3bb66a5fed1b5e481623
     logging: 2
     managementState: Managed
     proxy: {}
     replicas: 1
     requests:
       read: {}
       write: {}
     storage:
       s3:
         bucket: image-registry-us-east-1-c92e88cad85b48ec8b312344dff03c82-392c
         region: us-east-1
   status:
   ...

2. config/instance オブジェクトを編集します。

   $ oc edit configs.imageregistry.operator.openshift.io/cluster

   spec:
     affinity:
       podAntiAffinity:
         preferredDuringSchedulingIgnoredDuringExecution:
         - podAffinityTerm:
             namespaces:
             - openshift-image-registry
             topologyKey: kubernetes.io/hostname
           weight: 100
     logLevel: Normal
     managementState: Managed
     nodeSelector: 1
       node-role.kubernetes.io/infra: ""
     tolerations:
     - effect: NoSchedule
       key: node-role.kubernetes.io/infra
       value: reserved
     - effect: NoExecute
       key: node-role.kubernetes.io/infra
       value: reserved

   1

   適切な値が設定された nodeSelector パラメーターを、移動する必要のあるコンポーネントに追加します。表示されている形式の nodeSelector を使用することも、ノードに指定された値に基づいて <key>: <value> ペアを使用することもできます。インフラストラクチャーノードにテイントを追加した場合は、一致する容認も追加します。

3. レジストリー Pod がインフラストラクチャーノードに移動していることを確認します。

   1. 以下のコマンドを実行して、レジストリー Pod が置かれているノードを特定します。

      $ oc get pods -o wide -n openshift-image-registry

   2. ノードに指定したラベルがあることを確認します。

      $ oc describe node <node_name>

      コマンド出力を確認し、node-role.kubernetes.io/infra が LABELS リストにあることを確認します。

手順

1. ルーター Operator の IngressController カスタムリソースを表示します。

   $ oc get ingresscontroller default -n openshift-ingress-operator -o yaml

   コマンド出力は以下のテキストのようになります。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     creationTimestamp: 2019-04-18T12:35:39Z
     finalizers:
     - ingresscontroller.operator.openshift.io/finalizer-ingresscontroller
     generation: 1
     name: default
     namespace: openshift-ingress-operator
     resourceVersion: "11341"
     selfLink: /apis/operator.openshift.io/v1/namespaces/openshift-ingress-operator/ingresscontrollers/default
     uid: 79509e05-61d6-11e9-bc55-02ce4781844a
   spec: {}
   status:
     availableReplicas: 2
     conditions:
     - lastTransitionTime: 2019-04-18T12:36:15Z
       status: "True"
       type: Available
     domain: apps.<cluster>.example.com
     endpointPublishingStrategy:
       type: LoadBalancerService
     selector: ingresscontroller.operator.openshift.io/deployment-ingresscontroller=default

2. ingresscontroller リソースを編集し、 nodeSelector を infra ラベルを使用するように変更します。

   $ oc edit ingresscontroller default -n openshift-ingress-operator

     spec:
       nodePlacement:
         nodeSelector: 1
           matchLabels:
             node-role.kubernetes.io/infra: ""
         tolerations:
         - effect: NoSchedule
           key: node-role.kubernetes.io/infra
           value: reserved
         - effect: NoExecute
           key: node-role.kubernetes.io/infra
           value: reserved

   1

   適切な値が設定された nodeSelector パラメーターを、移動する必要のあるコンポーネントに追加します。表示されている形式の nodeSelector を使用することも、ノードに指定された値に基づいて <key>: <value> ペアを使用することもできます。インフラストラクチャーノードにテイントを追加した場合は、一致する容認も追加します。

3. ルーター Pod が infra ノードで実行されていることを確認します。

   1. ルーター Pod のリストを表示し、実行中の Pod のノード名をメモします。

      $ oc get pod -n openshift-ingress -o wide

      出力例

      NAME                              READY     STATUS        RESTARTS   AGE       IP           NODE                           NOMINATED NODE   READINESS GATES
      router-default-86798b4b5d-bdlvd   1/1      Running       0          28s       10.130.2.4   ip-10-0-217-226.ec2.internal   <none>           <none>
      router-default-955d875f4-255g8    0/1      Terminating   0          19h       10.129.2.4   ip-10-0-148-172.ec2.internal   <none>           <none>

      この例では、実行中の Pod は ip-10-0-217-226.ec2.internal ノードにあります。

   2. 実行中の Pod のノードのステータスを表示します。

      $ oc get node <node_name> 1

      1

      Pod のリストより取得した <node_name> を指定します。

      出力例

      NAME                          STATUS  ROLES         AGE   VERSION
      ip-10-0-217-226.ec2.internal  Ready   infra,worker  17h   v1.24.0

      ロールのリストに infra が含まれているため、Pod は正しいノードで実行されます。

手順

1. マシンセットを編集します。

   $ oc edit machineset <machine_set_name> -n openshift-machine-api

2. 変更を適用するためにマシンセットをスケーリングする際に必要になるため、spec.replicas フィールドの値を書き留めます。

   apiVersion: machine.openshift.io/v1beta1
   kind: MachineSet
   metadata:
     name: <machine_set_name>
     namespace: openshift-machine-api
   spec:
     replicas: 2 1
   # ...

   1

   この手順例では、replicas 値が 2 のコンピュートマシンセットを示しています。

3. 必要な設定オプションを使用してコンピュートマシンセット CR を更新し、変更を保存します。

4. 次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。

   $ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<machine_set_name>

   出力例

   NAME                        PHASE     TYPE         REGION      ZONE         AGE
   <machine_name_original_1>   Running   m6i.xlarge   us-west-1   us-west-1a   4h
   <machine_name_original_2>   Running   m6i.xlarge   us-west-1   us-west-1a   4h

5. 次のコマンドを実行して、更新されたコンピュートマシンセットで管理されるマシンごとに delete アノテーションを設定します。

   $ oc annotate machine/<machine_name_original_1> \
     -n openshift-machine-api \
     machine.openshift.io/delete-machine="true"

6. 次のコマンドを実行して、コンピュートマシンセットをレプリカ数の 2 倍にスケーリングします。

   $ oc scale --replicas=4 \1
     machineset <machine_set_name> \
     -n openshift-machine-api

   1

   元の例の値 2 は 2 倍の 4 になります。

7. 次のコマンドを実行して、更新されたコンピュートマシンセットによって管理されているマシンをリスト表示します。

   $ oc get -n openshift-machine-api machines -l machine.openshift.io/cluster-api-machineset=<machine_set_name>

   出力例

   NAME                        PHASE          TYPE         REGION      ZONE         AGE
   <machine_name_original_1>   Running        m6i.xlarge   us-west-1   us-west-1a   4h
   <machine_name_original_2>   Running        m6i.xlarge   us-west-1   us-west-1a   4h
   <machine_name_updated_1>    Provisioned    m6i.xlarge   us-west-1   us-west-1a   55s
   <machine_name_updated_2>    Provisioning   m6i.xlarge   us-west-1   us-west-1a   55s

   新しいマシンが Running フェーズにある場合、コンピュートマシンセットを元のレプリカ数にスケーリングできます。

8. 次のコマンドを実行して、コンピュートマシンセットのレプリカ数を元の数にスケーリングします。

   $ oc scale --replicas=2 \1
     machineset <machine_set_name> \
     -n openshift-machine-api

   1

   元の例の値は 2 です。

手順

1. マシンヘルスチェックの定義を含む healthcheck.yml ファイルを作成します。

2. healthcheck.yml ファイルをクラスターに適用します。

   $ oc apply -f healthcheck.yml

手順

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

   cpuManagerPolicy は、KubeletConfig CR の作成時に定義されます。

   2

   cpuManagerReconcilePeriod は、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. カスタムリソースで 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.11"

   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: registry.access.redhat.com/rhel:latest
              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 の保持のデフォルト値は 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. ベアメタルホスト CR に cluster.k8s.io/delete-machine: true のアノテーションを付けます。
2. 関連するマシンセットをスケールダウンします。

検証

1. AMQ Interconnect Operator が利用可能で、必要な Pod が実行されていることを確認します。

   $ oc get pods -n amq-interconnect

   出力例

   NAME                                    READY   STATUS    RESTARTS   AGE
   amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
   interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

2. 必要な bare-metal-event-relay ベアメタルイベントプロデューサー Pod が openshift-bare-metal-events namespace で実行されていることを確認します。

   $ oc get pods -n openshift-bare-metal-events

   出力例

   NAME                                                            READY   STATUS    RESTARTS   AGE
   hw-event-proxy-operator-controller-manager-74d5649b7c-dzgtl     2/2     Running   0          25s

手順

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.11 \
   /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.11 \
   /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.11 \
   /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.11" \
   /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.11 \
   /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.11"
       }
   ]

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

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