Container Service for Kubernetes:コンテナ向け CPU QoS の有効化

操作手順

ConfigMap を使用して、クラスター全体で CPU QoS 機能を有効化し、LS Pod および BE Pod の CPU グループ ID 優先度を構成できます。グループ ID 機能は、各 CPU cgroup に識別子を割り当てます。カーネルがこれらの識別子を持つタスクをスケジュールする際には、指定された優先度に従って処理されます。

構成が完了すると、Pod の YAML ファイルに koordinator.sh/qosClass ラベルを追加することで、その Pod の CPU QoS クラスを宣言できます。koordinator.sh/qosClass ラベルを指定しない Pod については、ack-koordinator がネイティブの Kubernetes Pod QoS クラスに従います。BestEffort Pod は BE にマップされ、他の QoS クラスの Pod は LS にマップされます。

1. CPU QoS 機能を有効化するためのファイル configmap.yaml を、以下の内容で作成します。

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: ack-slo-config
     namespace: kube-system
   data:
     # コンテナ向け CPU QoS 機能を有効化します。
     resource-qos-config: |
       {
         "clusterStrategy": {
           "lsClass": {
             "cpuQOS": {
               "enable": true,
               "groupIdentity": 2
             }
           },
           "beClass": {
             "cpuQOS": {
               "enable": true,
               "groupIdentity": -1
             }
           }
         }
       }

   lsClass および beClass フィールドは、それぞれ LS および BE QoS クラスの Pod を構成します。cpuQOS フィールドは CPU QoS を構成します。以下の表に、主なパラメーターを示します。

   パラメーター	型	値	説明
   enable	ブール値	true false	true：クラスター全体で CPU QoS 機能を有効化します。 false：クラスター全体で CPU QoS 機能を無効化します。
   groupIdentity	整数	[-1, 2]	CPU グループ ID の優先度です。groupIdentity の値が大きいほど、コンテナのカーネルスケジューリング優先度が高くなります。詳細については、「グループ ID 機能」をご参照ください。 デフォルトでは、LS Pod は 2、BE Pod は -1 です。0 を指定すると、本機能が無効化されます。

2. ack-slo-config ConfigMap が kube-system 名前空間に存在するか確認します。

   • 存在する場合、以下の patch コマンドを実行して更新します。これにより、ConfigMap 内の他の構成が上書きされるのを防ぎます。

     kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)"

   • 存在しない場合、以下のコマンドを実行して ConfigMap を作成します。

     kubectl apply -f configmap.yaml

3. 以下の内容で ls-pod-demo.yaml というファイルを作成します。この構成では、Pod の QoS クラスを LS として指定します。その後、YAML ファイルをクラスターにデプロイします。

   説明

   Deployment などのワークロードに構成を適用する場合は、template.metadata フィールド内で適切なアノテーションを Pod に設定します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: ls-pod-demo
     labels:
       koordinator.sh/qosClass: 'LS' # Pod の QoS クラスを LS として指定します。
   spec:
     containers:
     - command:
       - httpd
       - -D
       - FOREGROUND
       image: registry.cn-zhangjiakou.aliyuncs.com/acs/apache-2-4-51-for-slo-test:v0.1
       imagePullPolicy: Always
       name: apache
       resources:
         limits:
           cpu: "4"
           memory: 10Gi
         requests:
           cpu: "4"
           memory: 10Gi
     restartPolicy: Never
     schedulerName: default-scheduler

   kubectl apply -f ls-pod-demo.yaml

4. ノード上で以下のコマンドを実行し、cgroup 階層内の LS Pod のカーネルグループ ID を確認します。

   cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-pod1c20f2ad****.slice/cpu.bvt_warp_ns

   期待される出力：

   # LS Pod のグループ ID は 2 であり、高優先度であることを示します。
   2

5. 以下の内容で be-pod-demo.yaml というファイルを作成します。この構成では、Pod の QoS クラスを BE として指定します。その後、YAML ファイルをクラスターにデプロイします。

   apiVersion: v1
   kind: Pod
   metadata:
     name: be-pod-demo
     labels:
       koordinator.sh/qosClass: 'BE' # Pod の QoS クラスを BE として指定します。
   spec:
     containers:
       - args:
           - '-c'
           - '1'
           - '--vm'
           - '1'
         command:
           - stress
         image: registry-cn-beijing.ack.aliyuncs.com/acs/stress:v1.0.4
         imagePullPolicy: Always
         name: stress
     restartPolicy: Always
     schedulerName: default-scheduler

   kubectl apply -f be-pod-demo.yaml

6. ノード上で以下のコマンドを実行し、cgroup 階層内の BE Pod のカーネルグループ ID を確認します。

   cat /sys/fs/cgroup/cpu/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod4b6e96c8****.slice/cpu.bvt_warp_ns

   期待される出力：

   # BE Pod のグループ ID は -1 であり、低優先度であることを示します。
   -1

   出力結果から、LS Pod のグループ ID 優先度が BE Pod よりも高いことが確認できます。これは、CPU QoS が LS Pod に対する CPU リソースの優先配分を正しく実施していることを示しています。

よくある質問

ack-koordinator へのアップグレード時のプロトコル互換性

旧バージョンのプロトコル（ack-slo-manager v0.8.0 以前）では、Pod に alibabacloud.com/qosClass アノテーションを追加することで CPU QoS を有効化していました。

ack-koordinator は、この旧プロトコルとの互換性を維持しています。コンポーネントを ack-koordinator へシームレスにアップグレードしたうえで、段階的に Pod を koordinator.sh プロトコルへ移行できます。ack-koordinator は 2023 年 7 月 30 日まで旧プロトコルをサポートします。リソースフィールドを速やかに新しいプロトコルバージョンへ更新してください。