Container Service for Kubernetes:コロケーションの概要

アーキテクチャ

ACKはack-koordinatorコンポーネントを使用して、同じクラスターに配置された異なるワークロードのSLOを満たします。 ack-koordinatorは、SLOコントローラとSLOエージェントで構成されています。 SLOコントローラは標準のKubernetes拡張機能です。 SLOコントローラはDeploymentを使用してデプロイされ、SLOエージェントはDaemonSetを使用してデプロイされます。 SLOエージェントは、kubeletのすべての機能をサポートし、さまざまなコロケーション機能を提供します。

前の図は、コロケーションアーキテクチャを示しています。 ACKのSLOアウェアコロケーションソリューションは、複数のプロトコルを定義します。 これらのプロトコルにより、ACKは、カスタムリソース定義 (CRD) を使用して、ノードのメトリック、QoSポリシーの構成、およびQoSポリシーの施行を記録し、標準の拡張リソースを使用して、動的オーバーコミットメントに利用可能なリソースの量を記録できます。 図のコンポーネントには、次の機能があります。

• SLOコントローラ: 各ノードの負荷を監視し、リソースを過剰コミットし、リソースプロファイルに基づいてSLOを保証します。

• Recommender: リソースプロファイリング機能を提供し、ワークロードのピークリソース需要を推定します。 Recommenderは、リソース要求の設定とコンテナの制限を簡素化します。

• Koordlet: 各ノードの負荷を監視し、異常を検出し、リソースを動的に分離し、閉ループで干渉を抑制します。

• ACKスケジューラ: SLO対応のコロケーションを最適化します。 例えば、リソースが動的にオーバーコミットされる場合、ACKスケジューラはポッドを拡散することができる。

• Koordinator Descheduler: デプロイとしてデプロイされ、再スケジューリングに使用されます。

リソースモデル

Kubernetesで使用されるリソース管理メカニズムでは、リソース要求と制限に基づいてリソースを申請するコンテナーが必要です。 リソースの競合を防ぐために、管理者は通常、リソース要求とコンテナーの制限をLSワークロードに対してより大きな値に設定します。 その結果、大量のリソースが要求されるが、実際のリソース利用率は依然として低い。

次の図の緑色のブロックは、動的にオーバーコミットできるリソースの量を示しています。 リソースはBEワークロードに割り当てられ、異なるワークロードがSLOを満たし、全体的なリソース使用率を改善できるようにします。

ack-koordinatorは、動的にオーバーコミットされる可能性のあるリソースを定量化し、再利用されるリソースの量をリアルタイムで計算し、標準の拡張リソースとしての情報をKubernetesノードメタデータに同期できます。

次のサンプルコードは、ノードのYAMLテンプレートの例を示しています。

status:
  allocatable:
    # milli-core
    kubernetes.io/batch-cpu: 50000
    # bytes
    kubernetes.io/batch-memory: 50000
  capacity:
    kubernetes.io/batch-cpu: 50000
    kubernetes.io/batch-memory: 100000

BEポッドの優先度はLSポッドの優先度よりも低くなっています。 回収されたリソースを使用するようにBEポッドを構成するには、BEポッドのYAMLテンプレートにqosフィールドとbatchフィールドを追加するだけです。 qos: LSは高い優先度を示し、qos: BEは低い優先度を示す。 batch-cpuとbatch-memoryは、ポッドによって要求されたリソースの量を示します。 詳細については、「動的リソースのオーバーコミットメント」をご参照ください。

次のサンプルコードは、BEポッドのYAMLテンプレートの例を示しています。

metadata:
  labels:
    koordinator.sh/qosClass: "BE" # Set the QoS class to BE or LS. 
spec:
  containers:
  - resources:
      limits:
        kubernetes.io/batch-cpu: 1000
        kubernetes.io/batch-memory: 2048
      requests:
        kubernetes.io/batch-cpu: 1000
        kubernetes.io/batch-memory: 2048

ノードレベルQoS

CPU QoS

LSポッドのCPUリソースを予約し、BEポッドがリソースを競合しないようにするには、ack-koordinatorコンポーネントが提供するCPU QoS機能を使用します。 CPU QoS機能は、Alibaba Cloud Linuxに基づいています。 ack-koordinatorコンポーネントを使用すると、グループID機能を使用して、ポッドのLinuxスケジューリングの優先順位を設定できます。 LSポッドとBEポッドが同じ場所に配置されている環境では、リソースの競合を防ぐために、LSポッドの優先度を高く、BEポッドの優先度を低く設定できます。 LSポッドは、限られたCPUリソースを使用するように優先されます。 これにより、LSワークロードのサービス品質が保証されます。

CPU抑制

コロケーションのリソースモデルでは、動的にオーバーコミットできるリソースの合計量は、LSポッドのリソース使用量によって異なります。 リソースはbeポッドに割り当てることができます。 ノード上のLSポッドに十分なCPUリソースを確保するために、ack-koordinatorのCPU抑制機能を使用して、ノード上のBEポッドのリソース使用を制限できます。 CPU抑制機能は、ノードの全体的なリソース使用量がしきい値を下回る場合に、beポッドが使用できるCPUリソースの量を制限できます。 これにより、ノード上のコンテナが安定して実行するのに十分なリソースを確保できます。

次の図では、CPUしきい値はノードのCPU使用率しきい値を示します。 ポッド (LS).UsageはLSポッドのCPU使用率を示します。 BEのCPU制限は、BEポッドのCPU使用率を示します。 beポッドで使用できるCPUリソースの量は、LSポッドのCPU使用率の変動に基づいて調整されます。 これにより、BEポッドはアイドルリソースを利用でき、BEワークロードのスループットが向上します。 これにより、LSワークロードの負荷が増加したときにBEポッドがリソースを競合することもなくなります。

CPUバースト

Kubernetesでは、リソース制限を使用してKubernetesリソースを管理できます。 CPU制限を設定して、OSカーネルが、ある期間内にコンテナが使用できるCPUリソースの量を制限できるようにすることができます。 たとえば、CPU制限=2を指定できます。 OSカーネルは、コンテナが使用できるCPUタイムスライスを、各100ミリ秒の期間内で200ミリ秒に制限します。

次の図は、4つのvCoresを持つノードで実行されるwebアプリケーションコンテナーのスレッド割り当てを示しています。 コンテナのCPU制限は2に設定されています。 最後の1秒以内の全体的なCPU使用率は低い。 ただし、スレッド2は、2番目の100ミリ秒期間のどこかでCPUスロットリングが実施されるため、3番目の100ミリ秒期間が開始するまで再開できません。 これは、応答時間 (RT) を増加させ、コンテナにおけるロングテール待ち時間の問題を引き起こす。

CPUバースト機能を使用すると、LSワークロードのロングテール遅延の問題を効率的に解決できます。 この機能により、コンテナがアイドル状態のときに、コンテナはCPUタイムスライスを収集できます。 これらのCPUタイムスライスは、リソース需要の急増を処理し、コンテナのパフォーマンスを向上させるために使用できます。 ACKを使用すると、CPUバーストをサポートするすべてのカーネルバージョンを使用できます。 CPUバーストをサポートしないカーネルバージョンの場合、ACKはCPUスロットリングを監視し、コンテナのCPU制限を動的に調整して、CPUバーストと同様にコンテナのパフォーマンスを最適化します。

メモリQoS

ランタイムのパフォーマンスとノードの安定性を向上させるために、ack-koordinatorはAlibaba Cloud Linuxと連携してポッドのメモリQoS機能を有効にします。 ack-koordinatorはコンテナ設定に基づいてmemcgを自動的に設定し、memcg QoS機能、memcgバックエンド非同期再利用機能、およびコンテナのグローバル最小透かし評価機能を有効にできます。 これにより、コンテナ間での公平なメモリスケジューリングを確保しながら、メモリ依存アプリケーションのパフォーマンスが最適化されます。

L3キャッシュとMBAに基づくリソースの分離

異なるワークロードのコンテナがノード上で共同配置されている場合、コンテナはノードのL3キャッシュ (ラストレベルキャッシュ) を共有します。 これらのワークロードに分散されるメモリ帯域幅は、メモリ帯域幅割り当て (MBA) によって制御されます。 ECSベアメタルインスタンスは、ポッドで使用できるCPUキャッシュを動的に調整するためのラストレベルキャッシュ (LLC) 機能と、メモリ帯域幅の分散を制御するためのMBA機能を提供します。 さらに、ack-koordinatorは、LSポッドのパフォーマンスを確保するために、BEポッドで使用されるリソースをきめ細かく制限します。

次のステップ