LoginSignup
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@alibabacloud-sa

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

Last updated at Posted at 2025-03-12

本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(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

上記のデバイスシナリオに対応して、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
  1. 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
  1. 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
  1. 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ではベストプラクティスを提供しており、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を使用してエンドツーエンドのテストをさらに実施するには、ベストプラクティスの例をステップバイステップで参照してください。この機能への貢献をしていただいたコミュニティ開発者の@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

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で有効にする手順については、以下を参照してください：

この機能への貢献をしていただいた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リソースの差別化されたスケジューリングポリシーの設計および使用方法に関する詳細情報は、次のリンクを参照してください：
        • 設計文書
        • ユーザーマニュアル
        コミュニティ開発者@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に基づいた動的リソース過剰コミットメントを提供します。ただし、過剰コミットメントされたリソースの安定性を確保するため、Midリソースはすべてノード上のスケジュールされたProd Podから取得されます。つまり、空のノードには最初はMidリソースが存在しません。このため、一部のワークロードがMidリソースを利用する際に不便が生じています。Koordinatorコミュニティは、いくつかの企業ユーザーからのフィードバックと貢献を受け取りました。! 6

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の有効化方法を参照してください。

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の追加拡張ポイントにレイテンシメトリクスを追加。

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

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

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

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?