Coordinator の 1 周年記念である新しいバージョン v1.2.0 は、ノードリソースの予約をサポートし、コミュニティの再スケジューリング戦略と互換性があります

著者: You Yi、Lu Feng

バックグラウンド

Koordinator は、Alibaba のコンテナスケジューリング分野での長年にわたる蓄積された経験に基づいて孵化し、生まれたオープンソースプロジェクトであり、コンテナのパフォーマンスを向上させ、クラスタリソースのコストを削減することができます。部門の混合、リソースのプロファイリング、スケジューリングの最適化などの技術的機能により、遅延の影響を受けやすいワークロードとバッチジョブの運用効率と信頼性を向上させ、クラスターリソースの使用効率を最適化できます。

ここに画像の説明を挿入

2022 年 4 月のリリース以来、コーディネーターはこれまでに 10 回のイテレーションをリリースし、Alibaba、Xiaomi、Xiaohongshu、iQiyi、360、Youzan などを含む多数の優れたエンジニアが貢献しています。2023 年の春に、コーディネーターも 1 周年を迎えました。コーディネーター v1.2 が正式にリリースされたことをお知らせいたします。新しいバージョンでは、Koordinator はノードリソースの予約機能をサポートし、K8s コミュニティの再スケジュール戦略と互換性があります.同時に、スタンドアロン側で AMD 環境の L3 キャッシュとメモリ帯域幅の分離のサポートを追加します.

新しいバージョンでは、合計 12 人の新しい開発者が Koordiantor コミュニティの構築に参加しました。彼らは@Re-Grh、@chengweiv5、@kingeasternsun、@shelwinnn、@yuexian1234、@Syulin7、@tzzcfrank、@Dengerwei、@complone です。、@AlbeeSo、@xigang、@leason00 は、上記の開発者の貢献と参加に感謝します。

新機能をいち早く知る

ノードリソースの予約

ハイブリッドシナリオにはさまざまな形式のアプリケーションが含まれます. クラウドネイティブコンテナーに加えて, まだコンテナー化されていない多くのアプリケーションもあります. これらのアプリケーションは、ホストマシン上のプロセスの形式で K8s コンテナーと一緒に実行されます. . K8s アプリケーションとノード側の他のタイプのアプリケーションとの間のリソース競合を減らすために、Coordinator はスケジューラーのリソーススケジューリングまたはノード側のリソース割り当てに参加しないように一部のリソースを予約することをサポートし、次の効果を達成します。リソースの分離。v1.2 バージョンでは、Koordiantor は既に CPU およびメモリリソースディメンションの予約をサポートしており、次のように予約済みの CPU 番号を直接指定できます。

ノードリソース予約ステートメント

予約するリソースの量または特定の CPU 数は、次のようにノードで構成できます。

apiVersion: v1
kind: Node
metadata:
  name: fake-node
  annotations: # specific 5 cores will be calculated, e.g. 0, 1, 2, 3, 4, and then those core will be reserved.
    node.koordinator.sh/reservation: '{"resources":{"cpu":"5"}}'
---
apiVersion: v1
kind: Node
metadata:
  name: fake-node
  annotations: # the cores 0, 1, 2, 3 will be reserved.
    node.koordinator.sh/reservation: '{"reservedCPUs":"0-3"}'

スタンドアロンコンポーネントの Koordlet がノードリソースのトポロジ情報を報告すると、特定の予約済み CPU 番号が NodeResourceTopology オブジェクトの Annotation に更新されます。

シーン適応のスケジューリングと再スケジューリング

リソースを割り当てるプロセスでは、スケジューラーは、クォータ管理、ノード容量の検証、CPU トポロジーの検証など、さまざまな状況でリソースの検証を行います。これらのシナリオでは、ノード予約リソースの考慮を増やす必要があります。たとえば、スケジューラーがノードの CPU キャパシティは、ノードによって予約されたリソースを差し引く必要があります。

cpus(alloc) = cpus(total) - cpus(allocated) - cpus(kubeletReserved) - cpus(nodeAnnoReserved)

さらに、バッチミックスで売られすぎたリソースの計算でも、この部分のリソースを差し引く必要があり、ノード内の一部のシステムプロセスのリソース消費を考慮して、Koord-Manager は計算中にノード予約とシステム使用量の最大値を取ります。、具体的には：

reserveRatio = (100-thresholdPercent) / 100.0
node.reserved = node.alloc * reserveRatio
system.used = max(node.used - pod.used, node.anno.reserved)
Node(BE).Alloc = Node.Alloc - Node.Reserved - System.Used - Pod(LS).Used

再スケジューリングの場合、各プラグイン戦略は、ノードの容量や使用率の計算などのシナリオでノードの予約リソースの量を認識する必要があります.さらに、ノードの予約リソースを占有しているコンテナーが既に存在する場合は、再スケジューリングを考慮する必要があります.ノード容量を確保するための追放リソースの競合を避けるために適切に管理する。今後のバージョンでこの部分のリスケジュール関連機能をサポートする予定ですので、ファンの皆様もぜひ共同構築にご参加ください。

スタンドアロンのリソース管理

LS タイプの Pod の場合、スタンドアロンの Koordlet コンポーネントは、CPU 割り当てに従って共有 CPU プールを動的に計算し、ノードによって予約された CPU コアは除外され、LS タイプの Pod およびその他のコンテナ化されていないものを確実に分離します。リソースを処理します。同時に、CPUSuppress 抑制ポリシーなどのスタンドアロン関連の QoS ポリシーについては、ノード使用率を計算するときに、予約されたリソースの量が考慮されます。

suppress(BE) := node.Total * SLOPercent - pod(LS).Used - max(system.Used, node.anno.reserved)

ノードリソース予約機能の詳細については、設計ドキュメントの概要を参照してください。https://github.com/koordinator-sh/koordinator/blob/main/docs/proposals/scheduling/20221227-ノードリソース -reservation.md

コミュニティのスケジュール変更ポリシーに準拠

Koordinator Descheduler のフレームワークの成熟度が高まっているおかげで、Koordinator v1.2 バージョンでは、インターフェイスの適応メカニズムを導入することで、Kubernetes Descheduler の既存のプラグインとシームレスに互換性を持つことができます。上流までのすべての機能が利用できます。

実装に関しては、Koordinator Descheduler はアップストリームコードをインポートすることによって侵入的な変更を行わず、すべてのアップストリームプラグイン、パラメーター構成、およびそれらの操作戦略との完全な互換性を保証します。同時に、コーディネーターを使用すると、ユーザーはアップストリームプラグインの強化されたエビクターを指定できるため、コーディネーターが提供するリソースの予約、ワークロードの可用性の保証、グローバルフロー制御などのセキュリティポリシーを再利用できます。

互換性のあるプラグインのリスト:

HighNodeUtilization
LowNodeUtilization
PodLifeTime
RemoveFailedPods
重複を削除
RemovePodsHavingTooManyRestarts
RemovePodsViolatingInterPodAntiAffinity
RemovePodsViolatingNodeAffinity
RemovePodsViolatingNodeTaints
RemovePodsViolatingTopologySpreadConstraint
デフォルトEvictor

これを使用する場合は、RemovePodsHavingTooManyRestarts を例として、次の構成を参照できます。

apiVersion: descheduler/v1alpha2
kind: DeschedulerConfiguration
clientConnection:
  kubeconfig: "/Users/joseph/asi/koord-2/admin.kubeconfig"
leaderElection:
  leaderElect: false
  resourceName: test-descheduler
  resourceNamespace: kube-system
deschedulingInterval: 10s
dryRun: true
profiles:
- name: koord-descheduler
  plugins:
    evict:
      enabled:
        - name: MigrationController
   deschedule:
     enabled:
       - name: RemovePodsHavingTooManyRestarts
  pluginConfig:
    - name: RemovePodsHavingTooManyRestarts
      args:
        apiVersion: descheduler/v1alpha2
        kind: RemovePodsHavingTooManyRestartsArgs
        podRestartThreshold: 10

強化されたリソース予約およびスケジューリング機能

Coordinator は、以前のバージョンで予約メカニズムを導入しました。これは、リソースを予約し、指定された特性を持つ Pod にそれらを再利用することで、リソース配信の決定論の問題を解決するのに役立ちます。たとえば、再スケジュールのシナリオでは、削除された後に利用可能なリソースがなく安定性の問題が発生するのではなく、削除される Pod に使用するリソースが必要であることが予想されます。または、容量の拡張が必要な場合、一部の PaaS プラットフォームは最初にアプリケーションのスケジューリングとオーケストレーションのリソースが満たされているかどうかを判断し、拡張するか、事前に準備作業を行うかを決定します。

Coordinator Reservation は CRD によって定義されます。各 Reservation オブジェクトは、スケジューリングのために koord-scheduler で Pod として偽装されます。このような Pod は、Reserve Pod と呼ばれます。Reserve Pod は、既存のスケジューリングプラグインとスコアリングプラグインを再利用して、適切なノードを見つけることができます。 . . 、最終的にスケジューラの内部状態で対応するリソースを占有します。予約が作成されると、予約されたリソースが将来使用されるポッドが指定されます. 特定のポッドを指定することも、いくつかのワークロードオブジェクトを指定することも、特定のラベルを持つポッドを指定することもできます. これらの Pod が koord-scheduler によってスケジュールされると、スケジューラーは Pod で使用できる Reservation オブジェクトを見つけ、最初に Reservation のリソースを使用します。また、予約ステータスにはどのポッドが使用されているかが記録され、ポッド注釈にもどの予約が使用されているかが記録されます。予約が使用された後、内部状態は自動的にクリーンアップされ、予約が原因で他のポッドがスケジュール不能にならないようにします。

Coordinator v1.2 では、多くの最適化を行いました。まず、Reservation が保持するリソースのみを使用できるという制限を解除し、Reservation のリソース境界を越えて、Reservation が予約したリソースを使用できるようにし、残りのリソースを使用できるようにします。ノードも使用できます。さらに、細粒度リソースの予約をサポートするために、非介入的な方法で Kubernetes スケジューラフレームワークを拡張しました。つまり、CPU コアと GPU デバイスを予約できます。また、Reservation を AllocateOnce に再利用できるというデフォルトの動作も変更しました。つまり、Reservation が Pod によって使用されると、Reservation は破棄されます。この変更は、AllocateOnce がほとんどのシナリオをより適切にカバーできるという考慮に基づいているため、既定の動作として、誰にとっても使いやすくなります。

AMD 環境で L3 キャッシュとメモリ帯域幅の分離をサポート

v0.3.0 バージョンでは、Koordiantor は Intel 環境の L3 キャッシュとメモリ帯域幅の分離を既にサポートしており、最新バージョン 1.2.0 では、AMD 環境のサポートを追加しました。

Linux カーネルの L3 キャッシュおよびメモリ帯域幅分離機能は、Intel と AMD の両方の環境をサポートする統合された resctrl インターフェイスを提供します. 主な違いは、Intel が提供するメモリ帯域幅分離インターフェイスはパーセンテージ形式であるのに対し、AMD が提供するメモリ帯域幅分離インターフェイスは.は絶対値形式で、詳細は次のとおりです。

# Intel Format
# resctrl schema
L3:0=3ff;1=3ff
MB:0=100;1=100

# AMD Format
# resctrl schema
L3:0=ffff;1=ffff;2=ffff;3=ffff;4=ffff;5=ffff;6=ffff;7=ffff;8=ffff;9=ffff;10=ffff;11=ffff;12=ffff;13=ffff;14=ffff;15=ffff
MB:0=2048;1=2048;2=2048;3=2048;4=2048;5=2048;6=2048;7=2048;8=2048;9=2048;10=2048;11=2048;12=2048;13=2048;14=2048;15=2048

インターフェイス形式は 2 つの部分で構成され、L3 は対応するソケットまたは CCD の使用可能な「方法」を 16 進数のデータ形式で表し、各ビットは 1 つの方法を表します; MB は対応するソケットまたは CCD が使用できるメモリを表します帯域幅範囲、Intel選択範囲は 0～100 パーセント形式、AMD は絶対値形式に対応、単位は Gb/s、2048 は無制限を意味します。Koordiantor はパーセンテージ形式のインターフェイスを一律に提供し、ノード環境が AMD であるかどうかを自動的に感知し、resctrl インターフェイスに入力される形式を決定します。

apiVersion: v1
kind: ConfigMap
metadata:
  name: slo-controller-config
  namespace: koordinator-system
data:
  resource-qos-config: |-
    {
      "clusterStrategy": {
        "lsClass": {
           "resctrlQOS": {
             "enable": true,
             "catRangeStartPercent": 0,
             "catRangeEndPercent": 100,
             "MBAPercent": 100
           }
         },
        "beClass": {
           "resctrlQOS": {
             "enable": true,
             "catRangeStartPercent": 0,
             "catRangeEndPercent": 30,
             "MBAPercent": 100
           }
         }
      }
    }

その他の機能

v1.2 リリース[ 1 ]ページでは、より多くのバージョンに含まれる新機能を確認できます。

これからの計画

次のバージョンでは、Koordiantor は次の機能に焦点を当てています。

ノード CPU、メモリ、GPU などの複数のリソース次元のトポロジー関係を包括的に考慮し、クラスター内でスケジューリングの最適化を実行する、ハードウェアトポロジーを考慮したスケジューリング。
リスケジューラのオブザーバビリティとトレーサビリティの機能強化。
GPU リソーススケジューリング機能の強化。

ここに画像の説明を挿入

Coordinator はオープンなコミュニティです. クラウドネイティブ愛好家は、さまざまな方法で共構築に参加することを大歓迎します. クラウドネイティブの分野の初心者または熟練者に関係なく、私たちはあなたの声を聞くことを非常に楽しみにしています! DingTalk 検索グループ番号: 33383887 を使用して、コーディネーターコミュニティの DingTalk グループに参加することもできます:

関連リンク：

[1] v1.2 リリース

https://github.com/koordinator-sh/koordinator/releases/tag/v1.2.0

Coordinator プロジェクトについて今すぐ知るには、ここをクリックしてください。