すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Mar 07, 2026

    Kubernetes 1.27 以前では、実行中の Pod のコンテナパラメーターを一時的に変更するには、PodSpec を更新して再提出するしかなく、これにより Pod が削除され、再作成されていました。Container Service for Kubernetes (ACK) は、Cgroups ファイルを使用して Pod リソースパラメーターを動的に変更できる機能を提供します。この機能により、Pod を再起動することなく、単一のマシン上で Pod の CPU、メモリ、ディスク I/O 隔離パラメーターを一時的に変更できます。

    この機能は一時的な調整のみを目的としています。例えば、Pod のメモリ使用量が徐々に増加する場合、Pod を再起動することなくメモリ制限を増やすことで、OOM killer のトリガーを回避できます。正式なルーチン運用保守作業には、以下の機能を使用することを推奨します。詳細については、「CPU バースト性能最適化ポリシーの有効化」、「CPU トポロジーアウェアスケジューリングの有効化」、および「リソースプロファイリング」をご参照ください。

    前提条件

    メモリ制限の変更

    Pod のメモリ使用量が増加した場合、Cgroups ファイルを使用してコンテナのメモリ制限を一時的かつ動的に変更することで、OOM killer がトリガーされるのを防ぐことができます。この例では、初期メモリ制限が 1 GB のコンテナを作成します。その後、Pod を再起動せずに Cgroups を使用してコンテナのメモリ制限を正常に変更できることを確認します。

    バージョン 1.22 以降のクラスターでこの機能を使用する場合は、ack-koordinator コンポーネントのバージョンが v1.5.0-ack1.14 以降であることを確認してください。その他のコンポーネントバージョンは、バージョン 1.22 以前のクラスターのみをサポートしています。

    説明

    CPU 制限の定期的な調整には、CPU バーストポリシーを使用して Pod の CPU リソース弾力性を自動的に調整できます。詳細については、「CPU バーストポリシーの有効化」をご参照ください。一時的に CPU 制限を調整する必要がある場合は、詳細については、「resource-controller から ack-koordinator への移行」の手順をご参照ください。

    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 GB です。
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "256M", "-c", "2", "--vm-hang", "1"]

    2. 次のコマンドを実行して、pod-demo をクラスターにデプロイします。

      kubectl apply -f pod-demo.yaml

    3. 次のコマンドを実行して、コンテナの初期メモリ制限を表示します。

      # 特定のパスは 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

      期待される出力:

      # これは 1 GB に相当します (1 × 1024 × 1024 × 1024 = 1073741824)。
1073741824

      出力は、コンテナの初期メモリ制限が 1 GB であることを示しています。これは、ステップ 1 の 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  # Pod のメモリ制限を 5 GB に指定します。

    5. 次のコマンドを実行して、cgroups-sample.yaml をクラスターにデプロイします。

      kubectl apply -f cgroups-sample.yaml

    6. 次のコマンドを実行して、コンテナの更新されたメモリ制限を表示します。

      # 特定のパスは Pod UID から構築できます。
cat /sys/fs/cgroup/memory/kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podaf44b779_41d8_43d5_a0d8_8a7a0b17****.slice/memory.limit_in_bytes

      期待される出力:

      # これは 5 GB に相当します (5 × 1024 × 1024 × 1024 = 5368709120)。
5368709120

      期待される出力は、コンテナのメモリ制限が 5 GB であることを示しており、これはステップ 4 の spec.pod.containers.memory 設定と一致します。これにより、変更が成功したことが確認されます。

    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

      出力は、Events リストに Pod の再起動に関する情報がなく、Pod が正常に実行されていることを示しています。

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

    アプリケーションが CPU 集中型で、より良いリソース隔離を必要とする場合、CPU コアバインディングスコープを変更して、Pod が使用できる CPU コアを指定できます。

    この例では、特定の CPU コアにバインドされていない Pod を作成します。その後、Pod を再起動せずに Cgroups ファイルを使用して Pod の CPU コアバインディングスコープを正常に変更できることを確認します。

    説明

    定期的な CPU コアバインディングには、CPU トポロジーアウェアスケジューリング機能を使用して、CPU に敏感なワークロードのパフォーマンスを向上させることを推奨します。詳細については、「CPU トポロジーアウェアスケジューリングの有効化」をご参照ください。

    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. 次のコマンドを実行して、pod-cpuset-demo.yaml をクラスターにデプロイします。

      kubectl apply -f pod-cpuset-demo.yaml

    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

      出力は、CPU バインディング前は利用可能な CPU コア範囲が 0 から 31 であり、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. 次のコマンドを実行して、cgroups-sample-cpusetpod.yaml をクラスターにデプロイします。

      kubectl apply -f cgroups-sample-cpusetpod.yaml

    6. 次のコマンドを実行して、コンテナの更新された 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

      期待される出力:

      2-3

      期待される出力は、コンテナーが CPU 2 および CPU 3 に正常にアタッチされたことを示しています。これは、ステップ 4 の spec.pod.containers.cpuset-cpus 設定と一致しており、変更が正常に適用されたことを確認します。

    7. 次のコマンドを実行して、Pod のステータスを確認します。

      kubectl describe pod pod-cpuset-demo

      期待される出力:

      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

      出力は、Events リストに Pod の再起動に関する情報がなく、Pod が正常に実行されていることを示しています。

    ディスク IOPS パラメーターの変更

    ディスク IOPS を制御するには、Alibaba Cloud Linux オペレーティングシステムを実行するワーカーノードを使用する必要があります。

    この例では、I/O 集中型テストアプリケーションを作成します。その後、Pod のスループットを制限し、Pod を再起動せずに Cgroups ファイルを使用してコンテナのディスク I/O 制限を変更できることを確認します。

    説明

    cgroup v1 環境で blkio 制限を使用する場合、オペレーティングシステムカーネルはコンテナのダイレクト I/O のみを制限します。バッファード I/O は制限できません。バッファード I/O を制限するには、Alibaba Cloud Linux で cgroup v1 の cgroup ライトバック機能を有効にする必要があります。詳細については、「cgroup ライトバック機能の有効化」をご参照ください。この機能は cgroup v2 環境ではサポートされていません。

    1. 以下の YAML 内容を使用して、I/O 集中型テストアプリケーションを作成します。

      ホストディレクトリ /mnt は Pod 内で使用するためにマウントされ、ディスクデバイス名 /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 ツールを使用してディスク IOPS の書き込みテストを実行します。
        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    # /data パスにマウントします。
      volumes:
        - name: pvc
          hostPath:
            path: /mnt

    2. 次のコマンドを実行して、fio-demo をクラスターにデプロイします。

      kubectl apply -f fio-demo.yaml

    3. ディスク IOPS を制御する Cgroups ファイルをデプロイして、Pod のスループットを制限します。

      1. /dev/vda1 デバイスの 1 秒あたりのバイト数 (BPS) 制限を指定するために、以下の YAML 内容で cgroups-sample-fio.yaml という名前のファイルを作成します。

        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、2097152、3145728)。
        device_write_bps: [{device: "/dev/vda1", value: "1048576"}]

      2. 次のコマンドを実行して、コンテナの更新されたディスク 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

        出力は、現在のディスク速度制限が 1048576 に設定されていることを示しています。

    4. 対応するノードのディスクモニタリングデータを表示します。

      84

      85

      上記の図に示すように、コンテナのスループット BPS (ファイルシステム書き込み) は、ステップ 3 で設定された device_write_bps 制限と一致します。変更中に Pod は再起動されませんでした。

      説明

      Alibaba Cloud Prometheus ダッシュボードも有効化できます。詳細については、「Alibaba Cloud Prometheus モニタリングへの接続と設定」をご参照ください。その後、Prometheus モニタリングページで、操作 > Prometheus 監視 を選択します。アプリケーションのモニタリング タブで、サンプルアプリケーションをフィルターして、そのディスクデータを表示できます。

    デプロイメントレベルでの Pod リソースパラメーターの動的変更

    前述のセクションで説明した Pod レベルでのリソースパラメーターの動的変更は、デプロイメントレベルでも機能します。Pod レベルでの変更は Cgroups ファイルの spec.pod フィールドを通じて有効になり、デプロイメントレベルでの変更は spec.deployment フィールドを通じて有効になります。次の例は、デプロイメントの CPU コアバインディングスコープを変更する方法を示しています。他のシナリオでの操作も同様です。

    1. 以下の内容で go-demo.yaml という名前のファイルを作成します。

      デプロイメントには、ストレステストプログラムの 2 つのインスタンスが含まれています。各インスタンスは 0.5 CPU コアを使用します。

      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. 次のコマンドを実行して、go-demo をクラスターにデプロイします。

      kubectl apply -f go-demo.yaml

    3. CPU バインディング情報を指定するために、以下の内容で cgroups-cpuset-sample.yaml という名前のファイルを作成します。

      apiVersion: resources.alibabacloud.com/v1alpha1
kind: Cgroups
metadata:
  name: cgroups-cpuset-sample
spec:
  deployment: # これは Deployment 用です。
    name: go-demo
    namespace: default
    containers:
    - name: go-demo
      cpuset-cpus: 2,3 # Pod を CPU コア 2 および 3 にバインドします。

    4. 次のコマンドを実行して、cgroups-cpuset-sample をクラスターにデプロイします。

      kubectl apply -f cgroups-cpuset-sample.yaml

    5. 次のコマンドを実行して、コンテナの更新された 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

      出力は、コンテナが CPU コア 2 および 3 にバインドされていることを示しています。これは、Cgroups ファイルの spec.deployment.containers.cpuset-cpus 設定と一致します。