コンテナの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) を増加させる。 これはまた、コンテナにおけるロングテール待ち時間の問題を引き起こす。 | CPUバーストを有効にすると、コンテナがアイドル状態になったときに、コンテナはCPUタイムスライスを蓄積できます。 コンテナは、CPU要求が急上昇したときにCPU制限を超えてバーストするために累積CPUタイムスライスを使用することができる。 これは、性能を改善し、容器のRTを低減する。 |
上記のシナリオに加えて、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のマネージドサービスの課金トピックを読んで、カスタムメトリクスの無料クォータと課金ルールについて確認することをお勧めします。 リソース使用量を監視および管理する方法の詳細については、「観察可能なデータ量と請求書の照会」をご参照ください。
前提条件
ACK Proクラスターが作成され、クラスターのKubernetesバージョンが1.18以降になります。 詳細については、「ACK管理クラスターの作成」および「ACKクラスターの手動アップグレード」をご参照ください。
説明クラスターにAlibaba Cloud Linuxを選択することを推奨します。 詳細については、「」をご参照ください。CPUバーストはAlibaba Cloud Linuxのみをサポートしていますか?
ack-koordinator 0.8.0がクラスターにインストールされています。 詳細については、「ack-koordinator」をご参照ください。
使用上の注意
注釈を使用して、ポッドの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バースト機能は、クラスター全体で有効になります。
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
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バースト機能を有効にすることができます。
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.
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バーストがアクセス遅延を削減し、アプリケーションのパフォーマンスを向上させる方法を示します。
検証ステップ
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
次のコマンドを実行して、Apache HTTP Serverを使用してアプリケーションを作成します。
kubectl apply -f apache-demo.yaml
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を使用してパラメーターを設定できるかどうかを示します。 はサポートされ、はサポートされていません。
パラメーター | タイプ | 説明 | 注釈 | 設定マップ |
| String |
| ||
| int | デフォルト値: このパラメーターは、Alibaba Cloud Linuxが提供するカーネルレベルのCPUバースト機能を設定するために使用されます。 このパラメータは、CPUバーストによってCPU制限を増やすことができる割合を指定します。 このパラメーターは、cgroupの たとえば、 | ||
| int | デフォルト値: このパラメーターは、CFSクォータの自動調整が有効になっている場合に、 | ||
| int | デフォルト値: このパラメーターは、 | ||
| int | デフォルト値: このパラメーターは、CFSクォータの自動調整が有効になっている場合のノードのCPU使用率のしきい値を指定します。 ノードのCPU使用率がしきい値を超えると、各ポッドの |
policy
をcfsQuotaBurstOnly
またはauto
に設定してCFSクォータの自動調整を有効にすると、ノードのポッドCPU制限パラメーターcpu.cfs_quota_us
がCPUスロットリングのステータスに基づいて自動的に調整されます。コンテナでストレステストを実行する場合は、テスト全体でコンテナのCPU使用率を記録するか、
policy
をcpuBurstOnly
または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バースト機能の有効化」をご参照ください。