Container Service for Kubernetes:CPU Burst パフォーマンス最適化ポリシーを有効にする

利点

CPU 使用率は、コンテナーの健全性を測定するための主要なメトリックです。クラスター管理者は通常、このメトリックを使用してコンテナーの CPU Limit を設定します。一般的に使用される秒単位のメトリックと比較して、コンテナーのミリ秒レベルの CPU 使用率は、より顕著なグリッチと急激な変動を示すことがよくあります。次の図では、CPU 使用率は秒単位 (紫色の線) で 4 コアを大幅に下回っています。しかし、ミリ秒単位 (緑色の線) では、コンテナーの CPU 使用率は一部の期間で 4 コアを超えています。CPU Limit を 4 コアに設定すると、オペレーティングシステムは CPU スロットリングのためにスレッドを一時停止します。

次の図は、Web サービスコンテナーがリクエスト (req) を受信した後、4 コアノード上のコンテナーのスレッドに CPU リソースがどのように割り当てられるかを示しています。コンテナーの CPU Limit は 2 です。左の図は通常の場合を示しています。右の図は CPU Burst が有効になった後の場合を示しています。

前述のシナリオに加えて、CPU Burst は CPU 使用率の急上昇への対応にも適しています。たとえば、サービス トラフィックが急増した場合、ack-koordinator は、ノードの全体的な負荷を安全なレベルに維持しながら、数秒以内に CPU ボトルネックを解消できます。

シナリオ

CPU Burst 機能は、次のシナリオで役立ちます。

• コンテナーは、CPU 使用率が通常、設定された CPU Limit を下回っているにもかかわらず、頻繁に CPU スロットリングを経験し、アプリケーションのパフォーマンスに影響を与えます。CPU Burst を有効にすると、コンテナーは負荷のバースト時に蓄積されたタイムスライスを使用できます。これにより、CPU スロットリングの問題が効果的に解決され、アプリケーションのサービス品質が向上します。

• コンテナーアプリケーションは、起動段階でより多くの CPU リソースを消費します。アプリケーションが起動して安定した実行状態に入ると、その CPU 使用率はより低い安定したレベルに低下します。CPU Burst を有効にすると、アプリケーションは起動時により多くのタイムスライスを使用して、過度に高い CPU Limit を設定することなく迅速な起動を保証できます。

検証手順

1. サンプルアプリケーション用に次の内容を含む apache-demo.yaml という名前のファイルを作成します。

   Pod オブジェクトの metadata フィールドにアノテーションを追加して、Pod の CPU Burst ポリシーを有効にします。

   apiVersion: v1
   kind: Pod
   metadata:
     name: apache-demo
     annotations:
       koordinator.sh/cpuBurst: '{"policy": "auto"}'   # 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 # これを実際のノード名に変更します。
     hostNetwork: False
     restartPolicy: Never
     schedulerName: default-scheduler

2. 次のコマンドを実行して、評価対象のアプリケーションとして Apache HTTP Server をデプロイします。

   kubectl apply -f apache-demo.yaml

3. wrk2 ストレステストツールを使用してリクエストを送信します。

   # オープンソースの wrk2 テストツールをダウンロード、解凍、インストールします。詳細は https://github.com/giltene/wrk2 をご参照ください。
   # 現在の Apache イメージ設定では、サーバー側のリクエスト処理ロジックをシミュレートするために Gzip 圧縮モジュールが有効になっています。
   # ストレステストコマンドを実行します。IP アドレスをターゲットアプリケーションの IP アドレスに変更してください。
   ./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

   説明

   • コマンド内のターゲットアドレスを Apache Pod の IP アドレスに置き換えてください。

   • -R パラメーターを変更して、送信者からの QPS レートを調整できます。

結果分析

以下のデータは、CPU Burst ポリシーを有効にする前と後の Alibaba Cloud Linux およびコミュニティ版 CentOS でのパフォーマンスを示しています。

• 完全に無効とは、CPU Burst ポリシーが none に設定されていることを意味します。

• 有効にすると、CPU Burst ポリシーは auto に設定されます。

データ比較から次のことがわかります:

• CPU Burst 機能を有効にすると、アプリケーションの p99 応答時間 (RT) が大幅に改善されます。

• CPU Burst 機能を有効にすると、Pod の全体的な CPU 使用率はほとんど変わらないまま、CPU スロットリングが大幅に減少します。

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

はい。以前のバージョンの Pod プロトコルでは、alibabacloud.com/cpuBurst アノテーションを追加する必要があります。ack-koordinator は、これらの以前のプロトコルバージョンと完全に互換性があります。コンポーネントを新しいバージョンにシームレスにアップグレードできます。

以下に、ack-koordinator と異なるプロトコルバージョンとの互換性について説明します。

CPU Burst 設定を有効にした後、Pod が依然として CPU スロットリングを経験するのはなぜですか？

これにはいくつかの理由が考えられます。問題をトラブルシューティングするには、次の項目を確認してください。

• 設定フォーマットが正しくない可能性があり、そのために CPU Burst ポリシーが有効になっていない場合があります。詳細については、「詳細設定」をご参照いただき、設定を確認・修正してください。

• CPU リソースが不足しているために CPU 使用率が cfsQuotaBurstPercent で指定された上限に達した場合、CPU スロットリングイベントが引き続き生成される可能性があります。

  アプリケーションの実際のニーズに基づいて、Request と Limit の値を調整できます。

• CPU Burst ポリシーは、Pod の 2 つの cgroup パラメーター (cpu.cfs_quota_us と cpu.cfs_burst_us) を調整します。詳細については、「詳細なパラメーター設定」をご参照ください。cpu.cfs_quota_us パラメーターは、ack-koordinator が CPU Throttled イベントを検出した後にのみ設定されるため、わずかな遅延が発生します。対照的に、cpu.cfs_burst_us パラメーターは設定に基づいて直接設定されるため、より応答性が高くなります。

  最適な結果を得るには、Alibaba Cloud Linux オペレーティングシステムを使用することをお勧めします。

• CPU Burst ポリシーには、cpu.cfs_quota_us を調整するための保護メカニズムが含まれています。これは、sharePoolThresholdPercent パラメーターによって設定されるノードレベルの安全しきい値です。ノードの CPU 使用率が高くなりすぎると、cpu.cfs_quota_us は初期値にリセットされ、Pod が他の Pod に影響を与えるのを防ぎます。

  マシンの使用率が高いことによるパフォーマンスの低下を避けるために、アプリケーションの要件に基づいて安全しきい値を設定できます。

CPU Burst ポリシーを有効にするには Alibaba Cloud Linux オペレーティングシステムを使用する必要がありますか？

いいえ。ack-koordinator の CPU Burst ポリシーは、すべての Alibaba Cloud Linux および CentOS オープンソースカーネルをサポートしています。ただし、Alibaba Cloud Linux オペレーティングシステムを使用することをお勧めします。Alibaba Cloud Linux のカーネル機能により、ack-koordinator はより詳細で弾力性のある CPU 管理メカニズムを提供できます。詳細については、「cgroup v1 インターフェイスで CPU Burst 機能を有効にする」をご参照ください。

CPU Burst を有効にした後、アプリケーションのコードによって報告されるスレッド数が変わるのはなぜですか？

これは、CPU Burst メカニズムが一部のアプリケーションがシステムリソース情報を取得する方法と競合するために発生します。ack-koordinator は、コンテナーの基盤となる cgroup パラメーター cpu.cfs_quota_us を動的に調整することで CPU Burst を実装します。この値は、現在のスケジューリング期間内にコンテナーが利用できる CPU 時間クォータを表します。ack-koordinator は、アプリケーションの負荷に基づいてこのクォータを動的にスケーリングします。

Java の Runtime.getRuntime().availableProcessors() のような多くのアプリケーションは、cpu.cfs_quota_us を直接読み取って、利用可能な CPU コアの数を推測します。したがって、CPU クォータが動的に調整されると、アプリケーションが取得するコアの数も変化し、スレッドプールサイズなど、この値に依存するパラメーターが不安定になります。

Pod で定義されている固定の limits.cpu 値に依存するようにアプリケーションを変更することをお勧めします。

1. 環境変数の注入: resourceFieldRef を使用して、Pod の limits.cpu 値を環境変数としてコンテナーに注入できます。

   env: 
     - name: CPU_LIMIT 
       valueFrom: 
         resourceFieldRef: 
           resource: limits.cpu

2. アプリケーションコードの変更: アプリケーションの起動ロジックを変更して、CPU_LIMIT 環境変数を優先的に読み取り、スレッドプールサイズを計算して設定できます。この変更後、CPU Burst がクォータをどのように調整しても、アプリケーションは安定した信頼性の高い値に基づいて実行されます。