Koordinator v1.6: AI/MLシナリオにおけるヘテロジニアスリソーススケジューリングをサポート

> 本記事は[こちらのブログ](https://www.alibabacloud.com/blog/koordinator-v1-6-supports-heterogeneous-resource-scheduling-in-aiml-scenarios_602051?spm=a2c65.11461433.0.0.4ee35355Di53WO)を参考にしています。
> 翻訳にはアリババクラウドの[ModelStudio](https://www.alibabacloud.com/en/product/modelstudio)([Qwen](https://www.alibabacloud.com/en/solutions/generative-ai/qwen))を使用しております。

# 背景

DeepSeekなどの大規模モデルの普及に伴い、AIおよび高性能コンピューティング分野におけるGPU、NPU、RDMAなどの異種デバイスリソースのスケジューリング需要が急速に増加しています。これらのリソースを効率的に管理しスケジュールすることが、業界の核心的な課題となっています。このような背景のもと、Koordinatorはコミュニティのニーズに積極的に応え、異種デバイススケジューリング能力を継続的に強化し、最新のv1.6バージョンで一連の革新的な機能を導入しました。これにより、顧客が異種リソーススケジューリングの課題を解決する手助けをすることを目指しています。v1.6では、より多くのモデルのGPUトポロジーを認識するためのデバイストポロジースケジューリング能力を向上させ、AIアプリケーションにおけるGPU相互接続性能を大幅に加速しました。オープンソースプロジェクトHAMiとの協力により、エンドツーエンドのGPUおよびRDMA共同割り当て能力と強力なGPU分離能力を提供しました。これにより、典型的なAIトレーニングタスクのクロスマシン相互接続効率と推論タスクの展開密度が向上し、アプリケーションのパフォーマンスが確保され、クラスターリソースの利用率が改善されました。Kubernetesコミュニティは、異なるリソースに対して異なるノードスコアリングポリシーを設定できる拡張リソースプラグインを提供しており、この機能は、GPUとCPUタスクがクラスター内で展開される際にGPUの断片化率を効果的に低減できます。2022年4月の正式リリース以来、Koordinatorは14回の大規模バージョンアップデートを行い、Alibaba、Ant Group、REDnote、iQIYI、Youzanなど多くの企業から優秀なエンジニアが参加し、豊富なアイデア、コード、実用的なアプリケーションシナリオを提供してくれました。これはプロジェクトの発展に大きく寄与しました。特に、v1.6.0では、合計10名の新しい開発者がKoordinatorコミュニティの構築に積極的に参加しました。彼らは@LY-today、@AdrianMachao、@TaoYang526、@dongjiang1989、@chengjoey、@JBinin、@clay-wangzhi、@ferris-cx、@nce3xin、そして@lijunxin559です。彼らの貢献に感謝するとともに、すべてのコミュニティメンバーの継続的な努力とサポートに感謝します。

# 核心ハイライト

## 1. トポロジー認識型GPUスケジューリング: AIアプリケーションにおけるGPU相互接続を加速

ディープラーニングや高性能コンピューティング（HPC）分野の急速な発展に伴い、GPUは多くの計算集約型ワークロードにとって中核的なリソースとなっています。Kubernetesクラスターにおいて、GPUを効率的に使用することでアプリケーションのパフォーマンスを大幅に向上させることができます。しかし、GPUリソースのパフォーマンスはハードウェアトポロジーやリソース構成によって不均衡になることがあります。例：

複数のNUMAノードを持つシステムでは、GPU、CPU、メモリ間の物理的な接続がデータ転送と計算効率に影響を与える可能性があります。L20、L40SなどのNVIDIAのモデルでは、GPU間の通信効率は、それらが同じPCIeまたはNUMAノードに属しているかどうかに依存します。また、仮想化環境でSharedNVSwitchモードを使用するAscend NPUやNVIDIA Hシリーズマシンでは、GPUはいくつかの事前定義されたパーティションルールに基づいて割り当てる必要があります。
![1](https://yqintl.alicdn.com/60dd07135b9b402b203d56404dc0c56248f94084.png)

上記のデバイスシナリオに対応して、KoordinatorはポッドのGPUトポロジー要件を満たすために多様なデバイストポロジースケジューリングAPIを提供しています。以下は、これらのAPIの使用例です：

1. GPU、CPU、メモリが同じNUMAノードに割り当てられる場合：yaml
apiVersion: v1
kind: Pod
metadata: 
  annotations: 
    scheduling.koordinator.sh_disabled/numa-topology-spec: {numaTopologyPolicy:Restricted, singleNUMANodeExclusive:Preferred}
spec: 
  containers: 
  - resources: 
      limits: 
        koordinator.sh_disabled/gpu: 200
        cpu: 64
        memory: 500Gi
      requests: 
        koordinator.sh_disabled/gpu: 200
        cpu: 64
        memory: 500Gi

2. GPUが同じPCIeに割り当てられる場合：yaml
apiVersion: v1
kind: Pod
metadata: 
  annotations: 
    scheduling.koordinator.sh_disabled/device-allocate-hint: |-
      {
        gpu: {
          requiredTopologyScope: PCIe
        }
      }
spec: 
  containers: 
  - resources: 
      limits: 
        koordinator.sh_disabled/gpu: 200

3. GPUが同じNUMAノードに割り当てられる場合：yaml
apiVersion: v1
kind: Pod
metadata: 
  annotations: 
    scheduling.koordinator.sh_disabled/device-allocate-hint: |-
      {
        gpu: {
          requiredTopologyScope: NUMANode
        }
      }
spec: 
  containers: 
  - resources: 
      limits: 
        koordinator.sh_disabled/gpu: 400

4. GPUは事前定義されたパーティションに基づいて割り当てる必要がある場合：一般的に、GPUの事前定義されたパーティションルールは特定のGPUモデルやシステム構成によって決定され、特定のノード上のGPU構成にも影響を受ける場合があります。スケジューラーはハードウェアモデルやGPUタイプの詳細を取得することはできず、代わりにノードレベルのコンポーネントがこれらの事前定義されたルールをデバイスカスタムリソース（CR）に報告します。
サンプルコード：yaml
apiVersion: scheduling.koordinator.sh_disabled/v1alpha1
kind: Device
metadata: 
  annotations: 
    scheduling.koordinator.sh_disabled/gpu-partitions: |
      {
        1: [
            NVLINK: {
                {
                  # どのGPUが含まれるか
                  minors: [
                      0
                  ], 
                  # GPU相互接続タイプ
                  gpuLinkType: NVLink,
                  # ここではRingアルゴリズムにおけるGPU間のボトルネック帯域幅を取っています。BusBandwidthは https://github.com/NVIDIA/nccl-tests/blob/master/doc/PERFORMANCE.md を参照してください。
                  ringBusBandwidth: 400Gi
                  # パーティションが割り当てられた後のノード全体の割り当て品質を示します。 allocationScore: 1,
                },
                ... 
            }
            ... 
        ], 
        2: [
            ... 
        ], 
        4: [
            ... 
        ], 
        8: [
            ... 
        ] 
      }
  labels: 
    // パーティションルールを遵守する必要があるかどうかを示します。 node.koordinator.sh_disabled/gpu-partition-policy: Honor
  name: node-1

複数の選択可能なパーティションスキームが存在する場合、Koordinatorはユーザーが最適なパーティションに基づいてGPUを割り当てるかどうかを決定することを許可します：yaml
kind: Pod
metadata: 
  name: hello-gpu
  annotations: 
    scheduling.koordinator.sh_disabled/gpu-partition-spec: |
      {
        # BestEffort|Restricted
        allocatePolicy: Restricted, 
      }
spec: 
  containers: 
    - name: main
      resources: 
        limits: 
          koordinator.sh_disabled/gpu: 100

ユーザーが最適なパーティションに基づいてGPUを割り当てる必要がない場合、スケジューラーは可能な限りbinpackアルゴリズムに基づいて動作します。トポロジー認識型GPUスケジューリングに関する詳細情報
### Koordinator v1.6.0のベストプラクティスとGPU・RDMAジョイント割り当て

多くのコンポーネントが関与し、環境が複雑であるため、Koordinator v1.6.0では<a href=https://koordinator.sh_disabled/docs/next/best-practices/gpu-and-rdma-joint-allocation target=_blank>ベストプラクティス</a>を提供しており、Koordinator、Multus-CNI、およびSRIOV-CNIをステップバイステップでデプロイする方法を示しています。関連するコンポーネントをデプロイした後、ユーザーは次のPodプロトコルを使用して、スケジューラにGPUおよびRDMAの共同割り当てをリクエストできます。yaml
apiVersion: v1
kind: Pod
metadata: 
  name: pod-vf01
  namespace: kubeflow
  annotations: 
    scheduling.koordinator.sh_disabled/device-joint-allocate: |-
      {
        deviceTypes: [gpu,rdma]
      }
    scheduling.koordinator.sh_disabled/device-allocate-hint: |-
      {
       rdma: {
         vfSelector: {} //apply VF
       }
      }
spec: 
  schedulerName: koord-scheduler
  containers: 
  - name: container-vf
    resources: 
      requests: 
        koordinator.sh_disabled/gpu: 100
        koordinator.sh_disabled/rdma: 100
      limits: 
        koordinator.sh_disabled/gpu: 100
        koordinator.sh_disabled/rdma: 100

GDRタスクに対してKoordinatorを使用してエンドツーエンドのテストをさらに実施するには、<a href=https://koordinator.sh_disabled/docs/next/best-practices/gpu-and-rdma-joint-allocation target=_blank>ベストプラクティス</a>の例をステップバイステップで参照してください。この機能への貢献をしていただいたコミュニティ開発者の@ferris-cxに心から感謝します！

---

### 3. 強力なGPU共有の分離: AI推論タスクにおけるリソース利用率の向上

AIアプリケーションでは、GPUは大規模モデルのトレーニングや推論に欠かせないコアデバイスであり、計算集約型タスクに強力な計算能力を提供します。しかし、この強力な計算能力はしばしば高コストを伴います。実際の運用では、次のような状況によく遭遇します。高性能なGPUカードを使用して、GPUリソースのごく一部（例えば20％の計算能力やGPUメモリ）しか使用しない小さなモデルや軽量な推論タスクを実行しなければならない場合です。このようなリソース利用は、貴重なGPU計算能力を浪費するだけでなく、企業のコストを大幅に増加させます。このような状況は特に以下のシナリオでよく見られます：

- **オンライン推論**: 多くのオンライン推論タスクは計算要件が低いものの、レイテンシ要件が高いです。リアルタイム性を満たすために高性能なGPU上にデプロイする必要があります。
- **開発・テスト環境**: 開発者がモデルをデバッグする際、少量のGPUリソースしか必要としませんが、従来のスケジューリング方式ではリソース利用率が低くなります。
- **マルチテナント共有クラスタ**: 複数のユーザーやチームが共有するGPUクラスタでは、各タスクがGPUを独占的に占有するため、リソース配分が不均一になり、ハードウェア能力を十分に活用することが困難になります。

この問題を解決するために、KoordinatorとHAMiはユーザーにGPU共有の分離を提供し、複数のポッドが同じGPUカードを共有できるようにします。これにより、GPUのリソース利用率を大幅に向上させ、企業のコストを削減し、さまざまなタスクの柔軟なリソース要件を満たすことができます。例えば、KoordinatorのGPU共有モードでは、ユーザーはGPUコア数やGPUメモリ比率を正確に割り当てることができ、各タスクが必要なリソースを取得しつつ、相互干渉を回避できます。

![4](https://yqintl.alicdn.com/119f477781f8652ca303767a06b863774b9ef593.png)

HAMiはCNCFサンドボックスプロジェクトであり、Kubernetes向けのデバイス管理ミドルウェアを提供します。そのコアモジュールであるHAMi-Coreは、CUDA-Runtime（libcudart.so）とCUDA-Driver（libcuda.so）間のAPI呼び出しをハイジャックすることで、GPU共有の分離機能を提供します。v1.6.0では、KoordinatorはHAMi-CoreのGPU分離機能を利用して、エンドツーエンドのGPU共有ソリューションを提供します。以下のYAMLファイルを使用してDaemonSetをデプロイし、対応するノードにHAMi-Coreを直接インストールできます。yaml
apiVersion: apps/v1
kind: DaemonSet
metadata: 
  name: hami-core-distribute
  namespace: default
spec: 
  selector: 
    matchLabels: 
      koord-app: hami-core-distribute
  template: 
    metadata: 
      labels: 
        koord-app: hami-core-distribute
    spec: 
      affinity: 
        nodeAffinity: 
          requiredDuringSchedulingIgnoredDuringExecution: 
            nodeSelectorTerms: 
            - matchExpressions: 
              - key: node-type
                operator: In
                values: 
                - gpu
      containers: 
      - command: 
        - /bin/sh_disabled
        - -c
        - |
          cp -f /k8s-vgpu/lib/nvidia/libvgpu.so /usl/local/vgpu && sleep 3600000
        image: docker.m.daocloud.io/projecthami/hami:v2.4.0
        imagePullPolicy: Always
        name: name
        resources: 
          limits: 
            cpu: 200m
            memory: 256Mi
          requests: 
            cpu: 0
            memory: 0
        volumeMounts: 
        - mountPath: /usl/local/vgpu
          name: vgpu-hook
        - mountPath: /tmp/vgpulock
          name: vgpu-lock
      tolerations: 
      - operator: Exists
      volumes: 
      - hostPath: 
          path: /usl/local/vgpu
          type: DirectoryOrCreate
        name: vgpu-hook
     # https://github.com/Project-HAMi/HAMi/issues/696
      - hostPath: 
          path: /tmp/vgpulock
          type: DirectoryOrCreate
        name: vgpu-lock

デフォルトでは、KoordinatorスケジューラーでGPUビンパッキングが有効になっています。KoordinatorとHAMi-Coreをインストールすると、次の方法でGPU共有カードを申請し、HAMi-Coreの分離を有効にできます。yaml
apiVersion: v1
kind: Pod
metadata: 
  name: pod-example
  namespace: default
  labels: 
    koordinator.sh_disabled/gpu-isolation-provider: hami-core
spec: 
  schedulerName: koord-scheduler
  containers: 
  - command: 
    - sleep
    - 365d
    image: busybox
    imagePullPolicy: IfNotPresent
    name: curlimage
    resources: 
      limits: 
        cpu: 40m
        memory: 40Mi
        koordinator.sh_disabled/gpu-shared: 1
        koordinator.sh_disabled/gpu-core: 50
        koordinator.sh_disabled/gpu-memory-ratio: 50
      requests: 
        cpu: 40m
        memory: 40Mi
        koordinator.sh_disabled/gpu-shared: 1
        koordinator.sh_disabled/gpu-core: 50
        koordinator.sh_disabled/gpu-memory-ratio: 50
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
  restartPolicy: Always

HAMi GPU共有分離機能をKoordinatorで有効にする手順については、以下を参照してください：
- <a href=https://koordinator.sh_disabled/docs/next/user-manuals/device-scheduling-gpu-share-with-hami target=_blank>Device Scheduling - GPU Share With HAMi</a>

この機能への貢献をしていただいたHAMiコミュニティメンバーの@wawa021
例:
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles: 
  - pluginConfig: 
      - name: NodeResourcesFit
        args: 
          apiVersion: kubescheduler.config.k8s.io/v1
          kind: NodeResourcesFitArgs
          scoringStrategy: 
            type: LeastAllocated
            resources: 
              - name: cpu
                weight: 1
              - name: memory
                weight: 1
              - name: nvidia.com/gpu
                weight: 1
しかし、実際の運用では、この設計は一部のシナリオでは適用できません。例えば、AIのシナリオでは、GPUを要求するサービスは、GPUの断片化を防ぐために、GPU全体を優先的に占有したいと考えています。一方で、CPUやメモリリソースを要求するサービスは、CPUのホットスポットを減らすために分散を優先したいと考えています。Koordinatorはv1.6.0でNodeResourceFitPlusプラグインを導入し、異なるリソースに対して差別化されたスコアリングポリシーを設定できるようにしました。Koordinatorスケジューラーをインストールする際に、以下の設定を使用できます。
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles: 
- pluginConfig: 
  - args: 
      apiVersion: kubescheduler.config.k8s.io/v1
      kind: NodeResourcesFitPlusArgs
      resources: 
        nvidia.com/gpu: 
          type: MostAllocated
          weight: 2
        cpu: 
          type: LeastAllocated
          weight: 1
        memory: 
          type: LeastAllocated
          weight: 1
    name: NodeResourcesFitPlus
  plugins: 
    score: 
      enabled: 
      - name: NodeResourcesFitPlus
        weight: 2
  schedulerName: koord-scheduler
さらに、CPUとメモリリソースを要求するサービスは、GPUマシン上で過剰なCPUやメモリが消費され、結果としてGPUを必要とするタスクが非GPUリソース不足によりPending状態になることを防ぐため、非GPUマシンに優先的に分散されることが望ましい場合があります。Koordinatorはv1.6.0でScarceResourceAvoidanceプラグインを導入し、この要件に対応しました。以下のようにスケジューラーを設定できます。これは、nvidia.com/gpuが希少リソースであることを示します。Podがこの希少リソースを要求しない場合、そのPodをスケジュールしないよう回避しようとします。
apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles: 
- pluginConfig: 
  - args: 
      apiVersion: kubescheduler.config.k8s.io/v1
      kind: ScarceResourceAvoidanceArgs
      resources: 
      - nvidia.com/gpu
    name: ScarceResourceAvoidance
  plugins: 
    score: 
      enabled: 
      - name: NodeResourcesFitPlus
        weight: 2
      - name: ScarceResourceAvoidance
        weight: 2
      disabled: 
      - name: *
  schedulerName: koord-scheduler
GPUリソースの差別化されたスケジューリングポリシーの設計および使用方法に関する詳細情報は、次のリンクを参照してください：
•    [設計文書](https://koordinator.sh_disabled/docs/next/designs/node-resource-fit-plus-scoring)
•    [ユーザーマニュアル](https://koordinator.sh_disabled/docs/next/user-manuals/node-resource-fit-plus-scoring/)
コミュニティ開発者@LY-today氏に感謝いたします。5. 精密なリソース予約：AIタスクの効率的な運用要件を満たす
異種リソースの効率的な利用は、しばしば密接に関連するCPUとNUMAリソースの正確な整列に依存します。例：
•    GPUアクセラレーションタスク：複数のNUMAノードを持つサーバーにおいて、GPUとCPUまたはメモリの物理的な接続がNUMA境界を越える場合、データ転送のレイテンシが増加し、タスクパフォーマンスが大幅に低下する可能性があります。そのため、このようなタスクでは通常、GPU、CPU、およびメモリが同じNUMAノードに割り当てられることが求められます。 •    AI推論サービス：オンライン推論タスクはレイテンシに敏感であるため、GPUとCPUリソースが可能な限り近くに割り当てられることを確認し、NUMAノード間の通信オーバーヘッドを削減することが重要です。 •    科学計算タスク：分子動力学（MD）シミュレーションや天気予報などの一部の高性能コンピューティングタスクは、高帯域幅で低遅延のメモリアクセスが必要であり、CPUコアとローカルメモリの厳密な整列が求められます。これらの要件は、タスクスケジューリングだけでなく、リソース予約のシナリオにも適用されます。本番環境では、リソース予約は重要なメカニズムであり、重要なタスクのためにリソースを事前にロックし、将来の特定時点での円滑な動作を確保します。しかし、異種リソースのシナリオでは、単純なリソース予約メカニズムでは精密なリソースオーケストレーションの要件を満たせないことが多いです。例：
•    一部のタスクでは、最適なパフォーマンスを得るために、特定のNUMAノード上のCPUおよびGPUリソースを予約する必要があります。 •    マルチテナントクラスターでは、異なるユーザーが異なるリソースタイプの組み合わせ（例えば、GPU + CPU + メモリ）を予約し、それらのリソースが厳密に整列されることを期待しています。 •    予約されたリソースが完全に使用されていない場合、残りのリソースを他のタスクに柔軟に割り当てながら、予約されたタスクのリソース保証に影響を与えないようにすることが課題となります。これらの複雑なシナリオに対処するために、Koordinator v1.6ではリソース予約機能が大幅に強化され、より精密で柔軟なリソースオーケストレーション能力を提供します。具体的には、以下の問題が解決されました：

CPUおよびGPUリソースの精密な予約とプリエンプションをサポートします。 Podによる予約リソースの正確なマッチングをサポートします。 リソース予約アフィニティにより、予約名やティンティング耐性属性を指定できます。 リソース予約はPod数の制限をサポートします。 リソース予約は低優先度のPodをプリエンプトすることをサポートします。 プラグイン拡張インターフェースの変更：

予約リソース検証インターフェース（ReservationFilterPlugin）はPreScoreフェーズからFilterフェーズに移動し、より正確なフィルタリング結果を得られるようになりました。 予約リソース台帳返却インターフェース（ReservationRestorePlugin）は不要なメソッドを廃止し、スケジューリング効率を向上させました。 以下は新しい機能の使用例です：
1. 完全一致の予約
Podによる予約リソースの正確なマッチングにより、一連のPodと一連の予約リソース間のマッチング関係を絞り込み、予約リソースの割り当てをより制御可能にします。
apiVersion: v1
kind: Pod
metadata: 
  annotations: 
    # Podの予約リソースカテゴリを指定します。Podは、これらのリソースカテゴリ下でPod仕様と同じ量の予約リソースを持つReservationオブジェクトのみにマッチできます。例として、cpu、memory、およびnvidia.com/gpuを指定できます。 scheduling.koordinator.sh_disabled/exact-match-reservation: {resourceNames:{cpu,memory,nvidia.com/gpu}}
2. 予約無視
Podがリソース予約を無視するように指定すると、Podは予約済みだが未割り当てのアイドルリソースをノード上に埋めることができます。これにより、プリエンプションを使用する際にリソースの断片化をさらに減少させます。
apiVersion: v1
kind: Pod
metadata: 
  labels: 
    # Podの
しかし、ハイブリッドクラスタのリソース使用率が継続的に向上する中で、異なる種類のタスク間でのリソース分離をどのように確保するかが重要な課題となっています。ハイブリッドデプロイメントのシナリオでは、リソース分離の中心的な目標は次の通りです：
- 高優先度タスクのパフォーマンスを保証する：例えば、オンラインサービスは低遅延要件を満たすために安定したCPU、メモリ、I/Oリソースが必要です。
- アイドルリソースを最大限に活用する：オフラインタスクは、高優先度タスクに干渉することなく、未使用のリソースを効率的に利用すべきです。
- リソース割り当てを動的に調整する：ノードの負荷変化に基づいてリアルタイムでリソース割り当てポリシーを調整し、リソース競合や浪費を回避します。

これらの目標を達成するために、Koordinatorはリソース分離機能の構築と改善を継続しています。v1.6では、リソース過剰コミットメントおよびハイブリッドQoSデプロイメントに関する一連の機能最適化と問題修正を行いました。これには以下の内容が含まれます：

Midリソースの過剰コミットメントとノードプロファイル機能により、ノード上で割り当てられていないリソースの計算ロジックと過剰コミットメントを最適化し、二次的な過剰コミットメントを回避します。負荷認識スケジューリングは、メトリック劣化のロジックを最適化します。CPU QoSおよびResctrl QoSはPod設定をサポートします。アウトオブバンド負荷管理はPrometheusメトリクスを補完し、観測性を向上させます。Blkio QoSやリソース増幅などの機能のバグを修正しました。

Midリソース過剰コミットメントはKoordinator v1.3で導入され、[node profiles](https://koordinator.sh_disabled/docs/designs/node-prediction)に基づいた動的リソース過剰コミットメントを提供します。ただし、過剰コミットメントされたリソースの安定性を確保するため、Midリソースはすべてノード上のスケジュールされたProd Podから取得されます。つまり、空のノードには最初はMidリソースが存在しません。このため、一部のワークロードがMidリソースを利用する際に不便が生じています。Koordinatorコミュニティは、いくつかの企業ユーザーからのフィードバックと貢献を受け取りました。! [6](https://yqintl.alicdn.com/a5e271a13a3a217a21e360cda32fa15f0a889d9f.png)

v1.6では、Koordinatorは過剰コミットメントの式を次のように更新しました：
MidAllocatable := min(ProdReclaimable, NodeAllocatable * thresholdRatio) + ProdUnallocated * unallocatedRatio
ProdReclaimable := min(max(0, ProdAllocated - ProdPeak * (1 + safeMargin)), NodeUnused)
計算ロジックには2つの変更があります：

- 未割り当てリソースは静的な比率に基づいて過剰コミットメントでき、コールドスタートの問題を緩和します。
- 実際に使用されているノードリソースは過剰コミットメントできません。これにより、二次的な過剰コミットメントによって推定値が大きくなりすぎるのを防ぎます。例えば、一部のユーザーがKoordinatorのノードリソース増幅機能を使用してより多くのProd Podをスケジュールすると、ProdAllocated > NodeAllocatableとなり、MidAllocatableの推定値が実際のノード負荷から逸脱することがあります。

さらに、ハイブリッドQoSデプロイメントに関して、Koordinator v1.6はPodのQoSポリシー設定機能を強化し、ハイブリッドデプロイメントノードにブラックリスト化された干渉Podを追加したり、カナリアハイブリッドQoSデプロイメントを調整するシナリオに対応しています。

- Resctrl機能は、PodのLLC（Last Level Cache）とメモリ帯域幅の分離をサポートします。
- CPU QoS機能は、PodのCPU QoS設定をサポートします。

Resctrl機能は次の方法で有効化できます：

- Koordletのfeature-gateでResctrl機能を有効にする。
- Pod Annotationプロトコル `node.koordinator.sh_disabled/resctrl` を使用して、LLCとメモリ帯域幅（MB）の制限ポリシーを設定する。例：yaml
apiVersion: v1
kind: Pod
metadata: 
  annotations: 
    node.koordinator.sh_disabled/resctrl: {llc: {schemata: {range: [0, 30]}}, mb: {schemata: {percent: 20}}}

CPU QoS設定は次の方法で有効化できます：

詳細については、[CPU QoSの有効化方法](https://koordinator.sh_disabled/docs/user-manuals/cpu-qos/)を参照してください。

Pod Annotationプロトコル `koordinator.sh_disabled/cpuQOS` を使用して、PodのCPU QoSポリシーを設定します。例：yaml
apiVersion: v1
kind: Pod
metadata: 
  annotations: 
    koordinator.sh_disabled/cpuQOS: {groupIdentity: 1}

ここに、ハイブリッドデプロイメント機能に貢献いただいたコミュニティ開発者の皆様、特に @kangclzjc、@j4ckstraw、@lijunxin559、@tan90github、@yangfeiyu20102011 に感謝申し上げます。

### 7. スケジューリングと再スケジューリング：運用効率の継続的な改善

クラウドネイティブ技術の進化に伴い、ますます多くの企業がコアビジネスをKubernetesプラットフォームに移行しており、クラスタ規模とタスク数が爆発的に増加しています。この傾向は、特にスケジューリング性能と再スケジューリングポリシーにおいて大きな技術的課題をもたらしています：
- スケジューリング性能の要件：クラスタ規模が拡大するにつれて、スケジューラーが処理する必要があるタスク数が急増し、スケジューラーの性能とスケーラビリティに対する要求が高まります。例えば、大規模なクラスタでは、Podのスケジューリング決定を迅速に行い、スケジューリングレイテンシを削減することが鍵となります。
- 再スケジューリングポリシーの要件：マルチテナント環境では、リソース競争が激化します。頻繁な再スケジューリングは、ワークロードが異なるノード間で繰り返し移動される原因となり、システムの負担が増え、クラスタの安定性に影響を与えます。また、生産タスクの安定稼働を確保しつつ、ホットスポット問題を回避するための合理的なリソース割り当て方法も、再スケジューリングポリシー設計における重要な考慮事項となっています。

これらの課題に対処するため、Koordinatorはv1.6.0でスケジューラーと再スケジューラーを全面的に最適化しました。これにより、スケジューリング性能と再スケジューリングポリシーの安定性と合理性を向上させることを目指しています。現在のバージョンでは、以下のスケジューラー性能の最適化を行っています：

- PodGroupのMinMemberチェックをPreEnqueueに前倒しし、不要なスケジューリングサイクルを削減。
- Reservationリソースの返却をAfterPreFilterフェーズに遅らせ、PreFilterResultで許可されたノードでのみリソースを復元することでアルゴリズムの複雑さを簡素化。
- NodeNUMAResource、DeviceShare、ReservationなどのプラグインのCycleState配布を最適化し、メモリオーバーヘッドを削減。
- BeforePreFilterやAfterPreFilterなど、Koordinatorの追加拡張ポイントにレイテンシメトリクスを追加。

クラ
現在、コミュニティでは以下の提案が計画されています：

- [Fine-grained device scheduling support Ascend NPU](https://github.com/koordinator-sh_disabled/koordinator/issues/2335)
- [Rescheduling to address the imbalance of different types of resources on a single node](https://github.com/koordinator-sh_disabled/koordinator/issues/2332)
- [PreAllocation: Reservation support binding to scheduled pods](https://github.com/koordinator-sh_disabled/koordinator/issues/2150)

主に解決すべき使用上の問題は以下の通りです：

- [NRI Plugin Conflict: Duplicate CPU Pinning Attempt Detected](https://github.com/koordinator-sh_disabled/koordinator/issues/2334)

長期的な提案は以下の通りです：

- [Provide an Evolvable End to End Solution for Koordinator Device Management](https://github.com/koordinator-sh_disabled/koordinator/issues/2181)

ユーザーからのフィードバックを歓迎し、より多くの開発者がKoordinatorプロジェクトに参加してその発展を促進することを期待しています！