Container Service for Kubernetes:CPU トポロジー対応スケジューリング

仕組み

デフォルトでは、Kubernetes はカーネルの Completely Fair Scheduler (CFS) に依存して CPU 負荷を分散します。このスケジューラは、CPU タイムスライスを公平に割り当てることで、すべてのコアに負荷を分散します。しかし、このスケジューラは物理 CPU トポロジーを無視するため、センシティブなアプリケーションでパフォーマンスジッターを引き起こす可能性があります。

Kubernetes CPU マネージャー (static ポリシー) は、Pod を専用の CPU コアにバインドできますが、以下の制限があります。

• スケジューラの認識不足：ネイティブの kube-scheduler はノードレベルでのみ決定を下します。クラスター全体の CPU トポロジーを認識できないため、グローバルなスケールで Pod に最適な物理コアのレイアウトを見つけることができません。

• トポロジー認識の欠如: ノードでコアを割り当てる際、static ポリシーは NUMA アーキテクチャを認識しません。これにより、NUMA ノード間のメモリアクセスが発生し、余分なレイテンシーが生じる可能性があります。

• 柔軟性の欠如：このポリシーでは、Pod の QoS クラスが <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#guaranteed" id="5b2a90624cgtc">Guaranteed</a> である必要があります。<a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#burstable" id="174c05a5978cf">Burstable</a> または <a href="https://kubernetes.io/docs/concepts/workloads/pods/pod-qos/#burstable" id="6cada2573fokq">BestEffort</a> の Pod には適用できません。

これらの制限に対処するため、Container Service for Kubernetes (ACK) は、新しい Scheduling Framework に基づく強化された CPU トポロジー対応スケジューリングを提供します。この機能は、ACK の kube-scheduler と ack-koordinator の連携によって実現されます。

1. ノードトポロジーの報告：ack-koordinator コンポーネントは、ソケット、NUMA ノード、キャッシュなどのローカル物理 CPU トポロジーをリアルタイムで検出し、そのトポロジーをスケジューリングセンターに報告します。

2. グローバルトポロジー対応スケジューリング：kube-scheduler は、グローバルなトポロジー情報を使用して、クラスター全体から Pod に最適なノードを選択し、コア割り当てスキームを計画します。例えば、最適なノードを選択する際、スケジューラはデフォルトでバインドされているアプリケーションが最も少ないコアを見つけます。この割り当てスキームは、スケジューリング結果の一部として Pod のアノテーションに書き込まれます。

3. ローカルコアピニング：Pod がターゲットノードにスケジュールされると、ack-koordinator は Pod のアノテーションを読み取り、Pod の対応する Cgroup 内の cpuset.cpus ファイルを変更して、Pod を物理コアにバインドします。

ステップ 1：サンプルアプリケーションのデプロイ

このトピックでは、Nginx アプリケーションを例に、CPU トポロジー対応スケジューリングを有効にして CPU ピニングを実現する方法を説明します。

1. nginx-app.yaml ファイルを作成します。

   YAML の表示

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-deployment
     namespace: default
     labels:
       app: nginx
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: alibaba-cloud-linux-3-registry.cn-hangzhou.cr.aliyuncs.com/alinux3/nginx_optimized:20240221-1.20.1-2.3.0
           ports:
           - containerPort: 80
           command:
           - "sleep"
           - "infinity"
           resources:
             requests:
               cpu: 4
               memory: 8Gi
             limits:
               # CPU の値を設定します。整数である必要があります。
               cpu: 4 
               memory: 8Gi

2. アプリケーションをデプロイします。

   kubectl apply -f nginx-app.yaml

3. Pod が配置されているノードにログインし、Pod UID とコンテナー ID を取得します。

   • Pod 名を取得します。
     kubectl get pods -n <your-namespace> コマンドを実行して、nginx-deployment-6f5899***** のような Pod 名を確認します。
     
     

   • Pod UID を取得します。

     # <your-pod-name> を実際の Pod 名に置き換えます
     kubectl get pod <your-pod-name> -n default -o jsonpath='{.metadata.uid}{"\n"}'

     期待される出力：

       uid: a78a02b5-c87f-4e74-9ddd-254c163*****

   • コンテナー ID を取得します。

     # <your-pod-name> を実際の Pod 名に置き換えます
     kubectl describe pod <your-pod-name> -n default

     出力で Containers フィールドを探し、Container ID を見つけて、containerd:// のようなプレフィックスを削除します。

     期待される出力：

     Containers:
       nginx:
         Container ID:   containerd://b8b88a70096aabb0aea197dd2aba78d15bcbe9145198ef46a0474b31*****

4. ノードの cgroup バージョンを確認します。

   stat -fc %T /sys/fs/cgroup/

   • 出力が cgroup_root の場合、システムは cgroup v1 を使用しています。

   • 出力が cgroup2fs の場合、システムは cgroup v2 を使用しています。

5. cgroup バージョンに基づいて対応する検証コマンドを実行し、CPU ピニングの状態を確認します。

   cgroup パスでは、Pod UID のハイフン (-) をアンダースコア (_) に置き換えます。例えば、元の Pod UID が a78a02b5-c87f-4e74-9ddd-254c163***** の場合、パスで使用されるフォーマットは a78a02b5_c87f_4e74_9ddd_254c163***** です。

   • cgroup v1：

     # <POD_UID> と <CONTAINER_ID> を実際の値に置き換えます
     cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod<POD_UID>.slice/cri-containerd-<CONTAINER_ID>.scope/cpuset.cpus

   • cgroup v2：

     # <POD_UID> と <CONTAINER_ID> を実際の値に置き換えます
     cat /sys/fs/cgroup/kubepods.slice/kubepods-pod<POD_UID>.slice/cri-containerd-<CONTAINER_ID>.scope/cpuset.cpus.effective

   期待される出力は範囲であり、これはコンテナーがノード上のすべてのコアを使用でき、ピニングされていないことを意味します。

   0-31

ステップ 2：CPU トポロジー対応スケジューリングの有効化

Pod にアノテーションを追加することで、CPU トポロジー対応スケジューリングを有効にできます。

• 一般的なピニングポリシー：1:1 のピニング原則に従う一般的なポリシーです。resources.limits.cpu で指定されたコア数を Pod にバインドします。最適なメモリアクセスパフォーマンスを確保するために、同じ NUMA ノード内の CPU コアを優先します。

• 自動ピニングポリシー：特定のハードウェアに最適化されたポリシーです。完全な物理コアクラスター (AMD CPU の CCX/CCD など) のバインドを優先し、CPU ローカリティを最大化して並行性を向上させます。これは、特定のラージスケール (32 コア以上) の AMD マシンタイプに推奨されます。

関連操作

本番環境での推奨事項

• 可観測性：コアピニングを有効にする前後で、Alibaba Cloud Prometheus モニタリングとの連携を行います。応答時間 (RT) や QPS などの主要なアプリケーションパフォーマンスメトリック、および CPU 使用率や CPU スロットリングなどのノードメトリックを注意深く監視し、コアピニングによるパフォーマンスの変化を観察します。

• 段階的なロールアウト：複数のレプリカを持つアプリケーションの場合、カナリアリリースや段階的な更新を使用して、ピニングポリシーを徐々に有効または無効にします。これにより、変更に伴うリスクを管理できます。

課金

ack-koordinator コンポーネントのインストールと使用は無料です。ただし、以下のシナリオでは追加料金が発生する場合があります：

• ack-koordinator は自己管理コンポーネントであり、インストール後にワーカーノードのリソースを消費します。コンポーネントのインストール時に、各モジュールのリソースリクエストを設定できます。

• デフォルトでは、ack-koordinator は、リソースプロファイリングや詳細なスケジューリングなどの機能のモニタリングメトリックを Prometheus フォーマットで公開します。コンポーネントの設定時に [ack-koordinator の Prometheus モニタリングを有効にする] オプションを選択し、Alibaba Cloud Prometheus サービスを使用する場合、これらのメトリックはカスタムメトリックと見なされ、料金が発生します。料金は、クラスターのサイズやアプリケーションの数などの要因によって異なります。この機能を有効にする前に、Alibaba Cloud Prometheus のPrometheus インスタンスの課金に関するドキュメントをよく読み、カスタムメトリックの無料クォータと課金ポリシーを理解してください。使用量データのクエリによって、リソース使用量を監視および管理できます。

関連ドキュメント

• ACK は GPU トポロジー対応スケジューリングをサポートしており、ノード上の GPU の最適な組み合わせを選択して、最高のトレーニング速度を実現できます。

• クラスター内で割り当てられているが使用されていないリソースを定量化し、それらを優先度の低いジョブに提供できます。これにより、動的リソースオーバーコミットメントが実現します。