特許 7502550 リソーススケジューリング方法、リソーススケジューリングシステム、及び機器

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-06-10

(45)【発行日】2024-06-18

(54)【発明の名称】リソーススケジューリング方法、リソーススケジューリングシステム、及び機器

(51)【国際特許分類】

   G06F 9/50 20060101AFI20240611BHJP

【ＦＩ】

G06F9/50 120Z

【請求項の数】 16

(21)【出願番号】P 2023500093

(86)(22)【出願日】2021-06-30

(65)【公表番号】

(43)【公表日】2023-07-27

(86)【国際出願番号】 CN2021103638

(87)【国際公開番号】W WO2022002148

(87)【国際公開日】2022-01-06

【審査請求日】2023-01-04

(31)【優先権主張番号】202010625668.0

(32)【優先日】2020-07-01

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】511151662

【氏名又は名称】中興通訊股▲ふん▼有限公司

【氏名又は名称原語表記】ＺＴＥ ＣＯＲＰＯＲＡＴＩＯＮ

【住所又は居所原語表記】ＺＴＥ Ｐｌａｚａ，Ｋｅｊｉ Ｒｏａｄ Ｓｏｕｔｈ，Ｈｉ－Ｔｅｃｈ Ｉｎｄｕｓｔｒｉａｌ Ｐａｒｋ，Ｎａｎｓｈａｎ Ｓｈｅｎｚｈｅｎ，Ｇｕａｎｇｄｏｎｇ ５１８０５７ Ｃｈｉｎａ

(74)【代理人】

【識別番号】100112656

【弁理士】

【氏名又は名称】宮田 英毅

(74)【代理人】

【識別番号】100089118

【弁理士】

【氏名又は名称】酒井 宏明

(74)【代理人】

【識別番号】110000914

【氏名又は名称】弁理士法人ＷｉｓｅＰｌｕｓ

(72)【発明者】

【氏名】張乗銘

(72)【発明者】

【氏名】唐波

(72)【発明者】

【氏名】王科文

(72)【発明者】

【氏名】韓炳涛

(72)【発明者】

【氏名】王永成

(72)【発明者】

【氏名】屠要峰

(72)【発明者】

【氏名】高洪

【審査官】田中 幸雄

(56)【参考文献】

【文献】特開２００７－２６４８８６（ＪＰ，Ａ）

【文献】米国特許出願公開第２０２１／０３７４１５６（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ９／５０

(57)【特許請求の範囲】

【請求項1】

コンピュータによって実行されるリソーススケジューリング方法であって、
スケジューリングキューからスケジューリング対象を取得するステップと、
前記スケジューリング対象がカスタムリソースである場合、現在のリソース状態及び前記カスタムリソースの要件情報に基づいて、スケジューリングユニットリストを得るステップであって、前記スケジューリングユニットリストは、前記カスタムリソースを構成するように構成される第１スケジューリングユニットを含み、前記カスタムリソースの要件情報には、分割ポリシーの情報及びリソース要件の情報が含まれるステップと、
前記スケジューリングユニットリスト中の前記第１スケジューリングユニットを順次スケジューリングするステップと、を含むリソーススケジューリング方法。

【請求項2】

現在のリソース状態及び前記カスタムリソースの要件情報とに基づいて、スケジューリングユニットリストを得る前記ステップは、
クラスタノードの残りのリソースが前記カスタムリソースの前記要求情報における前記リソース要件を満たす場合、現在のリソース状態と前記カスタムリソースの前記要求情報における前記分割ポリシーの情報に基づいて、前記スケジューリングユニットリストを得るステップを含む請求項１に記載のリソーススケジューリング方法。

【請求項3】

前記スケジューリング対象がネイティブスケジューリング基礎ユニットである第２スケジューリングユニットである場合、前記第２スケジューリングユニットを直接スケジューリングするステップをさらに含む請求項１に記載のリソーススケジューリング方法。

【請求項4】

全ての前記スケジューリング対象のスケジューリングが完了した後、前記第１スケジューリングユニット及び前記第２スケジューリングユニットをそれぞれ対応するノードにバインディングするステップをさらに含む請求項３に記載のリソーススケジューリング方法。

【請求項5】

全ての前記スケジューリング対象のスケジューリングが完了した後に、
ノードバインディング要求を開始させ、前記ノードの割当可能リソース情報を更新し、前記割当可能リソース情報に基づいて最適なノードを決定するステップをさらに含む請求項４に記載のリソーススケジューリング方法。

【請求項6】

スケジューリング要求に従ってスケジューリング対象を作成するステップと、
前記スケジューリング対象のバインディング情報をリスニングし、新しい前記スケジューリング対象を同一のキューに入れて前記スケジューリングキューを構成するステップと、をさらに含む請求項１に記載のリソーススケジューリング方法。

【請求項7】

第１スケジューリングユニットのいずれかがスケジューリングに失敗した場合、既にスケジューリングされている前記第１スケジューリングユニットを削除し、リソースを解放するステップをさらに含む請求項１に記載のリソーススケジューリング方法。

【請求項8】

スケジューリングキューからスケジューリング対象を取得するように構成されるスケジューラと、
前記スケジューリング対象がカスタムリソースである場合、現在のリソース状態及び前記カスタムリソースの要件情報に基づいて、スケジューリングユニットリストを得るスプリッタであって、前記スケジューリングユニットリストは、前記カスタムリソースを構成するように構成される第１スケジューリングユニットを含み、前記カスタムリソースの要件情報には、分割ポリシーの情報及びリソース要件の情報が含まれる前記スプリッタと、を含み、
前記スケジューラは、前記スケジューリングユニットリスト中の前記第１スケジューリングユニットを順次スケジューリングするリソーススケジューリングシステム。

【請求項9】

前記スプリッタは、さらに、
クラスタノードの残りのリソースが前記カスタムリソースの前記要求情報における前記リソース要件を満たす場合、現在のリソース状態と前記カスタムリソースの前記要求情報における前記分割ポリシーの情報に基づいて、前記スケジューリングユニットリストを得るように構成される請求項８に記載のリソーススケジューリングシステム。

【請求項10】

前記スケジューラは、さらに、
前記スケジューリング対象がネイティブスケジューリング基礎ユニットである第２スケジューリングユニットである場合、前記第２スケジューリングユニットを直接スケジューリングするように構成される請求項８に記載のリソーススケジューリングシステム。

【請求項11】

前記スプリッタは、さらに、
前記第１スケジューリングユニット及び第２スケジューリングユニットをそれぞれ対応するノードにバインディングするように構成される請求項１０に記載のリソーススケジューリングシステム。

【請求項12】

前記スケジューラは、さらに、
バインディング要求を開始させ、前記ノードの割当可能リソース情報を更新し、前記割当可能リソース情報に基づいて最適なノードを決定するように構成される請求項１１に記載のリソーススケジューリングシステム。

【請求項13】

前記スケジューラは、さらに、
前記スケジューリング対象のスケジューリング要求を取得し、
前記スケジューリング対象のバインディング情報をリスニングし、新しい前記スケジューリング対象を同一のキューに入れて前記スケジューリングキューを構成するように構成される請求項８に記載のリソーススケジューリングシステム。

【請求項14】

前記スケジューラは、さらに、
前記第１スケジューリングユニットのいずれかがスケジューリングに失敗した場合、既にスケジューリングされている前記第１スケジューリングユニットを削除し、リソースを解放するように構成される請求項８に記載のリソーススケジューリングシステム。

【請求項15】

メモリと、プロセッサと、メモリ上に記憶され、プロセッサ上で運転可能なコンピュータプログラムと、を含み、前記プロセッサは前記コンピュータプログラムを実行すると、請求項１～７のいずれか１項に記載のリソーススケジューリング方法を実現する機器。

【請求項16】

請求項１～７のいずれか１項に記載のリソーススケジューリング方法を実行するためのコンピュータ実行可能命令を記憶したコンピュータ読み取り可能な記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本願は、出願番号が２０２０１０６２５６６８．０、出願日が２０２０年７月１日の中国特許出願に基づいて提出され、当該中国特許出願の優先権を主張しており、当該中国特許出願の全ての内容はここで参照として本願に組み込まれている。

【0002】

本願は、コンピュータの技術分野に関し、特に、リソーススケジューリング方法、リソーススケジューリングシステム、機器、及びコンピュータ読み取り可能な記憶媒体に関する。

【背景技術】

【0003】

Ｋｕｂｅｒｎｅｔｅｓは現在最も主流のコンテナ・オーケストレーション、スケジューリングプラットフォームであり、良好な拡張性を通じてユーザのカスタムリソース（ＣＲＤ：Ｃｕｓｔｏｍ Ｒｅｓｏｕｒｃｅ Ｄｅｆｉｎｉｔｉｏｎｓ）の管理をサポートし、ユーザがカスタムリソースを１つの全体的な対象エンティティとして管理するのに有利である。しかし、現在、ＫｕｂｅｒｎｅｔｅｓはＰｏｄのスケジューリングのみをサポートし、ＣＲＤをスケジューリングするには専用のスケジューラが必要とされ、複数のスケジューラの間でリソーススケジューリングの矛盾の問題が発生し、また、次のような問題も発生する。リソースがＣＲＤのリソース要求を満たすことができず、結果としてＣＲＤがスケジューリングされず、ＣＲＤは正常にスケジューリングできたとしても、最適なリソース割り当てでスケジューリングされていないため、運転効率が低下する。

【発明の概要】

【発明が解決しようとする課題】

【0004】

以下は本明細書で詳細に説明される主題の概要である。本概要は、特許請求の範囲の保護範囲を限定するものではない。

【0005】

本願は、リソーススケジューリング方法、リソーススケジューリングシステム、機器、及びコンピュータ読み取り可能な記憶媒体を提案する。

【課題を解決するための手段】

【0006】

第１態様では、本願の実施例によるリソーススケジューリング方法は、
スケジューリングキューからスケジューリング対象を取得するステップと、
前記スケジューリング対象がカスタムリソースである場合、現在のリソース状態に応じて前記カスタムリソースを分解して、前記カスタムリソースを構成するように構成されるスケジューリングユニットを含むスケジューリングユニットリストを得るステップと、
前記スケジューリングユニットリスト中の前記スケジューリングユニットを順次スケジューリングするステップと、を含む。

【0007】

第２態様では、本願の実施例によるリソーススケジューリングシステムは、
スケジューリングキューからスケジューリング対象を取得するように構成されるスケジューラと、
前記スケジューリング対象がカスタムリソースである場合、現在のリソース状態に応じて前記カスタムリソースを分解して、前記カスタムリソースを構成するように構成されるスケジューリングユニットを含むスケジューリングユニットリストを得るように構成されるスプリッタと、を含み、
前記スケジューラは、前記スケジューリングユニットリスト中の前記スケジューリングユニットを順次スケジューリングする。

【0008】

第３態様では、本明細書の実施例による機器は、
メモリと、プロセッサと、メモリ上に記憶され、プロセッサ上で運転可能なコンピュータプログラムと、を含み、前記プロセッサは、前記コンピュータプログラムを実行すると、上記第１態様の実施例のリソーススケジューリング方法を実現する。

【0009】

第４態様では、本願の実施例によるコンピュータ読み取り可能な記憶媒体は、
上記した第１態様の実施例のリソーススケジューリング方法を実行するためのコンピュータ実行可能命令を記憶している。

【0010】

本願の他の特徴及び利点は、後の明細書で説明され、本明細書から部分的に明らかになるか、又は本明細書を実施することによって理解される。本願の目的及び他の利点は、明細書、特許請求の範囲、及び図面において特に指摘された構造によって達成され得る。
図面は、本願の技術案の更なる理解を提供するために使用され、明細書の一部を構成し、本願の実施例と共に本願の技術案を説明するために使用され、本願の技術案を限定するものではない。

【図面の簡単な説明】

【0011】

【図1】本願の一実施例によるシステムアーキテクチャプラットフォームの概略図である。

【図2】本願の一実施例によるリソーススケジューリング方法のフローチャートである。

【図3】本願の他の実施例によるリソーススケジューリング方法のフローチャートである。

【図4】本願の他の実施例によるリソーススケジューリング方法のフローチャートである。

【図5】本願の他の実施例によるリソーススケジューリング方法のフローチャートである。

【図6】本願の他の実施例によるリソーススケジューリング方法のフローチャートである。

【図7】本願の他の実施例によるリソーススケジューリング方法のフローチャートである。

【図8】本願の他の実施例によるリソーススケジューリング方法のフローチャートである。

【図9】本願の他の実施例によるリソーススケジューリング方法のフローチャートである。

【図10】本願の他の実施例によるリソーススケジューリング方法のフローチャートである。

【図11】本願の他の実施例によるリソーススケジューリング方法のフローチャートである。

【発明を実施するための形態】

【0012】

本願の目的、技術案及び利点をより明確にするために、以下では、図面及び実施例を参照して、本願をさらに詳細に説明する。なお、ここで説明される具体的な実施例は、本願を説明するためにのみ使用され、本願を限定するものではない。

【0013】

なお、機能モジュール分割は装置の概略図に示され、論理的順序はフローチャートに示されているが、示された又は説明されたステップは、場合によっては、装置のモジュール分割又はフローチャートに示された順序とは異なるもので実行されてもよい。明細書、特許請求の範囲、又は上記の図面における用語「第１」、「第２」などは、特定の順序又は優先順位を説明するために使用されるのではなく、類似の対象を区別するために使用される。

【0014】

Ｋｕｂｅｒｎｅｔｅｓは、クラウドプラットフォームの複数のホスト上でコンテナ化されたアプリケーションを管理するためのオープンソースのものであり、コンテナ化されたアプリケーションのデプロイメントを簡単かつ効率的にすることを目指しており、アプリケーションのデプロイメント、計画、更新、保守の仕組みを提供している。Ｋｕｂｅｒｎｅｔｅｓでは、複数のコンテナを作成し、各コンテナで１つのアプリケーションインスタンスを運転し、そして、組み込まれた負荷分散ポリシーを使用して、このアプリケーションインスタンスグループの管理、発見、アクセスを行うが、これらの詳細は、運用管理者が複雑な手作業の設定と処理を行う必要がない。Ｋｕｂｅｒｎｅｔｅｓは適用が広く、多くの企業や研究機関のクラウドコンピューティング、人工知能などのプラットフォームはＫｕｂｅｒｎｅｔｅｓに基づいて実現されている。Ｋｕｂｅｒｎｅｔｅｓは、良好な拡張性によって、ユーザのカスタムリソース（ＣＲＤ：Ｃｕｓｔｏｍ Ｒｅｓｏｕｒｃｅ Ｄｅｆｉｎｉｔｉｏｎｓ）の管理をサポートし、ユーザがカスタムリソースを１つの全体的な対象エンティティとして管理することに有利である。

【0015】

しかし、現在、ＫｕｂｅｒｎｅｔｅｓはＰｏｄのスケジューリングのみをサポートし、ＰｏｄはＫｕｂｅｒｎｅｔｅｓで作成及びデプロイメントが可能な最小ユニットであり、Ｋｕｂｅｒｎｅｔｅｓクラスタ内の１つのアプリケーションインスタンスであり、常に同じノード上にデプロイされ、Ｐｏｄには１つ又は複数のコンテナが含まれており、ストレージやネットワークなどの各コンテナが共有するリソースも含まれている。ＫｕｂｅｒｎｅｔｅｓはＣＲＤをスケジューリングするには専用のスケジューラが必要とされ、複数のスケジューラの間でリソーススケジューリングの矛盾が発生する可能性がある。

【0016】

ＫｕｂｅｒｎｅｔｅｓデフォルトスケジューラはＰｏｄのスケジューリングのみをサポートし、ＣＲＤ対象のスケジューリングをサポートしておらず、Ｋｕｂｅｒｎｅｔｅｓデフォルトスケジューラは、現在のリソース状態に応じてＣＲＤ対象をＰｏｄに自動的かつ合理的に分解することはできない。本願は、リソーススケジューリング方法、リソーススケジューリングシステム、機器、及びコンピュータ読み取り可能な記憶媒体を提供し、リソースをスケジューリングする際に、スケジューリングキューからスケジューリング対象を取得し、スケジューリング対象がカスタムリソースである場合、現在のリソース状態に応じてカスタムリソースを分解して、カスタムリソースを構成するように構成される第１スケジューリングユニットを含むスケジューリングユニットリストを得て、次に、スケジューリングユニットリストに従って各第１スケジューリングユニットを順次スケジューリングする。このリソーススケジューリング方法は、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームに適用することができ、第１スケジューリングユニットはＣＲＤ対象であり、スケジューリングする際にスケジューリング対象がＣＲＤである場合、現在のリソース状態に応じてＣＲＤを分解して、Ｐｏｄ集合を含むスケジューリングユニットリストを得て、このように、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームがスケジューリングユニットリストに従ってＰｏｄをアトミックにスケジューリングすることができ、全てのＰｏｄがキューに従って順次スケジューリングされ、他のＰｏｄが挿入されることを回避し、このようにＣＲＤが合理的にスケジューリングされ、スケジューリング効率が高く、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームが様々な業務シナリオに適合することを確保する。

【0017】

以下、図面を参照して、本願の技術案を明確かつ完全に説明するが、以下に説明される実施例は本願の実施例の一部であり、実施例の全てではないことは明らかである。

【0018】

図１に示すように、図１は、本願の一実施例によるリソーススケジューリング方法を実行するためのシステムアーキテクチャプラットフォーム１００の概略図であり、このシステムアーキテクチャプラットフォーム１００はリソーススケジューリングシステムである。

【0019】

図１に示す実施例では、システムアーキテクチャプラットフォーム１００は、スケジューリング対象をスケジューリングするように構成されるスケジューラ１１０と、スケジューラ１１０の分解要求に応答して、スケジューラ１１０のスケジューリング要件を満たすようにスケジューリング対象を分解するスプリッタ１２０と、を含む。具体的には、スケジューリングする際には、スケジューラ１１０は、スケジューリングキューからスケジューリング対象を取得し、スケジューリング対象がカスタムリソースである場合、スプリッタ１２０は、現在のリソース状態に応じてカスタムリソースを分解して、カスタムリソースを構成するように構成される第１スケジューリングユニットを含むスケジューリングユニットリストを得る。スケジューラ１１０は、スケジューリングユニットリストに従って、スケジューリングユニットリスト中の第１スケジューリングユニットを順次スケジューリングすることにより、カスタムリソースのスケジューリングを完了する。

【0020】

図１に示すように、具体的には、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームを例に説明する。

【0021】

実施例のＫｕｂｅｒｎｅｔｅｓスケジューリングシステムは、スケジューラ（Ｓｃｈｅｄｕｌｅｒ）１１０と、スプリッタ（Ｐｏｄ－Ｓｐｌｉｔｏｒ）１２０と、コントローラ（ＣＲＤ－Ｃｏｎｔｒｏｌｌｅｒ）１３０と、を含む。

【0022】

ここで、スケジューラ１１０はＰｏｄのスケジューリングを担当し、スプリッタはＣＲＤ対象のスプリットを担当し、第１スケジューリングユニットはＣＲＤ対象であり、第２スケジューリングユニットはネイティブＰｏｄ対象である。本実施例では、ＣＲＤとＰｏｄが同一のスケジューリングキューに入れられ、スケジューリング対象がＣＲＤである場合、スケジューラ１１０は拡張されたスプリット（Ｓｐｌｉｔ）インタフェースにより分解されたＰｏｄ集合を得て、全てのＰｏｄはスケジューラ１１０により順次スケジューリングされる。

【0023】

スプリッタ１２０はユーザによってカスタマイズされた拡張コンポーネントであり、主としてスケジューラ１１０の分解要求に応答して、現在のクラスタリソース占有状況に応じてＣＲＤを合理的なＰｏｄにスプリットし、これらのＰｏｄを含むスケジューリングユニットリストを作成し、スケジューリングのためにスケジューリングユニットリストをスケジューラ１１０に返すことを担当し、また、スプリッタ１２０は、スケジューラ１１０のノードバインディング要求に応答して、Ｐｏｄとノード（Ｎｏｄｅ）とのバインディング操作を行うこともできる。ここで、Ｐｏｄとノードとのバインディングは、Ｐｏｄという対象にノードの情報、リソース情報を新たに追加するものとして理解してもよく、次に、スケジューリングシステムの専用コンポーネントは、これらのバインディング情報に基づいて対応するノード上でＰｏｄを運転させる。

【0024】

コントローラ１３０は、ユーザによってカスタマイズされた拡張コンポーネントであり、特定のＣＲＤの状態、ライフサイクルの管理に用いられる。ＣＲＤと対応するＰｏｄの状態に応じてＣＲＤ状態を更新し、ユーザコマンド又はＣＲＤ自体のポリシーによれば、例えばＰｏｄが正常に終了すると、ＣＲＤライフサイクルが終了し、このようにして、ＣＲＤライフサイクルを維持する。コントローラ１３０は、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームが有する機能コンポーネントであり、ここでは詳しく説明しない。

【0025】

また、ユーザはＡｐｉ－Ｓｅｒｖｅｒ１４０を介してＣＲＤ、Ｐｏｄ対象を作成し、スケジューラ１１０はＡｐｉ－Ｓｅｒｖｅｒを介してＣＲＤ、Ｐｏｄ対象のバインディング情報をリスニングし、全てのＰｏｄのスケジューリングが完了した後、スプリッタ１２０はＡｐｉ－Ｓｅｒｖｅｒを介してＰｏｄとノードとをバインディングする。

【0026】

また、スケジューラ１１０には、現在、エクステンダ（Ｅｘｔｅｎｄｅｒ）とスケジューリングフレームワーク（Ｓｃｈｅｄｕｌｉｎｇ Ｆｒａｍｅｗｏｒｋ）の２つの拡張方式があるが、従来の拡張インタフェースに新たにＳｐｌｉｔインタフェースを追加し、スケジューラ１１０がＣＲＤをスケジューリングする際に、このＳｐｌｉｔインタフェースを介してＣＲＤを分解したＰｏｄ集合を取得する。ここで、エクステンダは、ｗｅｂ ｈｏｏｋ方式でスケジューラ１１０を拡張させ、スケジューリングフレームワークは、拡張インタフェースをスケジューラ１１０に直接コンパイルする。ＣＲＤリソースを合理的に分割するために、本願の実施例では、ＣＲＤリソース対象を分割してＣＲＤをＰｏｄ集合に変換するように構成される新しい拡張インタフェース、すなわちＳｐｌｉｔインタフェースが導入される。ＣＲＤリソースが異なると、分割方式が異なる可能性があり、具体的なＳｐｌｉｔインタフェースはＥｘｔｅｎｄｅｒ又はＳｃｈｅｄｕｌｉｎｇ Ｆｒａｍｅｗｏｒｋで実現され、主に２つの作業、すなわち、ある戦略を採用してこのＣＲＤを１～Ｎ個のＰｏｄの集合に分割し、各Ｐｏｄに具体的なリソース数を割り当てることと、分割の過程で、クラスタノードの残りのリソース例えばＧＰＵ、ＣＰＵリソースなどが分割の要件を満たすことができるか否かを判断し、満たさない場合、スケジューラ１１０に対してエラー情報を返し、全て満たす場合、分割したＰｏｄ集合を返すことを担当する。

【0027】

スケジューリングシステムは、スケジューリングする際には、スケジューリング対象がＣＲＤである場合、現在のリソース状態に応じてＣＲＤを分解して、Ｐｏｄ集合を含むスケジューリングユニットリストを得て、このようにして、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームはスケジューリングユニットリストに従ってＰｏｄをスケジューリングすることができ、全てのＰｏｄがキューに従って順次スケジューリングされ、他のＰｏｄが挿入されることを回避し、このようにＣＲＤが合理的にスケジューリングされ、スケジューリング効率が高く、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームが様々な業務シナリオに適合することを確保する。

【0028】

なお、スケジューリング対象がＰｏｄである場合、元のＫｕｂｅｒｎｅｔｅｓスケジューリングシステムのスケジューリングの流れに従って処理を行うが、Ｐｏｄのバインディング操作はスプリッタ１２０によって行われ、スケジューリング対象がＣＲＤである場合、スプリッタ１２０は、現在のクラスタのリソース状態に応じて、Ｐｏｄを分解し、ＣＲＤを１つ又は複数のＰｏｄに分解し、スプリッタ１２０は、ＣＲＤを分解するＰｏｄの数、及びＰｏｄによって使用されるリソース（ＣＰＵ、メモリ、ＧＰＵ）を決定するだけでよく、これらのＰｏｄのスケジューリングは、スプリッタ１２０によってＣＲＤの分解が完了した後にスケジューラ１１０によって行われ、スケジューラ１１０は、ノードに対してフィルタリング、優先順位付け、スコア付けなどの最適化アルゴリズムを実行して、Ｐｏｄのために適切なノードを選択し、それによって、Ｐｏｄリスト中のＰｏｄをスプリッタ１２０によってノードにバインディングし、スケジューラ１１０とスプリッタ１２０のリソースの同期化を確保することができる。

【0029】

このようにして、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームのスケジューラ１１０は、ＣＲＤとＰｏｄのコスケジューリング、及び単一ＣＲＤのＰｏｄアトミックスケジューリングをサポートすることができる。理解できるものとして、ＣＲＤとＰｏｄのコスケジューリングの場合、スケジューラ１１０は構成を読み取り、どのＣＲＤがスケジューリングに関与しているかを把握し、Ｐｏｄ及びスケジューリングを必要とするＣＲＤを同一のスケジューリングキューに入れ、スケジューラ１１０がスケジューリングする対象がＣＲＤである場合、拡張されたＳｐｌｉｔインタフェースを介してＣＲＤ対象を分解したＰｏｄ対象リストを取得し、各Ｐｏｄを順次スケジューリングすることにより、ＣＲＤとＰｏｄのコスケジューリングが実現される。

【0030】

ＣＲＤのＰｏｄアトミックスケジューリングとしては、ＣＲＤによって分解されたＰｏｄ集合をスケジューリングする際に、他のＰｏｄをスケジューリングすることができず、ＣＲＤを分解したＰｏｄ集合が全てスケジューリングに成功した場合成功し、そうでない場合失敗するものとして理解してもよい。このようにして、残りのリソースの不足によってスケジューリングができず、ＣＲＤ全体のスケジューリングが失敗することを回避することができる。

【0031】

なお、ＣＲＤスケジューリングにはバックオフ（ＢａｃｋＯｆｆ）機構があり、このＢａｃｋＯｆｆ機構は、ＣＲＤのＰｏｄのうちいずれかのＰｏｄのスケジューリングが失敗すると、ＣＲＤ全体のスケジューリングが失敗したと見なされる。ＣＲＤのスケジューリングに失敗した場合、そのＣＲＤですでにスケジューリングに成功したＰｏｄについては、削除されてリソースを解放する必要がある。また、ＣＲＤを分解したＰｏｄはリエントラント保護機能を有しており、スケジューラ１１０のスケジューリングキューにはＣＲＤ対象とＰｏｄ対象が記憶されており、ＣＲＤ対象に属するＰｏｄ集合をスケジューリングキューに再挿入する必要はない。

【0032】

なお、スケジューラ１１０とスプリッタ１２０はリソース同期機構を有し、スプリッタ１２０がＣＲＤを合理的かつ最適に分解するためには、クラスタのリソース状態を明確にし、ノード及びＰｏｄ情報をリスニングし、ローカルに割当可能リソース情報をキャッシュする必要がある。ＣＲＤのＰｏｄ集合がスケジューラ１１０によるスケジューリングに成功した後、スケジューラ１１０は、Ｐｏｄのバインディング（Ｂｉｎｄ）要求をスプリッタ１２０に送信し、スプリッタ１２０は、バインディング要求を受信すると、スプリッタ１２０のローカルにキャッシュされたノード割当可能リソース情報を更新してから、最終的なバインディング要求をＡｐｉ－Ｓｅｒｖｅｒ１４０に送信し、これによって、リソースの同期化を達成する。

【0033】

本願の実施例に記載されたシステムアーキテクチャプラットフォーム１００及び適用シナリオは、本願の実施例の技術案をより明確に説明するためのものであり、本願の実施例による技術案を限定するものではなく、当業者に周知のように、システムアーキテクチャプラットフォーム１００の進化と新しい適用シナリオの出現に伴い、本願の実施例による技術案は類似の技術的課題に対しても同様に適用される。

【0034】

当業者が理解できるように、図１に示すシステムアーキテクチャプラットフォーム１００は本願の実施例を限定するものではなく、図示よりも多い又は少ない部材を含んだり、いくつかの部材を組み合わせたり、異なる部材の配置を取ったりしてもよい。

【0035】

上記したシステムアーキテクチャプラットフォーム１００に基づいて、以下、本願のリソーススケジューリング方法の様々な実施例を示す。

【0036】

図２に示すように、図２は、本願の一実施例によるリソーススケジューリング方法のフローチャートであり、このリソーススケジューリング方法は、ステップＳ１００、ステップＳ２００、及びステップＳ３００を含むが、これらに限定されない。

【0037】

ステップＳ１００：スケジューリングキューからスケジューリング対象を取得する。

【0038】

一実施例では、リソーススケジューリングとは、様々なリソースを合理的かつ効率的に利用するものとして理解してもよい。理解できるものとして、スケジューリングする対象はリソース対象であり、スケジューリング可能な対象はキューの形態で並べられ、スケジューリングする際にはキューの順序や優先度に応じて呼び出すことによりスケジューリング対象が得られ、これにより、スケジューリング対象の迅速な取得が容易になり、リソースの合理的なスケジューリングにも役立つ。

【0039】

Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームを例に挙げて説明し、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームでは、Ｐｏｄ、Ｄｅｐｌｏｙｍｅｎｔ、Ｓｅｒｖｉｃｅ、Ｖｏｌｕｍｅなど、多くのデフォルトのリソースタイプが用意されており、これらのリソースは、日常的なシステムのデプロイメントや管理のほとんどのニーズに対応することができる。しかし、これらの既存のリソースタイプでは満たされない特殊なニーズがある場合は、ＣＲＤによってこれらのニーズを満たすことができ、このように、Ｋｕｂｅｒｎｅｔｅｓの拡張能力が効果的に向上する。

【0040】

なお、ＫｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームはＰｏｄのスケジューリングをサポートしており、すなわち、Ｐｏｄを直接スケジューリングすることができる。理解できるものとして、ＣＲＤとＰｏｄ対象の両方を同一のスケジューリングキューに挿入することも、ＣＲＤを個別にスケジューリングすることも可能である。具体的には、ＣＲＤとＰｏｄのコスケジューリングの場合、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームのスケジューラは構成を読み取り、スケジューリングに関与可能なＣＲＤ対象とＰｏｄ対象を取得し、Ｐｏｄ及びスケジューリングを必要とするＣＲＤを同一のスケジューリングキューに入れ、スケジューリングキューからスケジューリング対象を順次取得してスケジューリングを行う。

【0041】

ステップＳ２００：スケジューリング対象がカスタムリソースである場合、現在のリソース状態に応じてカスタムリソースを分解して、スケジューリングユニットリストを得る。

【0042】

ここで、スケジューリングユニットリストはカスタムリソースを構成するように構成される第１スケジューリングユニットを含み、このカスタムリソースはＣＲＤであり、この第１スケジューリングユニットはＣＲＤ対象であり、理解できるものとして、ＣＲＤ対象とネイティブＰｏｄ対象は同一のスケジューリングキューに同時に挿入されることができ、すなわち、ＣＲＤ対象とＰｏｄ対象のコスケジューリングが可能であり、ＣＲＤとＰｏｄのコスケジューリングの場合、スケジューラはスケジューリングキューからスケジューリング対象を順次取得する。スケジューラはスケジューリングする際に、まずスケジューリング対象のタイプを判断し、スケジューリング対象がＣＲＤである場合、現在のリソース状態に応じてＣＲＤを分解して、ＣＲＤを構成するＰｏｄのリストであるスケジューリングユニットリストを得て、すなわちＣＲＤはＰｏｄの集合に分割され、このようにして、ＫｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームはＰｏｄリストに従ってＰｏｄを直接スケジューリングできる。

【0043】

理解できるものとして、現在のスケジューリングプラットフォームの残りのリソース又は利用可能なリソースとして理解され得る現在のリソース状態に応じてＣＲＤを分解する必要がある。ＣＲＤを分解するためのリソース要求を満たす場合、スプリッタによりＣＲＤ対象を合理的に分割し、最適なリソース割り当てでＣＲＤをスケジューリングすることを可能にし、運転効率をより高める。

【0044】

なお、スケジューリング対象がネイティブＰｏｄである場合、分解することなくＰｏｄを直接スケジューリングすることができる。理解できるものとして、Ｐｏｄはｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームの基礎ユニットであり、ユーザが作成又はデプロイする最小コンポーネントであり、コンテナ化されたアプリケーションを運転するリソース対象でもある。Ｋｕｂｅｒｎｅｔｅｓクラスタ内の他のリソース対象は、Ｐｏｄというリソース対象をサポートして、ｋｕｂｅｒｎｅｔｅｓがアプリケーションサービスを管理する目的を実現するものである。このように、ＫｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームはＰｏｄとＣＲＤのコスケジューリングをサポートしながら、単一ＣＲＤのＰｏｄのアトミックスケジューリングを実現し、ＣＲＤが合理的にスケジューリングされ、様々な業務シナリオに適合できることも確保される。

【0045】

ステップＳ３００：スケジューリングユニットリスト中のスケジューリングユニットを順次スケジューリングする。

【0046】

一実施例では、分解が完了すると、スケジューリングユニットリストが生成され、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームにおいては、このスケジューリングユニットはＰｏｄであり、スケジューリングユニットリストはＰｏｄ集合リストであり、スケジューラは、Ｐｏｄ集合リストに従って、このＰｏｄ集合リスト中の全てのＰｏｄを順次スケジューリングすることにより、単一のＣＲＤのスケジューリングを行う。理解できるものとして、全てのＰｏｄをリストの形態で順次にスケジューリングすることは、他のＰｏｄの挿入によってリスト中の残りのＰｏｄが残りのリソース不足のためにスケジューリングされず、ＣＲＤ全体のスケジューリングが失敗することを回避することができ、また、あるＣＲＤのＰｏｄの一部をスケジューリングするときに、別のＣＲＤのＰｏｄの一部を挿入してしまうと、この２つのＣＲＤの残りのＰｏｄが残りのリソースの不足のためにスケジューリングされず、すでに占有しているリソースが解放されず、２つのＣＲＤがリソースのデッドロック状態になってしまうという問題も回避できる。

【0047】

一実施例では、現在のリソース状態に応じてカスタムリソースを分解して、スケジューリングユニットリストを得るステップＳ２００は、ステップＳ２１０を含んでもよいが、これに限定されない。

【0048】

ステップＳ２１０：クラスタノードの残りのリソースがカスタムリソースを分解する要件を満たす場合、カスタムリソースを分解してスケジューリングユニットリストを得る。

【0049】

一実施例では、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームにおいては、スプリッタは、主にスケジューラの分解要求に応答して、現在のクラスタノードのリソース占有状況に応じてＣＲＤを合理的なＰｏｄに分解し、これらのＰｏｄを含むスケジューリングユニットリストを作成し、スケジューリングのためにスケジューリングユニットリストをスケジューラに返すことを担当する。スプリッタはクラスタノードのリソース状態を把握することができ、例えばクラスタノードのバインディング状態をリスニングすることによってリソース状態を取得し、そのリソース状態に応じてＣＲＤを合理的に分解し、最適なＣＲＤ分解要件を満たすことができる。

【0050】

これにより、スプリッタはリソース状態を十分に考慮した上でＣＲＤを効率的かつ合理的に分解し、またスケジューラはＣＲＤを理解する必要がなく、Ｐｏｄのスケジューリングに集中し、これにより、ＣＲＤの分割とスケジューリングが実現される。

【0051】

なお、ＣＲＤを分解したＰｏｄはリエントラント保護機能を有しており、スケジューラのスケジューリングキューにはＣＲＤ対象とＰｏｄ対象が記憶されており、ＣＲＤ対象に属するＰｏｄ集合をスケジューリングキューに挿入する必要はない。

【0052】

図３に示すように、一実施例では、リソーススケジューリング方法は、ステップＳ１０１とステップＳ１０２をさらに含むが、これらに限定されない。

【0053】

ステップＳ１０１：スケジューリング要求に従ってスケジューリング対象を作成する。

【0054】

ステップＳ１０２：スケジューリング対象のバインディング情報をリスニングし、新しいスケジューリング対象を同一のキューに入れてスケジューリングキューを構成する。

【0055】

理解できるものとして、ユーザは、ＣＲＤを深層学習する必要があるなど、適用シナリオの実際のニーズに合わせてＣＲＤ対象とＰｏｄ対象を作成する。ユーザはＡｐｉ－Ｓｅｒｖｅｒを介してＣＲＤ対象とＰｏｄ対象を作成し、スケジューラはＡｐｉ－Ｓｅｒｖｅｒを介してＣＲＤ対象とＰｏｄ対象のバインディング情報をリスニングし、スケジューリング可能なＣＲＤとＰｏｄを同一のキューに入れる。ＣＲＤ及びＰｏｄをキューに入れてスケジューリングキューを構成し、その後、スケジューリングキューからスケジューリング対象を取得し、追加されたスケジューリング対象は、ＣＲＤとＰｏｄ、又は全てＣＲＤ若しくは全てＰｏｄであってもよい。

【0056】

図４に示すように、一実施例では、リソーススケジューリング方法は、ステップＳ４００をさらに含むが、これらに限定されない。

【0057】

ステップＳ４００：全てのスケジューリング対象のスケジューリングが完了した後、スケジューリングユニットを対応するノードにバインディングする。

【0058】

一実施例では、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームは、ＣＲＤ対象をスケジューリングする際に、ＣＲＤを合理的に分解し、スケジューリングのためにスケジューリングユニットリストをスケジューラに返し、スケジューラは、Ｐｏｄのスケジューリングに集中するだけで、全てのスケジューリング対象のスケジューリングを行うことができる。スケジューラは、全てのスケジューリング対象をスケジューリングした後、ノードバインディング要求をスプリッタに送信し、スプリッタはスケジューラのノードバインディング要求に応答してＰｏｄとノードとのバインディング操作を行う。具体的には、スプリッタはＡｐｉ－Ｓｅｒｖｅｒを介してＰｏｄとノードとのバインディングを行う。

【0059】

一実施例では、リソーススケジューリング方法は、ステップＳ５００をさらに含むが、これに限定されない。

【0060】

ステップＳ５００：スケジューリングユニットのいずれかがスケジューリングに失敗した場合、既にスケジューリングされているスケジューリングユニットを削除し、リソースを解放する。

【0061】

一実施例では、ＣＲＤのＰｏｄ集合のいずれかのＰｏｄのスケジューリングが失敗した場合、ＣＲＤ全体スケジューリングが失敗したとみなされる。ＣＲＤのスケジューリングに失敗すると、そのＣＲＤですでにスケジューリングに成功したＰｏｄは削除されてリソースを解放する必要があり、これによって、リソースの占有による実行効率の低下を避けることができる。

【0062】

図５に示すように、一実施例では、全てのスケジューリング対象のスケジューリングが完了した後、スケジューリングユニットを対応するノードにバインディングするステップＳ４００は、ステップＳ４１０とステップＳ４２０を含んでもよいが、これらに限定されない。

【0063】

ステップＳ４１０：ノードバインディング要求を開始させ、ノードの割当可能リソース情報を更新し、割当可能リソース情報に基づいて最適なノードを決定し、最適なノードに基づいてスケジューリングユニットにホストをそれぞれ割り当てる。

【0064】

ステップＳ４２０：スケジューリングユニットを対応するホストにバインディングする。

【0065】

一実施例では、全てのＰｏｄのスケジューリングが完了した後、スプリッタはＡｐｉ－Ｓｅｒｖｅｒを介してＰｏｄとノードとのバインディングを行う。ノードバインディングの流れは、ノードに対してフィルタリング、優先順位付け、スコア付けなどの最適化アルゴリズムを行うことにより適切なノードを選択し、最適なノードを選択してＰｏｄにホストを割り当て、Ａｐｉ－ＳｅｒｖｅｒにＰｏｄのバインディング要求を送信することにより、Ｐｏｄを対応するホストにバインディングし、これにより、バインディング操作を完了する。

【0066】

なお、スケジューリング対象がＰｏｄである場合、Ｋｕｂｅｒｎｅｔｅｓスケジューリングシステムは従来のスケジューリングの流れに従って処理を行うが、Ｐｏｄのバインディング操作はスプリッタによって行われる。スケジューリング対象がＣＲＤである場合、スプリッタは、現在のクラスタのリソース状態に応じてＰｏｄを分解し、ＣＲＤを１つ又は複数のＰｏｄに分解し、スプリッタは、ＣＲＤを分解するＰｏｄの数、及びあるＰｏｄが使用するリソース（ＣＰＵ、メモリ、ＧＰＵ）を決定するだけでよく、スプリッタがＣＲＤを分解した後、スケジューラはこれらのＰｏｄをスケジューリングし、スケジューラはノードに対してフィルタリング、優先順位付け、スコア付けなどの最適化アルゴリズムを行い、Ｐｏｄに適したノードを選択し、これにより、ＰｏｄリストのＰｏｄとノードをスプリッタによってバインディングし、スケジューラとスプリッタのリソースの同期化を確保する。

【0067】

また、スケジューラとスプリッタはリソース同期機構を有し、スプリッタがＣＲＤを合理的で最適に分解するためには、クラスタのリソース状態を明確にし、ノード及びＰｏｄ情報をリスニングし、ローカルに割当可能リソース情報をキャッシュする必要がある。ＣＲＤのＰｏｄ集合がスケジューラによって正常にスケジューリングされた後、スケジューラはＰｏｄのバインディング要求をスプリッタに送信し、スプリッタはバインディング要求を受信すると、スプリッタのローカルにキャッシュされたノード割当可能リソース情報を更新してから、最終的なバインディング要求をＡｐｉ－Ｓｅｒｖｅｒに送信し、これによって、リソースの同期化を達成する。

【0068】

図６に示すように、一実施例では、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームを例として、リソーススケジューリング方法はステップＳ６１０～ステップＳ６５０を含むが、これらに限定されない。

【0069】

ステップＳ６１０：Ａｐｉ－Ｓｅｒｖｅｒを介してＣＲＤ、Ｐｏｄ対象を作成する。
ステップＳ６２０：Ａｐｉ－Ｓｅｒｖｅｒを介してＣＲＤ、Ｐｏｄ対象をリスニングし、新しいＣＲＤ又はＰｏｄを同一のスケジューリングキューに入れる。
ステップＳ６３０：スケジューリングキューからスケジューリング対象を取得する。
スケジューリング対象がＰｏｄである場合、Ｐｏｄスケジューリングの流れに従って処理を行い、
スケジューリング対象がＣＲＤである場合、ＣＲＤ分解要求をスプリッタに送信し、スプリッタに現在のリソース状態に応じてＣＲＤを分解させ、分解されたＰｏｄをＡｐｉ－Ｓｅｒｖｅｒを介して作成する。
ステップＳ６４０：スプリッタから返されたＰｏｄリストに従って、Ｐｏｄリストに従ってＰｏｄを順次スケジューリングする。
ステップＳ６５０：全てのＰｏｄスケジューリングが完了した後、スプリッタにバインディング要求を開始させ、Ａｐｉ－Ｓｅｒｖｅｒを介してＰｏｄとノードとのバインディングを行う。

【0070】

上記した様々な実施例におけるリソーススケジューリング方法の特定のステップの流れをより明確に説明するために、以下に５つの実施例を用いて説明する。

【0071】

実施例１
本実施例はスケジューラがＣＲＤとＰｏｄのコスケジューリングに成功した例であり、ＫｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームにおいてＣＲＤとＰｏｄのコスケジューリングを行う過程を示し、深層学習ジョブをＣＲＤと定義し、深層学習ジョブの並列実行を完了したＷｏｒｋｅｒｓをＰｏｄによってキャリアし、これによって、深層学習ジョブとＰｏｄのコスケジューリングを実現でき、かつ成功に運転できる。
インスタンス環境：２つのノードを含み、ノードリソースが十分であるＵｂｕｎｔｕ１６．０４システムを搭載したＫｕｂｅｒｎｅｔｅｓクラスタであって、クラスタには修正されたスケジューラがデプロイされており、カスタマイズされた深層学習ジョブのコントローラとスプリッタがデプロイされている。
図７に示すように、具体的な操作ステップは以下のとおりである。
ステップＳ７１０：深層学習ジョブファイルを定義し、このＣＲＤ対象を作成する。
ステップＳ７２０：個々のＰｏｄのファイルを定義し、そのＰｏｄ対象を作成する。
ステップＳ７３０：深層学習ジョブの作成に成功した後、深層学習ジョブに対応するＣＲＤは運転状態となる。
ステップＳ７４０：深層学習ジョブに関連するＰｏｄの作成に成功した後、深層学習ジョブで分解されたＰｏｄは全て運転状態となる。
これにより、ステップＳ７２０で作成された個々のＰｏｄの状態は運転状態であり、ここでは、ＣＲＤの状態と分解されたＰｏｄの状態とが一致する。

【0072】

実施例２
本実施例では、スケジューラは２種類のＣＲＤ対象のスケジューリングに成功し、実施例はＫｕｂｅｒｎｅｔｅｓスケジューリングプラットフォーム上で異なるＣＲＤをコスケジューリングする過程を示し、深層学習ジョブをＣＲＤと定義し、機械学習ジョブをＣＲＤと定義し、２種類のＣＲＤ対象が実行するＷｏｒｋｅｒｓを全てＰｏｄによってキャリアし、深層学習ジョブと機械学習ジョブのコスケジューリングを実現でき、しかも成功に運転できる。
インスタンス環境：２つのノードを含み、ノードリソースが十分であるＵｂｕｎｔｕ１６．０４システムを搭載したＫｕｂｅｒｎｅｔｅｓクラスタであって、クラスタには修正されたスケジューラがデプロイされており、カスタマイズされた深層学習ジョブのコントローラとスプリッタがデプロイされており、カスタマイズされた機械学習ジョブのコントローラとスプリッタがデプロイされている。
図８に示すように、具体的な操作ステップは以下のとおりである。
ステップＳ８１０：深層学習ジョブファイルを定義し、このＣＲＤ対象を作成する。
ステップＳ８２０：機械学習ジョブファイルを定義し、このＣＲＤ対象を作成する。
ステップＳ８３０：深層学習ジョブの作成に成功した後、深層学習ジョブに対応するＣＲＤは運転状態となる。
ステップＳ８４０：深層学習ジョブに関連するＰｏｄの作成に成功した後、深層学習ジョブで分解されたＰｏｄは全て運転状態となる。
ステップＳ８５０：機械学習ジョブの作成に成功した後、深層学習ジョブに対応するＣＲＤは運転状態となる。
ステップＳ８６０：機械学習ジョブに関するＰｏｄの作成に成功した後、深層学習ジョブで分解されたＰｏｄは全て運転状態となる。
ここで、ＣＲＤの状態は、分解されたＰｏｄの状態と一致していなければならない。

【0073】

実施例３
本実施例では、スケジューラはＣＲＤを最小限のノードで運転するようにスケジューリングし、実施例は、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォーム上でＣＲＤ対象をスケジューリングする場合に、リソース状態に応じてＣＲＤを合理的に分解することができることを示し、深層学習ジョブをＣＲＤと定義し、深層学習ジョブの並列実行を完了したＷｏｒｋｅｒｓをＰｏｄによってキャリアし、スケジューラはＣＲＤをスケジューリングする際に、現在のリソース状態に応じてＣＲＤを自動的に分解し、ＣＲＤのＰｏｄを極小のノード上で運転するようにスケジューリングし、これによって、ネットワークのオーバーヘッドを減らし、分解の合理性を確保する。
インスタンス環境：３つのノードを含み、ノードのＣＰＵ、メモリリソースが十分で、ノード１には８つのアイドルＧＰＵがあり、ノード２、３のいずれにも４つのアイドルＧＰＵがあるＵｂｕｎｔｕ１６．０４システムを搭載したＫｕｂｅｒｎｅｔｅｓクラスタであって、クラスタには修正されたスケジューラがデプロイされており、カスタマイズされた深層学習ジョブのコントローラとスプリッタがデプロイされている。
図９に示すように、具体的な操作ステップは以下のとおりである。
ステップＳ９１０：８つのＧＰＵリソースを申請する深層学習ジョブファイルを定義し、このＣＲＤ対象を作成する。
ステップＳ９２０：深層学習ジョブの作成に成功した後、深層学習ジョブに対応するＣＲＤは運転状態となる。
ステップＳ９３０：深層学習ジョブに関連するＰｏｄの作成に成功した後、深層学習ジョブで分解されたＰｏｄは全て運転状態となる。
ステップＳ９４０：ＣＲＤ分解後のＰｏｄの数が１であり、そのＰｏｄがノード１上で運転する。

【0074】

実施例４
本実施例では、スケジューラはリソース申請粒状度が大きいＣＲＤのスケジューリングに成功し、実施例は、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォーム上でＣＲＤ対象をスケジューリングする場合に、リソース状態に応じてＣＲＤを合理的に分解することを示し、深層学習ジョブをＣＲＤと定義し、深層学習ジョブの並列実行を完了したＷｏｒｋｅｒｓをＰｏｄによってキャリアし、スケジューラはＣＲＤをスケジューリングする際に、現在のリソース状態に応じてＣＲＤを自動的に分解することができ、もしこのジョブのリソース申請粒状度が大きい場合、単ノードリソースはそのジョブのリソース申請を満足できないが、クラスタの総リソースが満足できる場合にはこのＣＲＤを成功に分解し、スケジューリングして運転することができ、これによって、このジョブがリソーススターベーション状態にならないことを確保する。
インスタンス環境：４つのノードを含み、ノードのＣＰＵ、メモリリソースが十分で、ノード１、３のいずれにも４つのアイドルＧＰＵがあり、ノード２、４のいずれにも２つのアイドルＧＰＵがあるＵｂｕｎｔｕ１６．０４システムを搭載したＫｕｂｅｒｎｅｔｅｓクラスタであって、クラスタには修正されたスケジューラはデプロイされており、カスタマイズされた深層学習ジョブのコントローラとスプリッタはデプロイされている。
図１０に示すように、具体的な操作ステップは以下のとおりである。
ステップＳ１０１０：８つのＧＰＵリソースを申請する深層学習ジョブファイルを定義し、このＣＲＤ対象を作成する。
ステップＳ１０２０：深層学習ジョブの作成に成功した後、深層学習ジョブに対応するＣＲＤは運転状態となる。
ステップＳ１０３０：深層学習ジョブに関連するＰｏｄの作成に成功した後、深層学習ジョブで分解されたＰｏｄは全て運転状態となる。
ステップＳ１０４０：ＣＲＤ分解後のＰｏｄの数が２であり、２つのＰｏｄがノード１とノード３上で運転する。

【0075】

実施例５
本実施例では、スケジューラはＣＲＤ分解後のＰｏｄをアトミックにスケジューリングし、実施例は、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォーム上でスケジューラが単一ＣＲＤ対象に対するＰｏｄのスケジューリングを実現できることを示し、深層学習ジョブをＣＲＤと定義し、機械学習ジョブをＣＲＤと定義し、２種類のＣＲＤ対象が実行するＷｏｒｋｅｒｓを全てＰｏｄによってキャリアし、ＣＲＤのＰｏｄのアトミックスケジューリングを実現でき、ＣＲＤのスケジューリングが不合理であることや２つのＣＲＤがリソースのデッドロックに入るという問題を回避できる。
インスタンス環境：３つのノードを含み、ノードのＣＰＵ、メモリリソースが十分で、３つのノードの全てには４つのアイドルＧＰＵがあるＵｂｕｎｔｕ１６．０４システムを搭載したＫｕｂｅｒｎｅｔｅｓクラスタであって、クラスタには修正されたスケジューラはデプロイされており、カスタマイズされた深層学習ジョブのコントローラとスプリッタはデプロイされており、カスタマイズされた機械学習ジョブのコントローラとスプリッタはデプロイされている。
図１１に示すように、具体的な操作ステップは以下のとおりである。
ステップＳ１１１０：８つのＧＰＵリソースを申請する深層学習ジョブファイルを定義し、このＣＲＤ対象を作成する。
ステップＳ１１２０：８つのＧＰＵリソースを申請する機械学習ジョブファイルを定義し、このＣＲＤ対象を作成する。
ステップＳ１１３０：深層学習ジョブの作成に成功した後、深層学習ジョブに対応するＣＲＤ状態である。
ステップＳ１１４０：機械学習ジョブの作成に成功した後、深層学習ジョブに対応するＣＲＤ状態である。
ステップＳ１１５０：深層学習ジョブと機械学習ジョブの一方のみが運転状態にあり、運転状態にあるジョブの関連Ｐｏｄは全て運転状態となる。

【0076】

また、本願の１つの実施例は、メモリと、プロセッサと、メモリ上に記憶され、プロセッサ上で運転可能なコンピュータプログラムと、を含む機器も提供する。プロセッサ及びメモリはバス又は他の手段を介して接続することができる。

【0077】

メモリは、非一時的なコンピュータ読み取り可能な記憶媒体として、非一時的なソフトウェアプログラムと、非一時的なコンピュータ実行可能プログラムとを記憶するために使用することができる。さらに、メモリは、高速ランダムアクセスメモリを含むことができ、また、少なくとも１つの磁気ディスク記憶デバイス、フラッシュ記憶デバイス、又は他の非一時的なソリッドステート記憶デバイスのような非一時的なメモリを含むことができる。いくつかの実施形態では、メモリは、ネットワークを介してプロセッサに接続されることができるプロセッサに対してリモートに配置されたメモリを含んでもよい。上記のネットワークの例には、インターネット、企業イントラネット、ローカルエリアネットワーク、移動通信ネットワーク、及びこれらの組み合わせが含まれるが、これらに限定されない。

【0078】

なお、本実施例の端末は、図１に示す実施例のシステムアーキテクチャプラットフォーム１００を含んでもよく、本実施例の端末と図１に示す実施例のシステムアーキテクチャプラットフォーム１００とは同一の発明思想に属するため、これらの実施例は同一の実現原理及び技術的効果を有するが、ここでは詳しく説明しない。

【0079】

上記した実施例のリソーススケジューリング方法を実現するために必要な非一時的なソフトウェアプログラム及び命令はメモリに記憶され、プロセッサによって実行されると、上記した実施例におけるリソーススケジューリング方法を実行し、例えば、上記した図２の方法ステップＳ１００～Ｓ３００、図３の方法ステップＳ１０１～Ｓ１０２、図４の方法ステップＳ４００、図５の方法ステップＳ４１０～Ｓ４２０、図６の方法ステップＳ６１０～Ｓ６５０、図７の方法ステップＳ７１０～Ｓ７４０、図８の方法ステップＳ８１０～Ｓ８６０、図９の方法ステップＳ９１０～Ｓ９４０、図１０の方法ステップＳ１０１０～Ｓ１０４０、図１１の方法ステップＳ１１１０～Ｓ１１５０を実行する。

【0080】

上記で説明された装置の実施例は単に概略的なものであり、分離された構成要素として説明されたユニットは、物理的に分離されていてもよいし、そうでなくてもよく、すなわち、１つの場所に配置されていてもよいし、複数のネットワークユニットに分散されていてもよい。これらのモジュールの一部又は全部は、実際の必要に応じて、本実施例の目的を達成するために選択されてもよい。

【0081】

さらに、本願の一実施例は、１つのプロセッサ又はコントローラによって実行される、例えば、上記した端末の実施例の１つのプロセッサによって実行されると、上記した実施例におけるリソーススケジューリング方法、例えば、上記した図２の方法ステップＳ１００～Ｓ３００、図３の方法ステップＳ１０１～Ｓ１０２、図４の方法ステップＳ４００、図５の方法ステップＳ４１０～Ｓ４２０、図６の方法ステップＳ６１０～Ｓ６５０、図７の方法ステップＳ７１０～Ｓ７４０、図８の方法ステップＳ８１０～Ｓ８６０、図９の方法ステップＳ９１０～Ｓ９４０、図１０の方法ステップＳ１０１０～Ｓ１０４０、図１１の方法ステップＳ１１１０～Ｓ１１５０を上記したプロセッサに実行させるコンピュータ実行可能命令を記憶したコンピュータ読み取り可能な記憶媒体も提供する。

【0082】

本願の実施例は、リソースをスケジューリングする際に、スケジューリングキューからスケジューリング対象を取得し、スケジューリング対象がカスタムリソースである場合、現在のリソース状態に応じてカスタムリソースを分解して、カスタムリソースを構成するように構成される第１スケジューリングユニットを含むスケジューリングユニットリストを得て、次に、スケジューリングユニットリストに従って各第１スケジューリングユニットを順次スケジューリングするステップを含み、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームに適用でき、スケジューリングする際に、スケジューリング対象がＣＲＤである場合、現在のリソース状態に応じてＣＲＤを分解して、Ｐｏｄ集合を含むスケジューリングユニットリストを得て、このように、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームがスケジューリングユニットリストに従ってＰｏｄをアトミックにスケジューリングすることができ、全てのＰｏｄがキューに従って順次スケジューリングされ、他のＰｏｄが挿入されることを回避し、このようにＣＲＤが合理的にスケジューリングされ、スケジューリング効率が高く、Ｋｕｂｅｒｎｅｔｅｓスケジューリングプラットフォームが様々な業務シナリオに適合することを確保する。

【0083】

当業者であれば、上記で開示された方法におけるステップの全部又は一部、システムは、ソフトウェア、ファームウェア、ハードウェア、及びそれらの適切な組み合わせとして実装されてもよいことを理解する。物理的構成要素の一部又は全ては、中央処理機器、デジタル信号プロセッサ、マイクロプロセッサなどのプロセッサによって実行されるソフトウェアとして、又はハードウェアとして、又は特定用途向け集積回路などの集積回路として実装されてもよい。このようなソフトウェアは、コンピュータ記憶媒体（又は非一時的媒体）及び通信媒体（又は一時的媒体）を含むことができるコンピュータ読み取り可能な媒体上に配置されてもよい。当業者に周知のように、コンピュータ記憶媒体という用語は、情報（例えばコンピュータ読み取り可能な命令、データ構造、プログラムモジュール、又は他のデータ）を記憶するための任意の方法又は技術において実施される、揮発性及び不揮発性の、取り外し可能な、及び取り外し不可能な媒体を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ－ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）又は他の光ディスク記憶機器、磁気カートリッジ、磁気テープ、磁気ディスク記憶機器又は他の磁気記憶機器、又は所望の情報を記憶するために使用することができ、コンピュータによってアクセスすることができる他の任意の媒体を含むが、これらに限定されない。さらに、通信媒体は、通常、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、又は搬送波や他の送信機構のような変調データ信号中の他のデータを含み、任意の情報配信媒体を含み得ることが当業者には周知である。

【0084】

以上は本願の好ましい実施例を具体的に説明したが、本願は上記の実施形態に限定されるものではなく、当業者は本願の精神に反しないことなく様々な均等な変形や置換を行うことができ、これらの均等な変形や置換はいずれも本願の請求項によって定められる範囲内に含まれるものとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】