すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:CPUバーストの有効化

最終更新日:Dec 13, 2024

コンテナのCPU使用率は、コンテナのCPU制限を超えることはできません。 CPU使用率が制限に達すると、コンテナのCPUスケジューリングがカーネルによって抑制され、アプリケーションのサービス品質が低下します。 CPUバースト機能は、CPUスロットリングイベントを自動的に検出し、CPU制限を適切な値に自動的に調整します。 この機能を有効にすると、CPU需要が急増すると、コンテナのCPU使用率がCPU制限を超えてバーストする可能性があります。 これにより、CPUのボトルネックがなくなり、レイテンシに敏感なアプリケーションのサービス品質が向上します。

説明

CPUバースト機能を使用する前に、CFSスケジューラおよび [ノードのCPU管理ポリシーの制御] で関連する用語について学習することをお勧めします。

CPUバーストが開発される理由

Kubernetesクラスターでは、コンテナーのCPU制限により、コンテナーが使用できるCPUリソースの最大量が指定されます。 これにより、コンテナ間のCPU割り当てが公平になり、個々のコンテナによってCPUリソースが使い果たされた場合のパフォーマンス低下を防ぎます。

CPUリソースはタイムシェアリングです。 複数のプロセスまたはコンテナが1つのCPUタイムスライスを共有できます。 コンテナのCPU制限を指定すると、OSカーネルは完全公平スケジューラ (CFS) を使用して、コンテナが各期間内に使用できるCPUリソースの最大量 (cpu.cfs_quota_us) cpu.cfs_period_usを設定します。 たとえば、コンテナーのCPU制限を4に設定します。 OSカーネルは、コンテナが使用できるCPUタイムスライスを、各期間 (通常は各100ミリ秒) 内で400ミリ秒に制限します。

メリット

CPU使用率は、コンテナのパフォーマンスを評価するために使用される重要な指標です。 ほとんどの場合、CPU制限はCPU使用率に基づいて指定されます。 ミリ秒単位のCPU使用率は、秒単位よりも多くのスパイクを示します。 コンテナーのCPU使用率を次の図に示します。 1秒あたりのCPU使用率 (紫色の曲線) は4 vCores未満です。 ただし、ミリ秒単位のCPU使用率 (緑色の曲線) は、ある期間内に4 vCoresを超えます。 この場合、CPU制限を4 vCoresに設定すると、CPUスロットリングはOSカーネルによって強制され、コンテナー内のスレッドは中断されます。

原理说明

次の図は、コンテナーがリクエストを受信した後、webアプリケーションコンテナーのスレッドにCPUリソースがどのように割り当てられるかを示しています。 コンテナーは4つのvCoreを持つノードで実行され、コンテナーのCPU制限は2に設定されています。 左側の図は、CPUバーストが無効の場合のCPU割り当ての詳細を示しています。 右の図は、CPUバーストが有効な場合のCPU割り当ての詳細を示しています。

最後の1秒以内の全体的なCPU使用率は低い。 ただし、スレッド2は、3番目の100ミリ秒の期間が開始されるまで、リクエスト2の処理を再開できません。これは、2番目の100ミリ秒の期間にCPUスロットリングが適用されるためです。 これは、応答時間 (RT) を増加させる。 これはまた、コンテナにおけるロングテール待ち時間の問題を引き起こす。ack-slo-manager example.png

CPUバーストを有効にすると、コンテナがアイドル状態になったときに、コンテナはCPUタイムスライスを蓄積できます。 コンテナは、CPU要求が急上昇したときにCPU制限を超えてバーストするために累積CPUタイムスライスを使用することができる。 これは、性能を改善し、容器のRTを低減する。CPU Burst.png

上記のシナリオに加えて、CPUバーストはCPU使用率の急上昇の処理にも適しています。 たとえば、トラフィックのスパイクが発生した場合、ack-koordinatorはCPUのボトルネックを数秒以内に解消し、ノードで適切な数のワークロードを確保できます。

説明

ack-koordinatorは、ポッド仕様のCPU制限の値を変更する代わりに、cgroupパラメーターのCFSクォータの値を変更することでこれを実現します。

シナリオ

CPUバーストは、次のシナリオに適しています。

  • CPUスロットリングは、アプリケーションのCPU使用率がアプリケーションのCPU制限よりも低い場合があります。 その結果、アプリケーションの性能が低下する。 CPUバーストにより、コンテナは、アイドル時に蓄積するCPUタイムスライスを使用できます。 CPUバーストを有効にして、CPUスロットリングを解決し、アプリケーションのパフォーマンスを向上させることができます。

  • 起動プロセス中のアプリケーションのCPU使用率は、アプリケーションの起動後のCPU使用率よりも高くなります。 起動プロセス中にCPU要件を満たすようにCPUバーストを有効にできます。 この方法では、アプリケーションに対して過度に高いCPU制限を指定する必要はありません。

課金

ack-koordinatorコンポーネントをインストールまたは使用する場合、料金はかかりません。 ただし、次のシナリオでは料金が請求される場合があります。

  • ack-koordinatorは、インストール後にワーカーノードリソースを占有する管理対象外のコンポーネントです。 コンポーネントのインストール時に、各モジュールが要求するリソースの量を指定できます。

  • 既定では、ack-koordinatorは、リソースプロファイリングや細粒度スケジューリングなどの機能のモニタリングメトリックをPrometheusメトリックとして公開します。 ack-koordinatorのPrometheusメトリクスを有効にし、PrometheusのManaged Serviceを使用する場合、これらのメトリクスはカスタムメトリクスと見なされ、料金が課金されます。 料金は、クラスターのサイズやアプリケーションの数などの要因によって異なります。 Prometheusメトリクスを有効にする前に、Prometheusのマネージドサービスの課金トピックを読んで、カスタムメトリクスの無料クォータと課金ルールについて確認することをお勧めします。 リソース使用量を監視および管理する方法の詳細については、「観察可能なデータ量と請求書の照会」をご参照ください。

前提条件

使用上の注意

注釈を使用して、ポッドのCPUバーストを有効にできます。 ConfigMapを使用して、名前空間またはクラスター内のポッドのCPUバーストを有効にすることもできます。

注釈を使用してポッドのCPUバーストを有効にする

ポッドのCPUバーストを有効にするには、ポッドのYAMLファイルのmetadataセクションにアノテーションを追加します。

説明

デプロイなどのワークロードに構成を適用するには、template.metadataフィールドでポッドに適切なアノテーションを設定します。

annotations:
  # Set the value to auto to enable CPU Burst for a pod. 
  koordinator.sh/cpuBurst: '{"policy": "auto"}'
  # Set the value to none to disable CPU Burst for a pod. 
  koordinator.sh/cpuBurst: '{"policy": "none"}'

ConfigMapを使用してクラスター内のポッドのCPUバーストを有効にする

既定では、ConfigMapを使用して構成されたCPUバースト機能は、クラスター全体で有効になります。

  1. configmap.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。

    apiVersion: v1
    data:
      cpu-burst-config: '{"clusterStrategy": {"policy": "auto"}}'
      #cpu-burst-config: '{"clusterStrategy": {"policy": "cpuBurstOnly"}}'
      #cpu-burst-config: '{"clusterStrategy": {"policy": "none"}}'
    kind: ConfigMap
    metadata:
      name: ack-slo-config
      namespace: kube-system
  2. ack-slo-config ConfigMapがkube-system名前空間に存在するかどうかを確認します。

    • ack-slo-config ConfigMapが存在する場合は、kubectl patchコマンドを実行してConfigMapを更新することを推奨します。 これにより、ConfigMapの他の設定の変更が回避されます。

      kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)
    • ack-slo-config ConfigMapが存在しない場合は、次のコマンドを実行してack-slo-configという名前のConfigMapを作成します。

      kubectl apply -f configmap.yaml

ConfigMapを使用して名前空間のポッドのCPUバーストを有効にする

ConfigMapで名前空間を指定して、名前空間のポッドのCPUバースト機能を有効にすることができます。

  1. configmap.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: ack-slo-pod-config
      namespace: koordinator-system # If this is the first time you use CPU Burst, you must first create a namespace named koordinator-system. 
    data:
      # Enable or disable CPU Burst in the specified namespace. 
      cpu-burst: |
        {
          "enabledNamespaces": ["allowed-ns"], 
          "disabledNamespaces": ["blocked-ns"]
        }
      # This setting enables CPU Burst for pods in the allowed-ns namespace, which is equivalent to policy: auto. 
      # This setting disables CPU Burst for pods in the blocked-ns namespace, which is equivalent to policy: none.
  2. ack-slo-config ConfigMapがkube-system名前空間に存在するかどうかを確認します。

    • ack-slo-config ConfigMapが存在する場合は、kubectl patchコマンドを実行してConfigMapを更新することを推奨します。 これにより、ConfigMapの他の設定の変更が回避されます。

      kubectl patch cm -n kube-system ack-slo-config --patch "$(cat configmap.yaml)
    • ack-slo-config ConfigMapが存在しない場合は、次のコマンドを実行してack-slo-configという名前のConfigMapを作成します。

      kubectl apply -f configmap.yaml

手順

次の例では、webアプリケーションを使用して、CPUバーストがアクセス遅延を削減し、アプリケーションのパフォーマンスを向上させる方法を示します。

検証ステップ

  1. apache-demo.yamlという名前のファイルを作成し、次の内容をファイルにコピーします。

    ポッドのCPUバーストを有効にするには、ポッド構成のmetadataセクションに特定のアノテーションを追加します。

    apiVersion: v1
    kind: Pod
    metadata:
      name: apache-demo
      annotations:
        koordinator.sh/cpuBurst: '{"policy": "auto"}'   # Add this annotation to enable CPU Burst. 
    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
      nodeName: $nodeName # Replace the value with the actual node name. 
      hostNetwork: False
      restartPolicy: Never
      schedulerName: default-scheduler
  2. 次のコマンドを実行して、Apache HTTP Serverを使用してアプリケーションを作成します。

    kubectl apply -f apache-demo.yaml
  3. wrk2ツールを使用してストレステストを実行します。

    # Download, decompress, and then install the wrk2 package. For more information, visit https://github.com/giltene/wrk2. 
    # Gzip compression is enabled in the Apache image to simulate the request processing logic of the server. 
    # Run the following command to send requests. Replace the IP address in the command with the IP address of the application. 
    ./wrk -H "Accept-Encoding: deflate, gzip" -t 2 -c 12 -d 120 --latency --timeout 2s -R 24 http://$target_ip_address:8010/static/file.1m.test
    説明
    • コマンドのIPアドレスをApacheアプリケーションのポッドIPアドレスに置き換えます。

    • -Rパラメーターを変更して、送信者からの単位時間あたりのクエリ数を変更できます。

分析結果

次の表は、Alibaba Cloud LinuxおよびCentOSのCPUバーストを有効にする前後のメトリックを示しています。

  • 無効列は、CPUバーストポリシーがnoneに設定されている場合のメトリックを示します。

  • 有効列には、CPUバーストポリシーが自動に設定されている場合のメトリックが表示されます。

重要

以下のメトリックは理論値です。 実際の値は、オペレーティング環境によって異なります。

Alibaba Cloud Linux

無効

有効

apache RT-p99

107.37 ms

67.18 ms (-37.4%)

CPUスロットル比率

33.3%

0%

平均ポッドCPU使用率

31.8%

32.6%

CentOS

無効

有効

apache RT-p99

111.69 ms

71.30 ms (-36.2%)

CPUスロットル比率

33%

0%

平均ポッドCPU使用率

32.5%

33.8%

上記のメトリックは、次の情報を示しています。

  • CPUバーストを有効にすると、P99レイテンシが大幅に削減されます。

  • CPUバーストを有効にすると、CPUスロットリングイベントは大幅に削減され、ポッドの平均CPU使用率はほぼ同じ値のままになります。

詳細設定

詳細設定は、ConfigMapで指定するか、ポッド設定にアノテーションを追加して指定できます。 一部のパラメーターは、アノテーションを追加してConfigMapを変更することで設定できます。 この場合、アノテーションはConfigMapよりも優先されます。 このようなパラメーターを設定するためにアノテーションが追加されていない場合、ack-koordinatorは名前空間レベルのConfigMapで対応するパラメーターを使用します。 名前空間レベルのConfigMapでパラメーターが指定されていない場合、ack-koordinatorはクラスターレベルのConfigMapでパラメーターを使用します。

次のコードブロックは例です。

# Example of the ack-slo-config ConfigMap. 
data:
  cpu-burst-config: |
    {
      "clusterStrategy": {
        "policy": "auto",
        "cpuBurstPercent": 1000,
        "cfsQuotaBurstPercent": 300,
        "sharePoolThresholdPercent": 50,
        "cfsQuotaBurstPeriodSeconds": -1
      }
    }

# Example of pod annotations. 
  koordinator.sh/cpuBurst: '{"policy": "auto", "cpuBurstPercent": 1000, "cfsQuotaBurstPercent": 300, "cfsQuotaBurstPeriodSeconds": -1}'

次の表に、CPU Burstの高度なパラメーターを示します。

説明

[アノテーション] 列と [ConfigMap] 列は、アノテーションとConfigMapを使用してパラメーターを設定できるかどうかを示します。 对はサポートされ、错はサポートされていません。

パラメーター

タイプ

説明

注釈

設定マップ

policy

String

  • none: CPUバーストを無効にします。 値をnoneに設定すると、関連するパラメーターは元の値にリセットされます。 デフォルト値です。

  • cpuBurstOnly: Alibaba Cloud Linuxが提供するカーネルレベルのCPUバースト機能を有効にします。

  • cfsQuotaBurstOnly: CFSクォータの自動調整を有効にします。 すべてのカーネルバージョンがサポートされています。

  • auto: Alibaba Cloud LinuxのカーネルのCPUバーストとCFSクォータの自動調整を自動的に有効にします。

对

对

cpuBurstPercent

int

デフォルト値: 1000 単位: % 。

このパラメーターは、Alibaba Cloud Linuxが提供するカーネルレベルのCPUバースト機能を設定するために使用されます。 このパラメータは、CPUバーストによってCPU制限を増やすことができる割合を指定します。 このパラメーターは、cgroupのcpu.cfs_burst_usパラメーターに対応します。 詳細については、「cgroup v1のCPUバースト機能の有効化」をご参照ください。

たとえば、CPU制限が1に設定されている場合、cpu.cfs_quota_usの値は100,000になり、cpu.cfs_burst_usの値は10倍増加して1,000,000になります。

对

对

cfsQuotaBurstPercent

int

デフォルト値: 300 単位: % 。

このパラメーターは、CFSクォータの自動調整が有効になっている場合に、cpu.cfs_quota_us cgroupパラメーターの値を増やすことができる最大パーセンテージを指定します。 デフォルトでは、cpu.cfs_quota_usの値を3倍に増やすことができます。

对

对

cfsQuotaBurstPeriodSeconds

int

デフォルト値: -1 単位は秒です。 この値は、CFSクォータを増やしてコンテナを実行できる期間が無制限であることを示します。

このパラメーターは、cfsQuotaBurstPercentで指定された上限を超えることはできません、CFSクォータを増やしてコンテナを実行できる期間を指定します。 上限を超えると、cpu.cfs_quota_us cgroupパラメーターの増加した値は元の値にリセットされます。 他のポッドは影響を受けません。

对

对

sharePoolThresholdPercent

int

デフォルト値: 50 単位: % 。

このパラメーターは、CFSクォータの自動調整が有効になっている場合のノードのCPU使用率のしきい値を指定します。 ノードのCPU使用率がしきい値を超えると、各ポッドのcpu.cfs_quota_us cgroupパラメーターの増加値が元の値にリセットされます。

错

对

説明
  • policycfsQuotaBurstOnlyまたはautoに設定してCFSクォータの自動調整を有効にすると、ノードのポッドCPU制限パラメーターcpu.cfs_quota_usがCPUスロットリングのステータスに基づいて自動的に調整されます。

  • コンテナでストレステストを実行する場合は、テスト全体でコンテナのCPU使用率を記録するか、policycpuBurstOnlyまたはnoneに設定してCFSクォータの自動調整を無効にすることを推奨します。 これにより、本番環境でのリソースの弾力性が向上します。

よくある質問

以前のバージョンのack-slo-managerプロトコルに基づいて有効にしたCPUバースト機能は、ack-slo-managerをack-koordinatorにアップグレードしても機能しますか?

以前のポッドプロトコルバージョンでは、alibabacloud.com/cpuBurst注釈を追加する必要があります。 ack-koordinatorは、以前のプロトコルバージョンと完全に互換性があります。 ack-slo-managerからack-koordinatorにシームレスにアップグレードできます。

説明

ack-koordinatorは、2023年7月30日までのプロトコルバージョンと互換性があります。 以前のプロトコルバージョンで使用されていたリソースパラメーターを、最新バージョンで使用されているリソースパラメーターに置き換えることを推奨します。

次の表に、ack-koordinatorとさまざまなタイプのプロトコルの互換性を示します。

ack-koordinatorバージョン

alibabacloud.comプロトコル

koordinator.shプロトコル

≥ 0.2.0

対応

非対応

≥ 0.8.0

対応

対応

CPUバーストを有効にした後でもポッドがCPUスロットリングイベントを生成するのはなぜですか?

次の考えられる原因に基づいて設定を変更できます。

  • 構成形式が正しくないため、CPUバースト機能は有効になりません。 詳細については、「高度な設定」をご参照ください。

  • CPU使用率がcfsQuotaBurstPercentで指定された上限に達しても、CPUリソースが不足しているため、CPUスロットリングイベントが生成されます。

    アプリケーションの実際のリソース要求に基づいて、リソース要求と制限を調整することを推奨します。

  • CPUバーストでは、ポッドのcgroupパラメーターをcpu.cfs_quota_usおよびcpu.cfs_burst_usに調整できます。 詳細については、「高度な設定」をご参照ください。 cpu.cfs_quota_usは、ack-coordinatorがCPUスロットリングイベントを検出した後に変更されます。 したがって、調整は遅れて行われる。 cpu.cfs_burst_usは、既存の構成に基づいて直接変更されるため、より効率的です。

    最良の結果を得るには、Alibaba Cloud LinuxでCPUバーストを使用することを推奨します。

  • CPUバーストには、cpu.cfs_quota_usの値を変更する際の保護メカニズムがあります。 sharePoolThresholdPercentパラメーターを使用して、ノードのCPU使用率のしきい値を設定できます。 ノードのCPU使用率がしきい値に達すると、現在のポッドが他のポッドに影響を与えないように、cpu.cfs_quota_usの値が元の値にリセットされます。

    高い使用率がアプリケーションのパフォーマンスに影響しないように、アプリケーションの実際のステータスに基づいてCPU使用率のしきい値を設定することを推奨します。

CPUバーストはAlibaba Cloud Linuxのみをサポートしていますか?

ack-koordinatorが提供するCPUバースト機能は、Alibaba Cloud LinuxおよびオープンソースCentOSバージョンをサポートします。 Alibaba Cloud Linuxを選択することを推奨します。 Alibaba Cloud Linuxのカーネル機能により、ack-koordinatorはきめ細かい柔軟なCPUリソース管理を提供できます。 詳細については、「cgroup v1のCPUバースト機能の有効化」をご参照ください。