Container Service for Kubernetes:Pod リソースパラメーターの動的な変更

仕組み

ACK は、kind: Cgroups のカスタムリソース定義 (CRD) を使用して、リソースの変更を ack-koordinator に渡します。 Cgroups リソースを適用すると、ノード上の koordlet は、Kubernetes スケジューラと kubelet 調整ループを経由せずに、新しい値を cgroup ファイルに直接書き込みます。 ポッドの PodSpec は変更されず、ノード上の cgroup 値のみが更新されます。

特定のポッドをターゲットにするには spec.pod を、Deployment 内のすべてのポッドをターゲットにするには spec.deployment を使用します。

前提条件

次のことを確認してください。

• kubectl がACK クラスターに接続されていること。

• ack-koordinator 0.5.0 以降がインストールされていること。

課金

ack-koordinator のインストールと使用は無料です。次のような状況では、追加料金が発生する場合があります。

• ワーカーノードのリソース：ack-koordinator は非マネージドのアドオンであり、インストール後にワーカーノードのリソースを消費します。アドオンをインストールする際に、各モジュールのリソースリクエストを指定します。

• Prometheus のモニタリングメトリクス：[ACK-Koordinator の Prometheus モニタリングメトリクスを有効化] オプションを有効にし、Managed Service for Prometheus を使用する場合、メトリクスはカスタムメトリクスとして課金されます。料金は、クラスターのサイズとアプリケーションの数によって異なります。この機能を有効にする前に、Prometheus インスタンスの課金に関するドキュメントを確認し、使用量のクエリを使用して消費量を監視してください。

制限事項

メモリリミットの変更

Pod を再起動せずにメモリリミットを引き上げて、OOM (Out of Memory) による強制終了を防ぎます。この例では、リミットを 1 GiB から 5 GiB に引き上げます。

1. 以下の内容で pod-demo.yaml を作成します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-demo
   spec:
     containers:
     - name: pod-demo
       image: registry-cn-beijing.ack.aliyuncs.com/acs/stress:v1.0.4
       resources:
         requests:
           cpu: 1
           memory: "50Mi"
         limits:
           cpu: 1
           memory: "1Gi" # 初期メモリリミット：1 GiB
       command: ["stress"]
       args: ["--vm", "1", "--vm-bytes", "256M", "-c", "2", "--vm-hang", "1"]

2. 2. Pod をデプロイします。

   kubectl apply -f pod-demo.yaml

3. 3. 初期のメモリリミットを確認します。cgroup パスは、Pod UID とコンテナ ID から構成されます。

   cat /sys/fs/cgroup/memory/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podaf44b779_41d8_43d5_a0d8_8a7a0b17****.slice/memory.limit_in_bytes

   期待される出力：

   1073741824

   1073741824 は 1 GiB で、Pod 定義内の spec.containers.resources.limits.memory と一致します。

4. 新しいメモリ制限を設定するために、cgroups-sample.yamlを作成します。

   apiVersion: resources.alibabacloud.com/v1alpha1
   kind: Cgroups
   metadata:
     name: cgroups-sample
   spec:
     pod:
       name: pod-demo
       namespace: default
       containers:
       - name: pod-demo
         memory: 5Gi  # 新しいメモリリミット：5 GiB

5. 5. Cgroups リソースを適用します。

   kubectl apply -f cgroups-sample.yaml

6. 6. 更新されたメモリリミットを確認します。

   cat /sys/fs/cgroup/memory/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podaf44b779_41d8_43d5_a0d8_8a7a0b17****.slice/memory.limit_in_bytes

   期待される出力：

   5368709120

   5368709120 = 5 GiB であり、Cgroups リソースの spec.pod.containers.memory と一致します。

7. 7. Pod が再起動されていないことを確認します。

   kubectl describe pod pod-demo

   イベントセクションに再起動イベントがなく、元のスケジューリングイベントと起動イベントのみが存在することを確認します：

   Events:
     Type    Reason          Age   From               Message
     ----    ------          ----  ----               -------
     Normal  Scheduled       36m   default-scheduler  Successfully assigned default/pod-demo to cn-hangzhou.192.168.0.50
     Normal  AllocIPSucceed  36m   terway-daemon      Alloc IP 192.XX.XX.51/24 took 4.490542543s
     Normal  Pulling         36m   kubelet            Pulling image "registry-cn-beijing.ack.aliyuncs.com/acs/stress:v1.0.4"
     Normal  Pulled          36m   kubelet            Successfully pulled image "registry-cn-beijing.ack.aliyuncs.com/acs/stress:v1.0.4" in 2.204s (2.204s including waiting). Image size: 7755078 bytes.
     Normal  Created         36m   kubelet            Created container pod-demo
     Normal  Started         36m   kubelet            Started container pod-demo

   再起動イベントがないことから、メモリリミットがインプレースで更新されたことが確認できます。

CPU コアバインディングスコープの変更

Pod を特定の CPU コアにバインドして、より厳密なリソース分離を実現します。この例では、Pod を全 32 コア (0–31) からコア 2–3 に制限します。

1. 以下の内容で pod-cpuset-demo.yamlを作成します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: pod-cpuset-demo
   spec:
     containers:
     - name: pod-cpuset-demo
       image: registry-cn-beijing.ack.aliyuncs.com/acs/stress:v1.0.4
       resources:
         requests:
           memory: "50Mi"
         limits:
           memory: "1000Mi"
           cpu: 0.5
       command: ["stress"]
       args: ["--vm", "1", "--vm-bytes", "556M", "-c", "2", "--vm-hang", "1"]

2. 2. Pod をデプロイします。

   kubectl apply -f pod-cpuset-demo.yaml

3. 3. 現在の CPU コアバインディングを確認します。パスは、Pod UID とコンテナ ID から構成されます。

   cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podf9b79bee_eb2a_4b67_befe_51c270f8****.slice/cri-containerd-aba883f8b3ae696e99c3a920a578e3649fa957c51522f3fb00ca943dc2c7****.scope/cpuset.cpus

   期待される出力：

   0-31

   0-31 は、コンテナが 32 個すべての CPU コアを使用できることを意味します。

4. CPU バインディングを設定するために、cgroups-sample-cpusetpod.yaml を作成します。

   apiVersion: resources.alibabacloud.com/v1alpha1
   kind: Cgroups
   metadata:
     name: cgroups-sample-cpusetpod
   spec:
     pod:
       name: pod-cpuset-demo
       namespace: default
       containers:
       - name: pod-cpuset-demo
         cpuset-cpus: 2-3  # Pod を CPU コア 2 と 3 に制限

5. 5. Cgroups リソースを適用します。

   kubectl apply -f cgroups-sample-cpusetpod.yaml

6. 6. 更新された CPU バインディングを確認します。

   cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podf9b79bee_eb2a_4b67_befe_51c270f8****.slice/cri-containerd-aba883f8b3ae696e99c3a920a578e3649fa957c51522f3fb00ca943dc2c7****.scope/cpuset.cpus

   期待される出力：

   2-3

   コンテナは コア 2–3 にバインドされ、これは Cgroups リソースの spec.pod.containers.cpuset-cpus と一致します。

7. 7. Pod が再起動されていないことを確認します。

   kubectl describe pod pod-cpuset-demo

   Events セクションには、koordlet からの CPUSetBind イベントは含まれていますが、再起動イベントはありません:

   Events:
     Type    Reason          Age   From               Message
     ----    ------          ----  ----               -------
     Normal  Scheduled       7m7s  default-scheduler  Successfully assigned default/pod-cpuset-demo to cn-hangzhou.192.XX.XX.50
     Normal  AllocIPSucceed  7m5s  terway-daemon      Alloc IP 192.XX.XX.56/24 took 2.060752512s
     Normal  Pulled          7m5s  kubelet            Container image "registry-cn-beijing.ack.aliyuncs.com/acs/stress:v1.0.4" already present on machine
     Normal  Created         7m5s  kubelet            Created container pod-cpuset-demo
     Normal  Started         7m5s  kubelet            Started container pod-cpuset-demo
     Normal  CPUSetBind      84s   koordlet           set cpuset 2-3 to container pod-cpuset-demo success

ディスク I/O パラメーターの変更

この例では、fio ワークロードをデプロイし、cgroup ファイルを使用してその書き込みスループットを制限します。

1. 以下の内容で fio-demo.yaml を作成します。 ホストディレクトリ /mnt はポッド内の /data にマウントされ、/dev/vda1 にマッピングされます。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: fio-demo
     labels:
       app: fio-demo
   spec:
     selector:
       matchLabels:
         app: fio-demo
     template:
       metadata:
         labels:
           app: fio-demo
       spec:
         containers:
         - name: fio-demo
           image: registry.cn-zhangjiakou.aliyuncs.com/acs/fio-for-slo-test:v0.1
           command: ["sh", "-c"]
           # fio を使用してディスク I/O のシーケンシャル書き込みテストを実行
           args: ["fio -filename=/data/test -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=12000 -group_reporting -name=mytest"]
           volumeMounts:
             - name: pvc
               mountPath: /data
         volumes:
           - name: pvc
             hostPath:
               path: /mnt

2. 2. アプリケーションをデプロイします。

   kubectl apply -f fio-demo.yaml

3. 3. cgroup ファイルを使用して書き込みスループットを制限します。

   1. cgroups-sample-fio.yaml を作成し、/dev/vda1 にバイト/秒 (BPS) の書き込み制限を設定します。

      apiVersion: resources.alibabacloud.com/v1alpha1
      kind: Cgroups
      metadata:
        name: cgroups-sample-fio
      spec:
        deployment:
          name: fio-demo
          namespace: default
          containers:
          - name: fio-demo
            blkio:
              # BPS リミット (バイト/秒) (例：1048576 = 1 MiB/s)
              device_write_bps: [{device: "/dev/vda1", value: "1048576"}]

   2. b. Cgroups リソースを適用します。

      kubectl apply -f cgroups-sample-fio.yaml

   3. c. 更新されたディスク I/O リミットを確認します。パスは、Pod UID とコンテナ ID から構成されます。

      cat /sys/fs/cgroup/blkio/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-pod0840adda_bc26_4870_adba_f193cd00****.slice/cri-containerd-9ea6cc97a6de902d941199db2fcda872ddd543485f5f987498e40cd706dc****.scope/blkio.throttle.write_bps_device

      期待される出力：

      253:0 1048576

      デバイス 253:0 (/dev/vda1) の書き込み BPS 制限は 1048576 (1 MiB/s) です。ポッドは再起動されませんでした。

4. 4. Prometheus でディスクのモニタリングデータを表示するには、コンソールに移動し、[オペレーション] > [Prometheus モニタリング] を選択します。[アプリケーションモニタリング] タブで、サンプルアプリケーションをフィルターします。詳細については、「Alibaba Cloud Prometheus Monitoring への接続と設定」をご参照ください。

Deployment レベルでの変更の適用

上記の手順はすべて Deployment レベルでも機能し、spec.pod の代わりに spec.deployment を使用します。この例では、Deployment に CPU コアバインディングを適用します。

1. 以下の内容で go-demo.yaml を作成します。このデプロイメントは、それぞれ 0.5 CPU で 2 つのレプリカを実行します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: go-demo
     labels:
       app: go-demo
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: go-demo
     template:
       metadata:
         labels:
           app: go-demo
       spec:
         containers:
         - name: go-demo
           image: registry-cn-beijing.ack.aliyuncs.com/acs/stress:v1.0.4
           command: ["stress"]
           args: ["--vm", "1", "--vm-bytes", "556M", "-c", "1", "--vm-hang", "1"]
           imagePullPolicy: Always
           resources:
             requests:
               cpu: 0.5
             limits:
               cpu: 0.5

2. 2. アプリケーションをデプロイします。

   kubectl apply -f go-demo.yaml

3. Deployment のポッドを特定の CPU コアにバインドするために、cgroups-cpuset-sample.yaml を作成します。

   apiVersion: resources.alibabacloud.com/v1alpha1
   kind: Cgroups
   metadata:
     name: cgroups-cpuset-sample
   spec:
     deployment: # 単一の Pod ではなく、Deployment をターゲットにします
       name: go-demo
       namespace: default
       containers:
       - name: go-demo
         cpuset-cpus: 2-3 # CPU コア 2 と 3 にバインド

4. 4. Cgroups リソースを適用します。

   kubectl apply -f cgroups-cpuset-sample.yaml

5. 5. Pod の 1 つの CPU バインディングを確認します。パスは、Pod UID とコンテナ ID から構成されます。

   cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pod06de7408_346a_4d00_ba25_02833b6c****.slice/cri-containerd-733a0dc93480eb47ac6c5abfade5c22ed41639958e3d304ca1f85959edc3****.scope/cpuset.cpus

   期待される出力：

   2-3

   コンテナはコア 2–3にバインドされ、Cgroups リソースの spec.deployment.containers.cpuset-cpus と一致します。

次のステップ

• CPU バースト：コンテナは未使用の CPU タイムスライスを蓄積し、トラフィックの急増時にそれらを消費することで、レイテンシーを削減し、サービス品質 (QoS) を向上させます。詳細については、「CPU バーストポリシーの有効化」をご参照ください。

• CPU トポロジー認識スケジューリング：スケジューリング時に Pod を特定の CPU コアに固定することで、CPU のコンテキストスイッチのオーバーヘッドと NUMA をまたいだメモリアクセスを排除します。詳細については、「CPU トポロジー認識スケジューリングの有効化」をご参照ください。

• 動的リソースオーバーコミット：割り当てられたが未使用のリソースを回収し、優先度の低いワークロードで利用できるようにします。単一ノードの QoS ポリシーと組み合わせることで、アプリケーション間のパフォーマンス干渉を回避します。詳細については、「動的リソースオーバーコミットの有効化」をご参照ください。

• リソースプロファイリング：過去の使用状況データを分析して、コンテナのリクエストとリミットに関する適正サイジングの推奨事項を取得します。詳細については、「リソースプロファイリング」をご参照ください。