6.4. ノードホストに関する推奨プラクティス

前提条件

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. 次のコマンドを実行してノードにラベルを付けます。

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

2. すべてのコンピュートノードに対して CPU マネージャーを有効にするには、次のコマンドを実行して CR を編集します。

   # oc edit machineconfigpool worker

3. custom-kubelet: cpumanager-enabled ラベルを metadata.labels セクションに追加します。

   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. 次のコマンドを実行してプロジェクトを作成します。

   $ oc new-project <project_name>

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

   # cat cpumanager-pod.yaml

   出力例

   apiVersion: v1
   kind: Pod
   metadata:
     generateName: cpumanager-
   spec:
     securityContext:
       runAsNonRoot: true
       seccompProfile:
         type: RuntimeDefault
     containers:
     - name: cpumanager
       image: gcr.io/google_containers/pause:3.2
       resources:
         requests:
           cpu: 1
           memory: "1G"
         limits:
           cpu: 1
           memory: "1G"
       securityContext:
         allowPrivilegeEscalation: false
         capabilities:
           drop: [ALL]
     nodeSelector:
       cpumanager: "true"

10. Pod を作成します。

    # oc create -f cpumanager-pod.yaml

検証

1. 次のコマンドを実行して、ラベルを付けたノードに 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

2. 次のコマンドを実行して、CPU が Pod 専用として割り当てられていることを確認します。

   # oc describe node --selector='cpumanager=true' | grep -i cpumanager- -B2

   出力例

   NAMESPACE    NAME                CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
   cpuman       cpumanager-mlrrz    1 (28%)       1 (28%)     1G (13%)         1G (13%)       27m

3. cgroups が正しく設定されていることを確認します。次のコマンドを実行して、pause プロセスのプロセス ID (PID) を取得します。

   # oc debug node/perf-node.example.com

   sh-4.2# systemctl status | grep -B5 pause

   注記

   出力で複数の pause プロセスエントリーが返される場合は、正しい一時停止プロセスを特定する必要があります。

   出力例

   # ├─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

4. 次のコマンドを実行して、サービス品質 (QoS) 層 (Guaranteed) の Pod が kubepods.slice サブディレクトリー内に配置されていることを確認します。

   # cd /sys/fs/cgroup/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope

   # for i in `ls cpuset.cpus cgroup.procs` ; do echo -n "$i "; cat $i ; done

   注記

   他の QoS 階層の Pod は、親 kubepods の子である cgroups に配置されます。

   出力例

   cpuset.cpus 1
   tasks 32706

5. 次のコマンドを実行して、タスクに許可されている CPU リストを確認します。

   # grep ^Cpus_allowed_list /proc/32706/status

   出力例

    Cpus_allowed_list:    1

6. システム上の別の Pod が、Guaranteed Pod に割り当てられたコアで実行できないことを確認します。たとえば、besteffort QoS 階層の Pod を検証するには、次のコマンドを実行します。

   # cat /sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus

   # 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