特表 2024-541872 コンテナ・エンジン及びコンテナ・エンジンの実現方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-11-13

(54)【発明の名称】コンテナ・エンジン及びコンテナ・エンジンの実現方法

(51)【国際特許分類】

   G06F 9/445 20180101AFI20241106BHJP

【ＦＩ】

G06F9/445

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024523513

(86)(22)【出願日】2022-10-18

(85)【翻訳文提出日】2024-04-18

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

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

(87)【国際公開日】2023-04-27

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

(32)【優先日】2021-10-18

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＵＮＩＸ

(71)【出願人】

【識別番号】511151662

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

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

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

(74)【代理人】

【識別番号】100112656

【弁理士】

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

(74)【代理人】

【識別番号】100089118

【弁理士】

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

(72)【発明者】

【氏名】張徐瑜

(72)【発明者】

【氏名】談虎

(72)【発明者】

【氏名】劉建軍

(72)【発明者】

【氏名】陳俊霖

(72)【発明者】

【氏名】梁顯龍

(72)【発明者】

【氏名】王亮

(72)【発明者】

【氏名】李龍江

(72)【発明者】

【氏名】況明富

(72)【発明者】

【氏名】薛志宏

(72)【発明者】

【氏名】李翌

【テーマコード（参考）】

5B376

【Ｆターム（参考）】

5B376AE07

5B376AE12

5B376AE44

5B376EA17

(57)【要約】

【課題】本開示は、コンテナ・エンジン及びコンテナ・エンジンの実現方法、電子機器、コンピュータ可読な記憶媒体を提供する。
【解決手段】管理ノードに設けられた第1の装置に適用されるコンテナ・エンジンの実現方法は、通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信するステップと、前記通信プロトコルを採用して、前記第2の装置が送信したコンテナ操作応答を受信するステップとを含む。管理ノードまたはワーカー・ノードに設けられた第2の装置に適用されるコンテナ・エンジンの実現方法は、通信プロトコルを採用して、前記第1の装置が送信したコンテナ操作要求を受信し、コンテナ操作を行うステップと、前記通信プロトコルを採用して、コンテナ操作応答を前記第1の装置へ送信するステップとを含む。
【選択図】図3

【特許請求の範囲】

【請求項1】

管理ノードに設けられた第1の装置に適用されるコンテナ・エンジンの実現方法であって、
通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信するステップと、
前記通信プロトコルを採用して、前記第2の装置が送信したコンテナ操作応答を受信するステップと、を含むコンテナ・エンジンの実現方法。

【請求項2】

通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信する前記ステップの前に、
前記通信プロトコルを採用して、ノード・ステータス照会要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信した、ノード・ステータス情報を含んだノード・ステータス照会応答を受信するステップと、
前記通信プロトコルを採用して、第1のノード・リソース申請要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信した第1のノード・リソース申請応答を受信するステップと、
前記通信プロトコルを採用して、第2のノード・リソース申請要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信した第2のノード・リソース申請応答を受信するステップと、
前記通信プロトコルを採用して、コンテナ・イメージ操作要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信したコンテナ・イメージ操作応答を受信するステップとのうちの少なくとも一つを含む請求項１に記載のコンテナ・エンジンの実現方法。

【請求項3】

標準入力、標準エラーと標準出力のリンク・タイプを示すコンソール・タイプ・パラメータを受信するステップと、
前記通信プロトコルを採用して、前記コンソール・タイプ・パラメータをコンテナ作成要求またはプロセス作成要求に含ませて前記第2の装置に送信するステップと、
をさらに含む請求項１に記載のコンテナ・エンジンの実現方法。

【請求項4】

前記コンソール・タイプ・パラメータが、前記標準入力、標準エラーと標準出力を指定コンソールにリンクすることを示すために使用される場合、
前記通信プロトコルを採用して、前記第1の装置のポートを前記コンテナ作成要求またはプロセス作成要求に含ませて前記第2の装置に送信するステップと、
前記通信プロトコルを採用して、コンテナの標準入力を前記第1の装置のポートによって前記第2の装置に送信するステップと、
前記第2の装置が送信したコンテナの標準出力と標準エラーを受信するために前記通信プロトコルを採用して前記第1の装置のポートをリッスンし、前記コンテナの標準出力と標準エラーを前記指定コンソールに出力するステップと、をさらに含む請求項３に記載のコンテナ・エンジンの実現方法。

【請求項5】

前記コンソール・タイプ・パラメータが、前記標準入力、標準エラーと標準出力を指定ファイルにリンクすることを示すために使用される場合、
前記通信プロトコルを採用して、前記指定ファイルのファイル名を前記コンテナ作成要求またはプロセス作成要求に含ませて前記第2の装置に送信するステップをさらに含む請求項３に記載のコンテナ・エンジンの実現方法。

【請求項6】

通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信する前記ステップの前に、
事前設定された前記第2の装置のアドレスとポートに基づいて前記通信プロトコルを採用して、リンク確立要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信したリンク確立応答を受信するステップと、
前記通信プロトコルを採用して、登録コマンドを前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信した登録応答を受信するステップと、をさらに含む請求項１～５のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項7】

第1のノード・リソース申請要求を第2の装置へ送信する前記ステップの前に、
前記通信プロトコルを採用して、コンテナ・スペーサ・モジュール作成要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信したコンテナ・スペーサ・モジュール作成応答を受信するステップをさらに含む請求項１～５のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項8】

前記コンテナ・スペーサ・モジュール作成応答は、コンテナ・スペーサ・モジュールのポートを含む請求項７に記載のコンテナ・エンジンの実現方法。

【請求項9】

前記通信プロトコルは、リモート・プロシージャ・コール・プロトコルRPC、ソケット、プロセス間通信IPCの何れか一つを含む、請求項１～５のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項10】

管理ノードまたはワーカー・ノードに設けられた第2の装置に適用されるコンテナ・エンジンの実現方法であって、
通信プロトコルを採用して、前記第1の装置が送信したコンテナ操作要求を受信し、コンテナ操作を行うステップと、
前記通信プロトコルを採用して、コンテナ操作応答を前記第1の装置へ送信するステップと、を含むコンテナ・エンジンの実現方法。

【請求項11】

通信プロトコルを採用して、前記第1の装置が送信したコンテナ操作要求を受信する前記ステップの前に、
前記通信プロトコルを採用して、前記第1の装置が送信したノード・ステータス照会要求を受信し、ノード・ステータス情報を照会し、前記通信プロトコルを採用して、前記ノード・ステータス情報を含むノード・ステータス照会応答を前記第1の装置へ送信するステップ、
前記通信プロトコルを採用して、第1の装置が送信した第1のノード・リソース申請要求を受信し、前記第1の装置のために第1のノード・リソースを割り当て、前記通信プロトコルを採用して、第1のノード・リソース申請応答を前記第1の装置へ送信するステップ、
前記通信プロトコルを採用して、前記第1の装置が送信した第2のノード・リソース申請要求を受信し、前記第1の装置のために第2のノード・リソースを割り当て、前記通信プロトコルを採用して、第2のノード・リソース申請応答を前記第1の装置へ送信するステップ、または
前記通信プロトコルを採用して、前記第1の装置が送信したコンテナ・イメージ操作要求を受信し、コンテナ・イメージ操作を行い、前記通信プロトコルを採用して、コンテナ・イメージ操作応答を前記第1の装置へ送信するステップのうちの少なくとも一つをさらに含む請求項１０に記載のコンテナ・エンジンの実現方法。

【請求項12】

前記通信プロトコルを採用して、前記第1の装置が送信したコンソール・タイプ・パラメータであって、標準入力、標準エラーと特徴付け出力のリンク・タイプを示す前記コンソール・タイプ・パラメータを受信するステップをさらに含む請求項１０に記載のコンテナ・エンジンの実現方法。

【請求項13】

前記コンソール・タイプ・パラメータが、前記標準入力、標準エラーと標準出力を指定コンソールにリンクすることを示すために使用される場合、
前記通信プロトコルを採用して、前記第1の装置が送信した、前記第1の装置のポートを受信するステップと、
前記通信プロトコルを採用して、前記第1の装置のポートによって前記第1の装置が送信したコンテナの標準入力を受信し、前記コンテナの標準入力を前記コンテナに入力するステップと、
コンテナの標準出力と標準エラーを受信し、前記通信プロトコルを採用して、前記コンテナの標準出力と標準エラーを前記第1の装置のポートによって前記第1の装置に送信するステップと、をさらに含む請求項１２に記載のコンテナ・エンジンの実現方法。

【請求項14】

前記コンソール・タイプ・パラメータが、前記標準入力、標準エラーと標準出力を指定ファイルにリンクすることを示すために使用される場合、
前記通信プロトコルを採用して、前記第1の装置が送信した、前記指定ファイルのファイル名を受信するステップと、
受信した前記指定ファイルのファイル名をファイル名として前記指定ファイルを作成し、コンテナの標準入力と標準エラーを前記指定ファイルに書き込むステップとをさらに含む請求項１２に記載のコンテナ・エンジンの実現方法。

【請求項15】

通信プロトコルを採用して、前記第1の装置が送信したコンテナ操作要求を受信する前記ステップの前に、
前記第1の装置が送信したリンク確立要求を受信するために、前記通信プロトコルを採用して、事前設定された、前記第2の装置のアドレスとポートをリッスンし、前記通信プロトコルを採用して、リンク確立応答を前記第1の装置へ送信するステップと、
前記通信プロトコルを採用して、前記第1の装置が送信した登録コマンドを受信し、前記登録コマンドを実行し、前記通信プロトコルを採用して、登録応答を前記第1の装置へ送信するステップとをさらに含む請求項１０～１４のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項16】

第1の装置が送信した第1のノード・リソース申請要求を受信する前記ステップの前に、
前記通信プロトコルを採用して、前記第1の装置が送信したコンテナ・スペーサ・モジュール作成要求を受信し、コンテナ・スペーサ・モジュールを作成し、前記通信プロトコルを採用して、コンテナ・スペーサ・モジュール作成応答を前記第1の装置へ送信するステップをさらに含む請求項１０～１４のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項17】

前記コンテナ・スペーサ・モジュール作成応答は、コンテナ・スペーサ・モジュールのポートを含む請求項１６に記載のコンテナ・エンジンの実現方法。

【請求項18】

前記通信プロトコルは、リモート・プロシージャ・コール・プロトコルRPC、ソケット、プロセス間通信IPCの何れか一つを含む請求項１０～１４のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項19】

少なくとも1つのプロセッサと、
少なくとも1つのプログラムが記憶され、前記少なくとも1つのプログラムが前記少なくとも1つのプロセッサによって実行されると、請求項１～９のいずれか一項に記載のコンテナ・エンジンの実現方法、または、請求項１０～１８のいずれか一項に記載のコンテナ・エンジンの実現方法を実現するメモリと、を備える電子機器。

【請求項20】

コンピュータプログラムが記憶されたコンピュータ可読な記憶媒体であって、前記コンピュータプログラムがプロセッサによって実行されると、請求項１～９のいずれか一項に記載のコンテナ・エンジンの実現方法、または、請求項１０～１８のいずれか一項に記載のコンテナ・エンジンの実現方法を実現するコンピュータ可読な記憶媒体。

【請求項21】

管理ノードに設けられた第1の装置と、管理ノードまたはワーカー・ノードに設けられた第2の装置とを含むコンテナ・エンジンであって、
前記第1の装置は、
コンテナ操作要求をマスター・エージェント・サブモジュールへ送信するように配置されるコンテナ管理サブモジュールと、
通信プロトコルを採用して、コンテナ操作要求を前記第2の装置のコンテナ操作サブモジュールへ送信し、前記通信プロトコルを採用して、前記第2の装置のコンテナ操作サブモジュールが送信したコンテナ操作応答を受信するように配置されるマスター・エージェント・サブモジュールと、
を有するコンテナ・エンジン・コアモジュールを備え、
前記第2の装置は、
前記通信プロトコルを採用して、前記第1の装置のマスター・エージェント・サブモジュールが送信したコンテナ操作要求を受信し、前記コンテナ操作要求をコンテナ・ランタイム・モジュールに送信するように配置される前記コンテナ操作サブモジュールを含むコンテナ・スペーサ・モジュールと、
コンテナ操作を行い、コンテナ操作応答を前記コンテナ操作サブモジュールへ送信するように配置されるコンテナ・ランタイム・モジュールと、
を備え、
前記コンテナ操作サブモジュールはさらに、前記通信プロトコルを採用して、コンテナ操作応答を前記第1の装置のマスター・エージェント・サブモジュールへ送信するようにさらに配置されるコンテナ・エンジン。

【請求項22】

前記第1の装置と前記第2の装置との間はバス技術、有線ネットワーク技術、無線ネットワーク技術のうちの何れか一つのリンクが採用される請求項２１に記載のコンテナ・エンジン。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は2021年10月18日に国家知識産権局へ提出された出願番号をCN202111212628.4とN202111212628.4とし、発明の名称を「コンテナ・エンジン及びコンテナ・エンジンの実現方法、電子機器、記憶媒体」とする中国特許出願の優先権を主張し、これら出願の全ての内容を援用によって引用することとする。

【0002】

本開示の実施形態は、クラウド・コンピューティング・コンテナ技術分野に関するものであるが、これに限定されるものではなく、具体的には、コンテナ・エンジン及びコンテナ・エンジンの実現方法、電子機器、コンピュータ可読な記憶媒体に関するものである。

【背景技術】

【0003】

クラウド・コンピューティング分野におけるヒット技術としてのコンテナ技術は、独立した実行環境をビジネスプログラムに提供する同時に、コンテナのデプロイ、起動、削除は高速で、かつ、中央処理ユニット（CPU，Center Processing Unit）、メモリ、入出力（IO，Input Output）のパフォーマンス・ロスはゼロである。

【0004】

コンテナ分野においては、Docker、Containerd、コンテナ・ランタイム・インターフェイス-オープン（CRI-O，Container Runtime Interface Open）をはじめとするコンテナ・エンジンが登場した。これらコンテナ・エンジンは、アプリケーション・プログラミング・インターフェース（API、Application Programming Interface）とコマンドラインを外部に提供し、コンテナ・イメージ管理機能とコンテナファイフサイクル管理機能をAPIとコマンドラインによって提供する。現在、業界で広く使用されているDocker、Containerd、CRI-Oなどのコンテナ・エンジンは、一般的にワーカー・ノード上にコンテナ・オーケストレーション・システムのノード・エージェントとともにデプロイされており、管理ノードにはコンテナ・オーケストレーション・システムのAPIのみがデプロイされている。この配置方法では、ワーカー・ノード上でのコンテナ・エンジンとコンテナ・オーケストレーション・システムのノード・エージェントには、ワーカー・ノードのCPUとメモリリソースを過剰に消費するという問題がある。

【発明の概要】

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

【0005】

本開示の実施形態は、コンテナ・エンジン及びコンテナ・エンジンの実現方法、電子機器、コンピュータ可読な記憶媒体を提供する。

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

【0006】

第一の様態において、本開示の実施形態は、管理ノードに設けられた第1の装置に適用されるコンテナ・エンジンの実現方法であって、通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信するステップと、前記通信プロトコルを採用して、前記第2の装置が送信したコンテナ操作応答を受信するステップと、を含むコンテナ・エンジンの実現方法を提供する。

【0007】

第二の様態において、本開示の実施形態は、管理ノードまたはワーカー・ノードに設けられた第2の装置に適用されるコンテナ・エンジンの実現方法であって、通信プロトコルを採用して、前記第1の装置が送信したコンテナ操作要求を受信し、コンテナ操作を行うステップと、前記通信プロトコルを採用して、コンテナ操作応答を前記第1の装置へ送信するステップと、を含むコンテナ・エンジンの実現方法を提供する。

【0008】

第三の様態において、本開示実施形態は、少なくとも1つのプロセッサと、少なくとも1つのプログラムが記憶され、前記少なくとも1つのプログラムが前記少なくとも1つのプロセッサによって実行されると、前記何れか一つのコンテナ・エンジンの実現方法を実現するメモリと、を備える電子機器を提供する。

【0009】

第四の様態において、本開示の実施形態は、コンピュータプログラムが記憶されたコンピュータ可読な記憶媒体であって、前記コンピュータプログラムがプロセッサによって実行されると、前記何れか一つのコンテナ・エンジンの実現方法を実現するコンピュータ可読な記憶媒体を提供する。

【0010】

第五の様態において、本開示実施形態は、管理ノードに設けられた第1の装置と、管理ノードまたはワーカー・ノードに設けられた第2の装置とを含むコンテナ・エンジンであって、前記第1の装置は、コンテナ操作要求をマスター・エージェント・サブモジュールへ送信するように配置されるコンテナ管理サブモジュールと、通信プロトコルを採用して、コンテナ操作要求を前記第2の装置のコンテナ操作サブモジュールへ送信し、前記通信プロトコルを採用して、前記第2の装置のコンテナ操作サブモジュールが送信したコンテナ操作応答を受信するように配置されるマスター・エージェント・サブモジュールとを有するコンテナ・エンジン・コアモジュールを備え、前記第2の装置は、前記通信プロトコルを採用して、前記第1の装置のマスター・エージェント・サブモジュールが送信したコンテナ操作要求を受信し、前記コンテナ操作要求をコンテナ・ランタイム・モジュールに送信するように配置される前記コンテナ操作サブモジュールを含むコンテナ・スペーサ・モジュールと、コンテナ操作を行い、コンテナ操作応答を前記コンテナ操作サブモジュールへ送信するように配置されるコンテナ・ランタイム・モジュールと、を備え、前記コンテナ操作サブモジュールはさらに、前記通信プロトコルを採用して、コンテナ操作応答を前記第1の装置のマスター・エージェント・サブモジュールへ送信するように配置されるコンテナ・エンジンを提供する。

【図面の簡単な説明】

【0011】

【図1】図1は、関連技術におけるコンテナ・エンジンの構成模式図である。

【図2】図2は、本開示の実施形態によって提供されるコンテナ・エンジンの構成のブロック図である。

【図3】図3は、本開示の一実施形態によって提供される、管理ノードに適用されるコンテナ・エンジンの実現方法のフローチャート図である。

【図4】図4は、本開示の別の実施形態によって提供される、ワーカー・ノードに適用されるコンテナ・エンジンの実現方法のフローチャート図である。

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

【0012】

本開示の技術案を当業者がより良く理解できるよう、本開示によって提供されるコンテナ・エンジン及びコンテナ・エンジンの実現方法、電子機器、コンピュータ可読な記憶媒体を、図面を組み合わせながら以下に詳細に説明する。

【0013】

以下、図面を参照して例示的な実施形態について詳細に説明するが、前記例示的な実施形態は異なる形態で具現化されてもよく、本明細書に記載された実施形態に限定されると解釈すべきではない。むしろ、これら実施形態の提供は、本開示を徹底して完全なものとし、当業者に本開示の範囲を十分に理解させることを目的とする。

【0014】

本開示の様々な実施形態および実施形態における様々な特徴は、矛盾しない限り、互いに組み合わせることができる。

【0015】

本開示で使用される用語「および/または（和/或）」には、少なくとも1つの関連する列挙項目の任意またはすべての組み合わせが含まれる。

【0016】

本明細書にて使用される用語は特定の実施形態について説明するためのものにすぎず、本開示を制限する意図はない。本明細書にて使用される「一つの（一个）」と「当該（該）」という単数形も、上下文で別途明らかに説明しない限り複数形を含む意図もある。本明細書にて「含む(包括)」、「…からなる(由……制成)」という用語が使用されるときに、前記特徴、全体、ステップ、オペレーション、要素、および/またはコンポーネントの存在を指定するが、少なくとも1つの他の特徴、全体、ステップ、オペレーション、要素、コンポーネント、および／またはそれらのグループの存在または追加を除外するものでないことがさらに理解されるであろう。

【0017】

本明細書で使用されるすべての用語（技術用語および科学用語を含む）は、特に限定されない限り、当業者が一般的に理解するのと同じ意味を有するものとする。また、常用辞典にて限定されるそれら用語は、関連技術および本開示の背景での意味と一致する意味を有し、本明細書にて明確に定義しない限り、理想的または過度に形式的な意味を有するとして解釈されないであろうことがさらに理解されるであろう。

【0018】

コンテナ分野では、Docker、Containerd、CRI-Oをはじめとするコンテナ・エンジンが登場している。これらコンテナ・エンジンは、APIとコマンドラインを外部に提供し、コンテナ・イメージ管理機能とコンテナファイフサイクル管理機能をAPIとコマンドラインによって提供している。現在、業界で広く使われているDocker、ContainerdとCRI-Oなどのコンテナ・エンジンは、機能上、コンテナ・エンジン・コアモジュール、コンテナ・スペーサ・モジュールとコンテナ・ランタイム・モジュールに大きく分けることができ、図1に示すように、コンテナ・エンジン・コア・モジュールは具体的に、APIサブモジュール、クライアント・サブモジュール、コンテナ管理サブモジュール、コンテナ・イメージ管理サブモジュール、ノード管理サブモジュールとイメージ記憶サブモジュールを含み、コンテナ・スペーサ・モジュールは具体的に、入出力転送サブモジュール、コンテナ・リソース回収サブモジュールとコンテナ操作サブモジュールを含み、コンテナ・ランタイム・モジュールは具体的に、オープン・コンテナ・イニシアティブ（OCI，Open Container Initiative）ランタイム・サブモジュールまたはLXC（Linux（登録商標） Container）サブモジュールを含む。

【0019】

各サブモジュールの機能を以下に説明する。

【0020】

APIサブモジュールは、コンテナ・エンジン機能とサービス・ソフトウェア・インタフェース・サブモジュールを外部（例えば、コンテナ・オーケストレーション・システム）に提供することを担当している。

【0021】

クライアント・サブモジュールは、コンテナ、イメージ操作に対してコンテナ・エンジンが提供したコマンドライン・ツールを担当している。

【0022】

コンテナ管理サブモジュールは、コンテナに対する作成、実行、停止と削除などのライフサイクル状態の管理を担当している。

【0023】

コンテナ・イメージ管理サブモジュールは、イメージ状態、イメージとの間の関係の管理を担当している。

【0024】

ノード管理サブモジュールは、管理ノード・リソースとセキュリティ状態などの情報を管理することを担当している。

【0025】

イメージ・ストレージ・サブモジュールは、イメージの実際ファイルまたはデバイスの管理と、イメージ内容に対する読み書きを担当している。

【0026】

入出力転送サブモジュールは、外部からの入力をコンテナ内部へ転送するとともに、コンテナ内部の出力をコンテナ・エンジンに転送することを担当している。

【0027】

コンテナ・リソース回収サブモジュールは、死んだコンテナによって消費されたシステム・リソースの回収を担当している。

【0028】

コンテナ操作サブモジュールは、コンテナ・ランタイム・モジュールを呼び出して、コンテナの作成、実行、停止、削除、閲覧などの操作を直接開始することを担当している。

【0029】

OCIランタイム・サブモジュールは、OCI仕様の定義を満たすコンテナ・ランタイム・ツールであり、オペレーティングシステム上でコンテナの作成、実行、停止、削除、閲覧などの具体的な操作を実行することを担当している。

【0030】

LXCサブモジュールは、オープンソースのLinux Contianerプロジェクトで提供され、Linux上でコンテナのツールまたはダイナミック・ライブラリの作成、実行、停止、削除、閲覧を行うことができる。

【0031】

コンテナ・エンジンは、APIサブモジュールまたはクライアント・サブモジュールをコンテナ・オーケストレーション・システムに提供し、コンテナ・オーケストレーション・システム（例えば、K8S（Kubernetes）、K3Sなど）はイメージの作成、イメージの削除、イメージの照会、イメージのインポート、イメージのエクスポート、リポジトリからのイメージのプル、リポジトリへのイメージのプッシュなどのコンテナ管理機能、およびコンテナの作成、コンテナの削除、コンテナの起動、コンテナの停止、コンテナの一時停止、コンテナの再開、コンテナのステータスの照会などを完了するよう、APIサブモジュールまたはクライアント・サブモジュールを使用してコンテナ・エンジンに指示する。現在のコンテナ・エンジンの実現では、基礎となるオペレーティングシステムを呼び出して実現した、コンテナの作成、コンテナの削除、コンテナの起動、コンテナの停止、コンテナの一時停止、コンテナの再開などの機能は、OCIランタイム・サブモジュールまたはLXCサブモジュールに統合される。コンテナ・エンジンは内部でコンテナのライフサイクルの状態管理を維持し、コンテナ操作は、コンテナ操作サブモジュールがOCIランタイム・サブモジュールまたはLXCサブモジュールを呼び出して行われる。また、コンテナ内部プロセスの終了時のリソース回収を処理し、コンテナ内部プロセスの標準入力、標準出力、標準エラーを中継するために、コンテナ・エンジンのいずれにもコンテナ・スペーサ・モジュールが設けられている。

【0032】

K8S、K3S、Docker Swarmといった主なコンテナ・オーケストレーション・システムの登場により、クラスタ環境でのコンテナのデプロイとアップグレードがより便利となった。これにより、コンテナ・オーケストレーション・システムを管理ポータルとし、コンテナ・エンジンを作業実装ユニットとするクラウド・コンピューティングクラスタのセットが形成された。ビジネス開発者は、コンテナ・オーケストレーション・システムによってクラスタの内部ノードにビジネスプロセス群をコンテナ形式で迅速にデプロイできる。このようなクラウド・コンピューティングクラスタでは、個々の物理デバイス（例えば、サーバまたはシングルボードなど）は、その上に搭載された機能ユニットによって、管理ノードとワーカー・ノードに分けられている。管理ノードはCPU、メモリ、ストレージリソースが比較的十分なサーバまたはシングルボードであり、管理ノード上にはコンテナ・オーケストレーション・システムがデプロイされていることが多い。ワーカー・ノードは通常、CPU、メモリ、ストレージリソースが比較的不足しているサーバまたはシングルボードデバイスである。ワーカー・ノードにはコンテナ・オーケストレーション・エージェントとコンテナ・エンジンがデプロイされており、コンテナは正にコンテナ・エンジン上で実行される。クラスタ設計の信頼性、応答速度などの指標に応じて、1つ以上の管理ノードをクラスタにデプロイすることができ、クラスタのワーカーロード指標に応じて、1つ以上のワーカー・ノードをクラスタにデプロイすることができる。極端なケースでは、管理ノードとワーカー・ノードが同じ物理デバイスにデプロイされるケースがある。

【0033】

通常のクラウド・コンピューティングクラスタ・ノードでは、コンテナ・オーケストレーション・システムのAPIが管理ノードにデプロイされる一方、コンテナ・オーケストレーション・システムのノード・エージェントとコンテナ・エンジンはワーカー・ノードにデプロイされる。ユーザーがコンテナを作成する必要がある場合は、管理ノードに位置するコンテナ・オーケストレーション・システムのAPIにコマンドを送信するだけでよく、コンテナ・オーケストレーション・システムのAPIは、ノード・エージェントを介して実際のコンテナ作成、起動、管理作業を完了するようコンテナ・エンジンに指示する。しかしながら、ワーカー・ノード上のコンテナ・エンジンとコンテナ・オーケストレーション・システムのノード・エージェントには、ワーカー・ノードのCPUとメモリリソースを過剰に消費するという問題がある。オープンソースのContainerdエンジンを例とし、500個のコンテナを作成と起動するには、300メガバイト（M）のメモリ空間を必要とする。これは、特にIoT（Internet Of Things：モノのインターネット）クラスタ空間では、組み込みデバイスをワーカー・ノードとして使用するリソース制約のあるクラスタでは受け入れられない。また、OCIランタイム・サブモジュールまたはLXCサブモジュールだけをワーカー・ノードにデプロイする場合は、コンテナ・オーケストレーション・システムがコンテナ・エンジンを呼び出すのに要求される要件を満たすアダプタモジュールを開発する必要があり、開発負荷が大きくシステムが不安定になるという問題もある。

【0034】

図2は、本開示の実施形態によって提供されるコンテナ・エンジンの構成のブロック図である。図2に示すように、本開示の実施形態は、クラスタ上のコンテナ・エンジンのデプロイ構成を改造し、コンテナ・エンジンを第1の装置201と少なくとも一つの第2の装置202に分割し、第1の装置201と第2の装置202は完全に独立している。

【0035】

ここでは、第1の装置201と第2の装置202との間はマスタースレーブモードであり、例えば、一マスター一スレーブ、一マスター複数スレーブなどである。具体的には、第1の装置201は、管理ノードに設けられたマスター装置であり、第2の装置202は、ワーカー・ノードに設けられたスレーブ装置である。場合によっては、第1の装置201と第2の装置202は同時に管理ノードに設けられてもよく、すなわち管理ノードは作業ノードの機能も担う。

【0036】

第1の装置201と第2の装置202との間は、バス技術、有線ネットワーク技術、無線ネットワーク技術のうちの何れか一つのリンクが採用されてよい。

【0037】

第1の装置201は、コンテナ・エンジン・コアモジュール2011を含み、第2の装置202は、スレーブ・エージェント・モジュール2021、コンテナ・スペーサ・モジュール2022とコンテナ・ランタイム・モジュール2023を含む。

【0038】

コンテナ・エンジン・コアモジュール2011は、APIサブモジュール、クライアント・サブモジュール、コンテナ管理サブモジュール、コンテナ・イメージ管理サブモジュールとマスター・エージェント・サブモジュールを含む。

【0039】

幾つかの例示的な実施形態においては、スレーブ・エージェント・モジュール2021は、通信サブモジュール、イメージ記憶サブモジュールとノード管理サブモジュールを含む。さらなる例示的な実施形態においては、スレーブ・エージェント・モジュール2021は、通信サブモジュールとノード管理サブモジュールを含み、イメージ記憶サブモジュールは、一つの個別モジュールである。さらなる例示的な実施形態においては、スレーブ・エージェント・モジュール2021は、通信サブモジュールとイメージ記憶サブモジュールを含み、ノード管理サブモジュールは、一つの個別モジュールである。さらなる例示的な実施形態においては、スレーブ・エージェント・モジュール2021は、通信サブモジュールを含み、イメージ記憶サブモジュールは、一つの個別モジュールであり、ノード管理サブモジュールも、一つの個別モジュールである。

【0040】

コンテナ・スペーサ・モジュール2022は、入出力転送サブモジュール、コンテナ・リソース回収サブモジュールとコンテナ操作サブモジュールを含む。

【0041】

コンテナ・ランタイム・モジュール2023は、OCIランタイム・サブモジュールまたはLXCサブモジュールを含む。

【0042】

幾つかの例示的な実施形態においては、第1の装置201はリモート・プロシージャ・コール・プロトコル（RPC，Remote Procedure Call Protocol）を採用して第2の装置202と通信しており、つまり、RPCを採用して第2の装置202を呼び出すことで相応の機能を実現する。例えば、マスター・エージェント・サブモジュールはRPCを採用してスレーブ・エージェント・モジュール2021と通信しており、つまり、RPCを採用してスレーブ・エージェント・モジュール2021を呼び出すことで相応の機能を実現する。

【0043】

幾つかの例示的な実施形態においては、第1の装置201と第2の装置202が同時に管理ノードに設けられた場合、第1の装置201はUnixソケット（Sock）またはプロセス間通信（IPC，Inter-Process Communication）を採用して第2の装置202と通信している。例えば、マスター・エージェント・サブモジュールはUnix SockまたはIPCを採用してスレーブ・エージェント・モジュール2021と通信している。

【0044】

幾つかの例示的な実施形態においては、第1の装置201と第2の装置202との間の通信確立はC/Sモデルが採用されている。例えば、第1の装置201をクライアントとし、第2の装置202をサービスとする。このように、第2の装置202は起動後に、第2の装置202のアドレスとポートでリッスンし、第1の装置201はパワーオン後に、第2の装置202のアドレスとポートを取得し、第2の装置202のアドレスとポートに応じて第2の装置202とのリンクを自発的に確立し、第2の装置202に登録する。

【0045】

幾つかの例示的な実施形態においては、イメージ記憶サブモジュールを一つの個別モジュールとする場合、スレーブ・エージェント・モジュール2021とイメージ記憶サブモジュールとの間はIPCを採用して通信している。イメージ記憶サブモジュールをスレーブ・エージェント・モジュール2021の一つのサブモジュールとする場合、イメージ記憶サブモジュールはスレーブ・エージェント・モジュール2021と同じプロセスを共有し、これにより第2の装置202によるプロセスリソースの占有を低減した。

【0046】

幾つかの例示的な実施形態においては、イメージ記憶サブモジュールを一つの個別モジュールとする場合、マスター・エージェント・サブモジュールはRPCを採用してスレーブ・エージェント・モジュール2021の中継によってイメージ記憶サブモジュールと間接的に通信している。さらなる幾つかの例示的な実施形態においては、イメージ記憶サブモジュールを一つの個別モジュールとする場合、マスター・エージェント・サブモジュールはRPCを採用してイメージ記憶サブモジュールと直接通信している。

【0047】

幾つかの例示的な実施形態においては、ノード管理サブモジュールを一つの個別モジュールとする場合、スレーブ・エージェント・モジュール2021とノード管理サブモジュールとの間はIPCを採用して通信している。ノード管理サブモジュールをスレーブ・エージェント・モジュール2021の一つのサブモジュールとする場合、ノード管理サブモジュールはスレーブ・エージェント・モジュール2021と同じプロセスを共有し、これにより第2の装置202によるプロセスリソースの占有を低減した。

【0048】

幾つかの例示的な実施形態においては、ノード管理サブモジュールを一つの個別モジュールとする場合、マスター・エージェント・サブモジュールはRPCを採用してスレーブ・エージェント・モジュール2021の中継によってノード管理サブモジュールと間接的に通信している。さらなる幾つかの例示的な実施形態においては、ノード管理サブモジュールを一つの個別モジュールとする場合、マスター・エージェント・サブモジュールはRPCを採用してノード管理サブモジュールと直接通信している。

【0049】

幾つかの例示的な実施形態においては、コンテナ・スペーサ・モジュール2022、コンテナ・ランタイム・モジュール2023、スレーブ・エージェント・モジュール2021はそれぞれ独立プロセスを採用して実現され、コンテナ・スペーサ・モジュール2022はIPCを採用してスレーブ・エージェント・モジュール2021と通信しており、コンテナ・ランタイム・モジュール2023はIPCを採用してスレーブ・エージェント・モジュール2021と通信している。

【0050】

幾つかの例示的な実施形態においては、マスター・エージェント・サブモジュールはttrpcを採用してコンテナ・スペーサ・モジュール2022と直接通信しており、これによりコンテナ操作の速度を加速した。ここで、trpcはオープンソースソフトウェアプロジェクトのコードネームであり、低メモリ環境向けGRPC（GRPC for low-memory environments）などのオープンソースソフトウェアプロジェクトがある。

【0051】

幾つかの例示的な実施形態においては、マスター・エージェント・サブモジュールRPCを採用してスレーブ・エージェント・モジュール2021の中継によってコンテナ・スペーサ・モジュール2022と間接的に通信している。

【0052】

幾つかの例示的な実施形態においては、コンテナ・スペーサ・モジュール2022がコンテナ・ランタイム・モジュール2023を呼び出してコンテナ操作を行うことで、スレーブ・エージェント・モジュール2021を簡易化した。

【0053】

上述のコンテナ・エンジンアーキテクチャの変更により、コンテナ・エンジンの内部実現方法の一部が変更され、以下では、この変更に基づいたコンテナ・エンジンの内部実現方法について説明するが、以下の方法説明は、コンテナ・エンジンの実現プロセス全体ではなく、変更前のコンテナ・エンジンの内部実現方法とは異なる実現プロセスの一部であり、説明した実現方法は、変更後のコンテナ・エンジンの実現プロセスを限定するために使用されるものではない。

【0054】

図3は、本開示の一実施形態によって提供される、管理ノードに適用されるコンテナ・エンジンの実現方法のフローチャート図である。

【0055】

第一の様態においては、図3を参照すれば、本開示の一実施形態は、管理ノードに設けられた第1の装置に適用されるコンテナ・エンジンの実現方法を提供し、当該方法は、ステップ300とステップ301を含む。

【0056】

ステップ300：通信プロトコルを採用して、コンテナ操作要求を第2の装置を送信する。

【0057】

幾つかの例示的な実施形態においては、通信プロトコルは、RPC、ソケット、IPCの何れか一つを含む。具体的には、第1の装置と第2の装置が同時に管理ノードに設けられた場合は、採用される通信プロトコルはソケットまたはIPCであってよく、第1の装置が管理ノードに設けられ、第2の装置がワーカー・ノードに設けられた場合は、採用される通信プロトコルはRPCであってよい。

【0058】

幾つかの例示的な実施形態においては、コンテナ・オーケストレーション・システムが送信したAPI要求を受信した時に、API要求で要求された内容に応じて通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信することができる。API要求で要求されたのがコンテナ操作である場合、コンテナ操作を実現するために、通信プロトコルを直接用いてコンテナ操作要求を第2の装置へ送信することもできるし、コンテナ・イメージ操作を実現するために、まず通信プロトコルを採用してコンテナ・イメージ操作要求を第2の装置へ送信し、そして、コンテナ操作を実現するために、通信プロトコルを採用してコンテナ操作要求を第2の装置へ送信することもできる。例えば、コンテナを作成する場合、まずコンテナ・イメージを作成し、それからコンテナを作成する必要がある。コンテナを作成する必要がある場合、API要求を先に送信してコンテナ・イメージの作成を実現し、それからAPI要求を送信してコンテナの作成を実現することもできるし、1つのAPI要求のみを送信してコンテナ・イメージとコンテナの作成を実現することもできる。

【0059】

幾つかの例示的な実施形態においては、Unixにおいてソケットファイルまたは指定ネットワークポートによってAPI要求をリッスンすることができる。

【0060】

幾つかの例示的な実施形態においては、コンテナ操作は、コンテナ作成、コンテナ削除、コンテナ実行、コンテナ停止、コンテナ一時停止、コンテナ再開、コンテナ内新規プロセス作成、コンテナ情報照会などの少なくとも一つを含む。

【0061】

幾つかの例示的な実施形態においては、コンテナ・イメージ操作は、コンテナ・イメージ作成、コンテナミラー削除、コンテナミラー情報照会、フォーマット変換、コンテナ読み書き層作成などの少なくとも一つを含む。

【0062】

ステップ301：通信プロトコルを採用して、第2の装置が送信したコンテナ操作応答を受信する。

【0063】

幾つかの例示的な実施形態においては、通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信するステップの前に、当該方法は、
通信プロトコルを採用して、ノード・ステータス照会要求を第2の装置へ送信し、通信プロトコルを採用して、第2の装置が送信したノード・ステータス情報を含んだノード・ステータス照会応答を受信するステップと、
通信プロトコルを採用して、第1のノード・リソース申請要求を第2の装置へ送信し、通信プロトコルを採用して、第2の装置が送信した第1のノード・リソース申請応答を受信するステップと、
通信プロトコルを採用して、第2のノード・リソース申請要求を第2の装置へ送信し、通信プロトコルを採用して、第2の装置が送信した第2のノード・リソース申請応答を受信するステップと、
通信プロトコルを採用して、コンテナ・イメージ操作要求を第2の装置へ送信し、通信プロトコルを採用して、第2の装置が送信したコンテナ・イメージ操作応答を受信するステップとのうちの少なくとも一つをさらに含む。

【0064】

幾つかの例示的な実施形態においては、コンテナ・オーケストレーション・システムが送信したAPI要求を受信した時に、API要求で要求された内容に応じて通信プロトコルを採用して、コンテナ・イメージ操作要求を第2の装置へ送信することができる。
幾つかの例示的な実施形態においては、当該方法は、
標準入力、標準エラーと標準出力のリンク・タイプを示すコンソール・タイプ・パラメータを受信するステップと、
通信プロトコルを採用して、コンソール・タイプ・パラメータをコンテナ作成要求またはプロセス作成要求に含ませて第2の装置に送信するステップと、をさらに含む。

【0065】

幾つかの例示的な実施形態においては、標準入力、標準エラーと標準出力のリンク・タイプは、標準入力、標準エラーと標準出力を指定コンソールにリンクすることと、標準入力、標準エラーと標準出力を指定ファイルにリンクすることと、リンクしないこととを含む。

【0066】

幾つかの例示的な実施形態においては、コンソール・タイプ・パラメータは、コンテナ・オーケストレーション・システムまたは他の外部システムによって、第1の装置へ送信されてよい。

【0067】

幾つかの例示的な実施形態においては、コンソール・タイプ・パラメータが、標準入力、標準エラーと標準出力を指定コンソールにリンクすることを示すために使用される場合、当該方法は、
通信プロトコルを採用して、第1の装置のポートをコンテナ作成要求またはプロセス作成要求に含ませて第2の装置に送信するステップと、
通信プロトコルを採用して、コンテナの標準入力を第1の装置のポートによって第2の装置に送信するステップと、
第2の装置が送信したコンテナの標準出力と標準エラーを受信するために、通信プロトコルを採用して、第1の装置のポートをリッスンし、コンテナの標準出力と標準エラーを指定コンソールに出力するステップと、をさらに含む。

【0068】

幾つかの例示的な実施形態においては、コンソール・タイプ・パラメータが、標準入力、標準エラーと標準出力を指定ファイルにリンクすることを示すために使用される場合、当該方法は、
通信プロトコルを採用して、指定ファイルのファイル名をコンテナ作成要求またはプロセス作成要求に含ませて第2の装置に送信するステップをさらに含む。

【0069】

幾つかの例示的な実施形態においては、第1の装置はC/Sモデルを採用して第2の装置との間で通信する時、第1の装置と第2の装置はリンクを確立する必要があり、かつ、第1の装置をクライアントとする時、第2の装置に登録する必要がある。具体的には以下のように実現される。すなわち、通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信するステップの前に、当該方法は、リンクの確立を完了するためには、事前設定された第2の装置のアドレスとポートに基づいて通信プロトコルを採用して、リンク確立要求を第2の装置へ送信し、通信プロトコルを採用して、第2の装置が送信したリンク確立応答を受信するステップと、登録を完了するために、通信プロトコルを採用して、登録コマンドを第2の装置へ送信し、通信プロトコルを採用して、第2の装置が送信した登録応答を受信するステップと、をさらに含む。

【0070】

幾つかの例示的な実施形態においては、第2の装置のアドレスとポートは、配置ファイルに事前配置されてよい。

【0071】

第2の装置が2つ以上である場合、配置ファイルには各第2の装置のアドレスとポートがそれぞれ配置され、第1の装置は各第2の装置とそれぞれリンクを確立するとともに、第2の装置ごとに登録する。

【0072】

幾つかの例示的な実施形態においては、通信プロトコルを採用して、第2の装置が送信した登録応答を受信するステップの後に、当該方法は、ヘルスチェックメカニズムを実現するために、通信プロトコルを採用して、定期的にキープアライブ情報を第2の装置へ送信するステップをさらに含む。

【0073】

幾つかの例示的な実施形態においては、第1のノード・リソース申請要求を第2の装置へ送信するステップの前に、当該方法は、
通信プロトコルを採用して、コンテナ・スペーサ・モジュール作成要求を第2の装置へ送信し、通信プロトコルを採用して、第2の装置が送信したコンテナ・スペーサ・モジュール作成応答を受信するステップをさらに含む。

【0074】

幾つかの例示的な実施形態においては、コンテナ・スペーサ・モジュール作成応答は、コンテナ・スペーサ・モジュールのポートを含む。

【0075】

図4は、本開示の別の実施形態によって提供される、ワーカー・ノードに適用されるコンテナ・エンジンの実現方法のフローチャート図である。

【0076】

第二の様態においては、図4を参照すれば、本開示の別の実施形態は、管理ノードまたはワーカー・ノードに設けられた第2の装置に適用されるコンテナ・エンジンの実現方法を提供し、当該方法は、ステップ400とステップ401を含む。

【0077】

ステップ400：通信プロトコルを採用して、第1の装置が送信したコンテナ操作要求を受信し、コンテナ操作を行う。

【0078】

幾つかの例示的な実施形態においては、通信プロトコルは、RPC、ソケット、IPCの何れか一つを含む。具体的には、第1の装置と第2の装置が同時に管理ノードに設けられた場合は、採用される通信プロトコルはソケットまたはIPCであってよく、第1の装置が管理ノードに設けられ、第2の装置がワーカー・ノードに設けられた場合は、採用される通信プロトコルはRPCであってよい。

【0079】

幾つかの例示的な実施形態においては、コンテナ操作は、コンテナ作成、コンテナ削除、コンテナ実行、コンテナ停止、コンテナ一時停止、コンテナ再開、コンテナ内新規プロセス作成、コンテナ情報照会などの少なくとも一つを含む。

【0080】

ステップ401：通信プロトコルを採用して、コンテナ操作応答を第1の装置へ送信する。

【0081】

幾つかの例示的な実施形態においては、通信プロトコルを採用して、第1の装置が送信したコンテナ操作要求を受信するステップの前に、当該方法は、
通信プロトコルを採用して、第1の装置が送信したノード・ステータス照会要求を受信し、ノード・ステータス情報を照会し、通信プロトコルを採用して、ノード・ステータス情報を含むノード・ステータス照会応答を第1の装置へ送信するステップ、
通信プロトコルを採用して、第1の装置が送信した第1のノード・リソース申請要求を受信し、第1の装置のために第1のノード・リソースを割り当て、通信プロトコルを採用して、第1のノード・リソース申請応答を第1の装置へ送信するステップ、
通信プロトコルを採用して、第1の装置が送信した第2のノード・リソース申請要求を受信し、第1の装置のために第2のノード・リソースを割り当て、通信プロトコルを採用して、第2のノード・リソース申請応答を第1の装置へ送信するステップ、
通信プロトコルを採用して、第1の装置が送信したコンテナ・イメージ操作要求を受信し、コンテナ・イメージ操作を行い、通信プロトコルを採用して、コンテナ・イメージ操作応答を第1の装置へ送信するステップのうちの少なくとも一つをさらに含む。

【0082】

幾つかの例示的な実施形態においては、コンテナ・イメージ操作は、コンテナ・イメージ作成、コンテナミラー削除、コンテナミラー情報照会、フォーマット変換、コンテナ読み書き層作成などの少なくとも一つを含む。

【0083】

幾つかの例示的な実施形態においては、当該方法は、
通信プロトコルを採用して、第1の装置が送信したコンソール・タイプ・パラメータであって、標準入力、標準エラーと標準出力のリンク・タイプを示すコンソール・タイプ・パラメータを受信するステップをさらに含む。

【0084】

幾つかの例示的な実施形態においては、コンソール・タイプ・パラメータが、標準入力、標準エラーと標準出力を指定コンソールにリンクすることを示すために使用される場合、当該方法は、
通信プロトコルを採用して、第1の装置が送信した第1の装置のポートを受信するステップと、
通信プロトコルを採用して、第1の装置のポートによって第1の装置が送信したコンテナの標準入力を受信し、コンテナの標準入力をコンテナに入力するステップと、
コンテナの標準出力と標準エラーを受信し、通信プロトコルを採用して、コンテナの標準出力と標準エラーを第1の装置のポートによって第1の装置に送信するステップと、をさらに含む。

【0085】

幾つかの例示的な実施形態においては、コンソール・タイプ・パラメータが、標準入力、標準エラーと標準出力を指定ファイルにリンクすることを示すために使用される場合、当該方法は、
通信プロトコルを採用して、第1の装置が送信した指定ファイルのファイル名を受信するステップと、
受信した指定ファイルのファイル名をファイル名として指定ファイルを作成し、コンテナの標準入力と標準エラーを指定ファイルに書き込むステップとをさらに含む。

【0086】

幾つかの例示的な実施形態においては、第1の装置と第2の装置との間でC/Sモデルを採用して通信する時、第1の装置と第2の装置はリンクを確立する必要があり、かつ、第1の装置をクライアントとする時、第2の装置に登録する必要がある。具体的には以下のように実現される。すなわち、通信プロトコルを採用して、第1の装置が送信したコンテナ操作要求を受信するステップの前に、当該方法は、リンクの確立を完了するために、第1の装置が送信したリンク確立要求を受信するために、通信プロトコルを採用して、事前設定された第2の装置のアドレスとポートをリッスンし、通信プロトコルを採用して、リンク確立応答を第1の装置へ送信するステップと、登録を完了するために、通信プロトコルを採用して、第1の装置が送信した登録コマンドを受信し、登録コマンドを実行し、通信プロトコルを採用して、登録応答を第1の装置へ送信するステップとをさらに含む。

【0087】

幾つかの例示的な実施形態においては、第2の装置のアドレスとポートは事前配置されてよい。具体的な配置方法は特に限定されず、例えば配置ファイルに配置することもできる。

【0088】

第2の装置が2つ以上である場合、配置ファイルには各第2の装置のアドレスとポートがそれぞれ配置され、第1の装置は各第2の装置とそれぞれリンクを確立するとともに、第2の装置ごとに登録する。

【0089】

幾つかの例示的な実施形態においては、通信プロトコルを採用して、登録応答を第1の装置へ送信するステップの後に、当該方法は、ヘルスチェックメカニズムを実現するために、通信プロトコルを採用して、第1の装置が送信したキープアライブ情報を定期的に受信するステップをさらに含む。

【0090】

幾つかの例示的な実施形態においては、第1の装置が送信した第1のノード・リソース申請要求を受信するステップの前に、当該方法は、
通信プロトコルを採用して、第1の装置が送信したコンテナ・スペーサ・モジュール作成要求を受信し、コンテナ・スペーサ・モジュールを作成し、通信プロトコルを採用して、コンテナ・スペーサ・モジュール作成応答を第1の装置へ送信するステップをさらに含む。
幾つかの例示的な実施形態においては、コンテナ・スペーサ・モジュール作成応答は、コンテナ・スペーサ・モジュールのポートを含む。

【0091】

第三の様態において、本開示の別の実施形態は、少なくとも1つのプロセッサと、少なくとも1つのプログラムが記憶され、少なくとも1つのプログラムが少なくとも1つのプロセッサによって実行されると、前記何れか一つのコンテナ・エンジンの実現方法を実現するメモリと、を備える電子機器を提供する。

【0092】

ここで、プロセッサは、データ処理能力を有するデバイスであり、これには、中央処理装置(CPU)などが含まれるが、これらに限定されない。メモリは、ランダムアクセスメモリ(RAM、より具体的にはSDRAM、DDRなど)、リードオンリーメモリ(ROM)、電気的消去可能プログラマブルリードオンリーメモリ(EEPROM)、フラッシュメモリ(FLASH)を含むが、これらに限定されないデータ記憶能力を有する装置である。

【0093】

幾つかの実施形態では、プロセッサ、メモリはバスを介して互いに接続され、更に、コンピューティングデバイスの他のコンポーネントに接続されている。

【0094】

第四の様態において、本開示の別の実施形態は、コンピュータプログラムが記憶されたコンピュータ可読な記憶媒体であって、コンピュータプログラムがプロセッサによって実行されると、上記何れか一つのコンテナ・エンジンの実現方法を実現するコンピュータ可読な記憶媒体を提供する。

【0095】

図2に示すように、第五の様態において、本開示の別の実施形態は、第1の装置201と第2の装置202を含むコンテナ・エンジンを提供し、第1の装置は管理ノードに設けられ、第2の装置は管理ノードまたはワーカー・ノードに設けられている。

【0096】

ここでは、第1の装置は、コンテナ操作要求をマスター・エージェント・サブモジュールへ送信するように配置されるコンテナ管理サブモジュールと、通信プロトコルを採用して、コンテナ操作要求を第2の装置のコンテナ操作サブモジュールへ送信し、通信プロトコルを採用して、第2の装置のコンテナ操作サブモジュールが送信したコンテナ操作応答を受信するように配置されるマスター・エージェント・サブモジュールとを有するコンテナ・エンジン・コアモジュール2011を備える。

【0097】

ここでは、第2の装置202は、通信プロトコルを採用して、第1の装置201のマスター・エージェント・サブモジュールが送信したコンテナ操作要求を受信し、コンテナ操作要求をコンテナ・ランタイム・モジュール2023に送信するように配置される前記コンテナ操作サブモジュールを含むコンテナ・スペーサ・モジュール2022と、コンテナ操作を行い、コンテナ操作応答をコンテナ操作サブモジュールへ送信するように配置されるコンテナ・ランタイム・モジュール2023と、を備え、コンテナ操作サブモジュールはさらに、通信プロトコルを採用して、コンテナ操作応答を第1の装置201のマスター・エージェント・サブモジュールへ送信するように配置される。

【0098】

幾つかの例示的な実施形態においては、マスター・エージェント・サブモジュールはttrpcを採用してコンテナ・スペーサ・モジュール2022と直接通信しており、これによりコンテナ操作の速度を加速した。

【0099】

さらなる例示的な実施形態においては、マスター・エージェント・サブモジュールはRPCを採用してスレーブ・エージェント・モジュール2021の中継によってコンテナ・スペーサ・モジュール2022と間接的に通信している。この場合には、第2の装置202は、スレーブ・エージェント・モジュール2021をさらに含み、スレーブ・エージェント・モジュール2021は、通信プロトコルを採用して、マスター・エージェント・サブモジュールとの間の通信を実現するように配置される通信サブモジュールを含む。

【0100】

幾つかの例示的な実施形態においては、第1の装置と第2の装置との間でC/Sモデルを採用して通信する時、第1の装置と第2の装置はリンクを確立する必要があり、かつ、第1の装置をクライアントとする時、第2の装置に登録する必要がある。具体的には以下のように実現される。すなわち、マスター・エージェント・サブモジュールはさらに、事前設定されたスレーブ・エージェント・モジュール2021のアドレスとポートに応じて、通信プロトコルを採用して、リンク確立要求をスレーブ・エージェント・モジュール2021へ送信し、通信プロトコルを採用して、スレーブ・エージェント・モジュール2021が送信したリンク確立応答を受信し、これによりリンクの確立を完了し、通信プロトコルを採用して、登録コマンドをスレーブ・エージェント・モジュール2021へ送信し、通信プロトコルを採用して、スレーブ・エージェント・モジュール2021が送信した登録応答を受信し、これにより登録を完了するように配置される。

【0101】

第2の装置202は、通信プロトコルを採用して、事前設定されたスレーブ・エージェント・モジュール2021のアドレスとポートをリッスンすることで、マスター・エージェント・サブモジュールが送信したリンク確立要求を受信し、通信プロトコルを採用して、リンク確立応答をマスター・エージェント・サブモジュールへ送信することでリンクの確立を完了し、通信プロトコルを採用して、マスター・エージェント・サブモジュールが送信した登録コマンドを受信し、登録コマンドを実行し、通信プロトコルを採用して、登録応答をマスター・エージェント・サブモジュールへ送信することで、登録を完了するように配置されるスレーブ・エージェント・モジュール2021をさらに含む。

【0102】

幾つかの例示的な実施形態においては、スレーブ・エージェント・モジュール2021のアドレスとポートは配置ファイルに事前配置されてよい。

【0103】

第2の装置が2つ以上である場合、配置ファイルには各第2の装置のアドレスとポートがそれぞれ配置され、第1の装置は各第2の装置とそれぞれリンクを確立するとともに、第2の装置ごとに登録する。

【0104】

幾つかの例示的な実施形態においては、マスター・エージェント・サブモジュールはさらに、ヘルスチェックメカニズムを実現するために、通信プロトコルを採用して、定期的にキープアライブ情報をスレーブ・エージェント・モジュール2021へ送信するように配置される。スレーブ・エージェント・モジュール2021はさらに、ヘルスチェックメカニズムを実現するために、通信プロトコルを採用して、第1の装置のマスター・エージェント・サブモジュールが送信したキープアライブ情報を定期的に受信するように配置される。

【0105】

幾つかの例示的な実施形態においては、第1の装置201のコンテナ・エンジン・コアモジュール2011は、コンテナ・オーケストレーション・システムが送信したAPI要求を受信し、API要求で要求された内容に応じてコンテナ操作要求をコンテナ管理サブモジュールへ送信するか、またはコンテナ・イメージ操作要求をコンテナ・イメージ管理サブモジュールへ送信するように配置されるAPIサブモジュールと、APIサブモジュールが送信したコンテナ・イメージ操作要求を受信し、通信プロトコルを採用して、コンテナ・イメージ操作要求を第2の装置のイメージ記憶サブモジュールへ送信し、通信プロトコルを採用して、第2の装置のイメージ記憶サブモジュールが送信したコンテナ・イメージ操作応答を受信するように配置されるコンテナ・イメージ管理サブモジュールと、をさらに含む。コンテナ管理サブモジュールはさらに、APIサブモジュールが送信したコンテナ操作要求を受信し、通信プロトコルを採用して、コンテナ操作要求を第2の装置のコンテナ操作サブモジュールへ送信し、通信プロトコルを採用して、第2の装置のコンテナ操作サブモジュールが送信したコンテナ操作応答を受信するように配置される。

【0106】

第2の装置202は、スレーブ・エージェント・モジュール2021をさらに含み、スレーブ・エージェント・モジュール2021は、通信プロトコルを採用して、第1の装置のコンテナ・イメージ管理サブモジュールが送信したコンテナ・イメージ操作要求を受信し、コンテナ・イメージ操作を行い、通信プロトコルを採用して、コンテナ・イメージ操作応答を第1の装置のコンテナ・イメージ管理サブモジュールへ送信するように配置されるイメージ記憶サブモジュールを含む。コンテナ操作サブモジュールはさらに、通信プロトコルを採用して、第1の装置のコンテナ管理サブモジュールが送信したコンテナ操作要求を受信し、コンテナ操作を行い、通信プロトコルを採用して、コンテナ操作応答を第1の装置のコンテナ管理サブモジュールへ送信するように配置される。

【0107】

幾つかの例示的な実施形態においては、コンテナ管理サブモジュールはさらに、ノード・ステータス照会要求をマスター・エージェント・サブモジュールへ送信するように配置される。マスター・エージェント・サブモジュールはさらに、通信プロトコルを採用して、ノード・ステータス照会要求を第2の装置のノード管理サブモジュールへ送信し、通信プロトコルを採用して、第2の装置のノード管理サブモジュールが送信した、ノード・ステータス情報を含んだノード・ステータス照会応答を受信し、ノード・ステータス照会応答をコンテナ管理サブモジュールに送信するように配置される。

【0108】

第2の装置202は、スレーブ・エージェント・モジュール2021をさらに含み、スレーブ・エージェント・モジュール2021は、通信プロトコルを採用して、第1の装置のマスター・エージェント・サブモジュールが送信したノード・ステータス照会要求を受信し、ノード・ステータス情報を照会し、通信プロトコルを採用して、ノード・ステータス情報を含んだノード・ステータス照会応答を第1の装置のマスター・エージェント・サブモジュールへ送信するように配置されるノード管理サブモジュールを含む。

【0109】

幾つかの例示的な実施形態においては、コンテナ管理サブモジュールはさらに、第1のノード・リソース申請要求をマスター・エージェント・サブモジュールへ送信するように配置され、マスター・エージェント・サブモジュールはさらに、通信プロトコルを採用して、第1のノード・リソース申請要求を第2の装置のノード管理サブモジュールへ送信し、通信プロトコルを採用して、第2の装置のノード管理サブモジュールが送信した第1のノード・リソース申請応答を受信し、第1のノード・リソース申請応答をコンテナ管理サブモジュールに送信するように配置される。

【0110】

第2の装置202は、スレーブ・エージェント・モジュール2021をさらに含み、スレーブ・エージェント・モジュール2021は、通信プロトコルを採用して、第1の装置のマスター・エージェント・サブモジュールが送信した第1のノード・リソース申請要求を受信し、第1の装置のために第1のノード・リソースを割り当て、通信プロトコルを採用して、第1のノード・リソース申請応答を第1の装置のマスター・エージェント・サブモジュールへ送信するように配置されるノード管理サブモジュールを含む。

【0111】

幾つかの例示的な実施形態においては、コンテナ管理サブモジュールはさらに、第2のノード・リソース申請要求をマスター・エージェント・サブモジュールへ送信するように配置され、マスター・エージェント・サブモジュールはさらに、通信プロトコルを採用して、第2のノード・リソース申請要求を第2の装置のノード管理サブモジュールへ送信し、通信プロトコルを採用して、第2の装置のノード管理サブモジュールが送信した第2のノード・リソース申請応答を受信し、第2のノード・リソース申請応答をコンテナ管理サブモジュールに送信するように配置される。

【0112】

第2の装置202は、スレーブ・エージェント・モジュール2021をさらに含み、スレーブ・エージェント・モジュール2021は、通信プロトコルを採用して、第1の装置のマスター・エージェント・サブモジュールが送信した第2のノード・リソース申請要求を受信し、第1の装置のために第2のノード・リソースを割り当て、通信プロトコルを採用して、第2のノード・リソース申請応答を第1の装置のマスター・エージェント・サブモジュールへ送信するように配置されるノード管理サブモジュールを含む。

【0113】

幾つかの例示的な実施形態においては、コンテナ・エンジン・コアモジュール2011は、標準入力、標準エラーと標準出力のリンク・タイプを示すコンソール・タイプ・パラメータを受信し、コンソール・タイプ・パラメータをコンテナ管理サブモジュールに送信するように配置されるクライアント・サブモジュールをさらに含む。コンテナ管理サブモジュールはさらに、コンソール・タイプ・パラメータをマスター・エージェント・サブモジュールに送信するように配置される。マスター・エージェント・サブモジュールはさらに、通信プロトコルを採用して、コンソール・タイプ・パラメータをコンテナ作成要求またはプロセス作成要求に含ませて第2の装置の入出力転送サブモジュールに送信するために使用される。

【0114】

コンテナ・スペーサ・モジュール2022は、コンソール・タイプ・パラメータを受信し、コンソール・タイプ・パラメータをコンテナ操作サブモジュールに送信するように配置される入出力転送サブモジュールをさらに含む。

【0115】

幾つかの例示的な実施形態においては、コンテナ管理サブモジュールはさらに、コンソール・タイプ・パラメータが、標準入力、標準エラーと標準出力を指定コンソールにリンクすることを示すために使用される場合、コンテナ管理サブモジュールのポートをマスター・エージェント・サブモジュールに送信するように配置される。マスター・エージェント・サブモジュールはさらに、通信プロトコルを採用して、コンテナ管理サブモジュールのポートをコンテナ作成要求またはプロセス作成要求に含ませて第2の装置の入出力転送サブモジュールに送信し、通信プロトコルを採用して、コンテナの標準入力をコンテナ管理サブモジュールのポートによって第2の装置の入出力転送サブモジュールに送信し、第2の装置の入出力転送サブモジュールが送信したコンテナの標準出力と標準エラーを受信するために、通信プロトコルを採用して、コンテナ管理サブモジュールのポートをリッスンし、コンテナの標準出力と標準エラーをコンテナ管理サブモジュールに送信するように配置される。コンテナ管理サブモジュールはさらに、コンテナの標準出力と標準エラーを指定コンソールに出力するように配置される。

【0116】

入出力転送サブモジュールはさらに、コンソール・タイプ・パラメータが、標準入力、標準エラーと標準出力を指定コンソールにリンクすることを示すために使用される場合、通信プロトコルを採用して、第1の装置のマスター・エージェント・サブモジュールが送信したコンテナ管理サブモジュールのポートを受信し、通信プロトコルを採用して、コンテナ管理サブモジュールのポートによって第1の装置のマスター・エージェント・サブモジュールが送信したコンテナの標準入力を受信し、コンテナの標準入力をコンテナ操作サブモジュールに送信し、コンテナの標準出力と標準エラーをコンテナ管理サブモジュールのポートによってコンテナ管理サブモジュールに送信するように配置される。

【0117】

コンテナ操作サブモジュールはさらに、コンテナの標準入力をコンテナに入力し、コンテナの標準出力と標準エラーを受信し、コンテナの標準出力と標準エラーを入出力転送サブモジュールに送信するように配置される。

【0118】

幾つかの例示的な実施形態においては、コンテナ管理サブモジュールはさらに、コンソール・タイプ・パラメータが、標準入力、標準エラーと標準出力を指定ファイルにリンクすることを示すために使用される場合、コンソール・タイプ・パラメータをマスター・エージェント・サブモジュールに送信するように配置される。マスター・エージェント・サブモジュールはさらに、通信プロトコルを採用して、指定ファイルのファイル名をコンテナ作成要求またはプロセス作成要求に含ませて第2の装置の入出力転送サブモジュールに送信するように配置される。

【0119】

入出力転送サブモジュールはさらに、コンソール・タイプ・パラメータが、標準入力、標準エラーと標準出力を指定ファイルにリンクすることを示すために使用される場合、通信プロトコルを採用して、第1の装置が送信した指定ファイルのファイル名を受信し、受信した指定ファイルのファイル名をファイル名として指定ファイルを作成し、指定ファイルのファイル名をコンテナ操作サブモジュールに送信するように配置される。コンテナ操作サブモジュールはさらに、コンテナの標準入力と標準エラーを指定ファイルに書き込むように配置される。

【0120】

本開示の実施形態によって提供されるコンテナ・エンジンは、コンテナ・エンジンを第1の装置と第2の装置とに分割して実現し、第1の装置を管理ノードに設け、第2の装置を管理ノードまたはワーカー・ノードに設け、コンテナ・エンジンオーケストレーションシステムをコンテナ・エンジンにドッキングさせる方式を変えることなくコンテナ・エンジン・コアモジュールを第1の装置に保持し、かつ、コンテナ・スペーサ・モジュールとコンテナ・ランタイム・モジュールを第2の装置に保持する。コンテナ・スペーサ・モジュールとコンテナ・ランタイム・モジュールのリソースの消費が小さく、コンテナ・エンジン・コアモジュールのリソースの消費が大きいため、本開示の実施形態は、もとのコンテナ・エンジンオーケストレーションシステムを採用してコンテナ・エンジンをドッキングしながら、ワーカー・ノードのリソースの消費が節約されている。

【0121】

幾つかの例示的な実施形態においては、マスター・エージェント・サブモジュールはさらに、通信プロトコルを採用して、コンテナ・スペーサ・モジュール作成要求を第2の装置の通信サブモジュールへ送信し、通信プロトコルを採用して、第2の装置の通信サブモジュールが送信したコンテナ・スペーサ・モジュール作成応答を受信するように配置される。

【0122】

スレーブ・エージェント・モジュール2021は、通信プロトコルを採用して、第1の装置が送信したコンテナ・スペーサ・モジュール作成要求を受信し、コンテナ・スペーサ・モジュールを作成し、通信プロトコルを採用して、コンテナ・スペーサ・モジュール作成応答を第1の装置へ送信するように配置される通信サブモジュールをさらに含む。

【0123】

当業者は、上文で開示された方法におけるステップ、システム、装置のうちの機能モジュール/ユニットの全て又はいくつかが、ソフトウェア、ファームウェア、ハードウェア、及びそれらの適切な組み合わせとして実行されてもよいことを理解するであろう。ハードウェア実施形態において、上記の説明で言及した機能モジュール／ユニット間の区分は、必ずしも物理的構成要素の区分に対応しない。例えば、1つの物理コンポーネントは複数の機能を有してもよく、1つの機能又はステップは幾つかの物理コンポーネントの協働によって実行されてもよい。いくつかの物理的構成要素またはすべての物理的構成要素は、中央処理装置、デジタル信号プロセッサ、もしくはマイクロプロセッサなどのプロセッサによって実行されるソフトウェアとして、ハードウェアとして、または特定用途向け集積回路などの集積回路として実行され得る。このようなソフトウェアは、コンピュータ記憶媒体(または非一時的媒体)及び通信媒体(または一時的媒体)を含み得るコンピュータ可読媒体上に分散され得る。当業者によく知られているように、コンピュータ記憶媒体という用語は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するための任意の方法または技術で実行される揮発性および不揮発性、取り外し可能および取り外し不可能な媒体を含む。コンピュータ記憶媒体は、RAM、ROM、EEPROM、フラッシュメモリ若しくは他のメモリ技術、CD-ROM、デジタル多用途ディスク(DVD)若しくは他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ若しくは他の磁気メモリ、又は所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る任意の他の媒体を含むが、これらに限定されない。また、通信媒体は、通常、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波もしくは他の搬送メカニズムなどの変調データ信号における他のデータを含み、かつ、任意の情報配信媒体を含み得ることが当業者に知られている。

【0124】

本明細書においては実施形態の例がすでに公開されており、また具体的な用語が用いられているが、それらは一般的な説明的な意味としてのみ使用されており、そう解釈されるべきであり、限定を目的としたものではない。いくつかの実例では、特定の実施形態と組み合わせて説明される特徴、特性、および/または要素は、別途明確に指摘しない限り、単独で、または他の実施例にて説明される特徴、特性、および/または要素と組み合わせて使用され得ることが当業者に明らかであろう。したがって、添付の請求項によって明らかにされている本開示の範囲から逸脱しない限り、様々な形態および細部における変更が行われ得ることを当業者は理解するであろう。

【図1】

【図2】

【図3】

【図4】

【手続補正書】

【提出日】2024-04-18

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

管理ノードに設けられた第1の装置に適用されるコンテナ・エンジンの実現方法であって、
通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信するステップと、
前記通信プロトコルを採用して、前記第2の装置が送信したコンテナ操作応答を受信するステップと、を含むコンテナ・エンジンの実現方法。

【請求項2】

通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信する前記ステップの前に、
前記通信プロトコルを採用して、ノード・ステータス照会要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信した、ノード・ステータス情報を含んだノード・ステータス照会応答を受信するステップと、
前記通信プロトコルを採用して、第1のノード・リソース申請要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信した第1のノード・リソース申請応答を受信するステップと、
前記通信プロトコルを採用して、第2のノード・リソース申請要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信した第2のノード・リソース申請応答を受信するステップと、
前記通信プロトコルを採用して、コンテナ・イメージ操作要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信したコンテナ・イメージ操作応答を受信するステップとのうちの少なくとも一つを含む請求項１に記載のコンテナ・エンジンの実現方法。

【請求項3】

標準入力、標準エラーと標準出力のリンク・タイプを示すコンソール・タイプ・パラメータを受信するステップと、
前記通信プロトコルを採用して、前記コンソール・タイプ・パラメータをコンテナ作成要求またはプロセス作成要求に含ませて前記第2の装置に送信するステップと、
をさらに含む請求項１に記載のコンテナ・エンジンの実現方法。

【請求項4】

前記コンソール・タイプ・パラメータが、前記標準入力、標準エラーと標準出力を指定コンソールにリンクすることを示すために使用される場合、
前記通信プロトコルを採用して、前記第1の装置のポートを前記コンテナ作成要求またはプロセス作成要求に含ませて前記第2の装置に送信するステップと、
前記通信プロトコルを採用して、コンテナの標準入力を前記第1の装置のポートによって前記第2の装置に送信するステップと、
前記第2の装置が送信したコンテナの標準出力と標準エラーを受信するために前記通信プロトコルを採用して前記第1の装置のポートをリッスンし、前記コンテナの標準出力と標準エラーを前記指定コンソールに出力するステップと、をさらに含む請求項３に記載のコンテナ・エンジンの実現方法。

【請求項5】

前記コンソール・タイプ・パラメータが、前記標準入力、標準エラーと標準出力を指定ファイルにリンクすることを示すために使用される場合、
前記通信プロトコルを採用して、前記指定ファイルのファイル名を前記コンテナ作成要求またはプロセス作成要求に含ませて前記第2の装置に送信するステップをさらに含む請求項３に記載のコンテナ・エンジンの実現方法。

【請求項6】

通信プロトコルを採用して、コンテナ操作要求を第2の装置へ送信する前記ステップの前に、
事前設定された前記第2の装置のアドレスとポートに基づいて前記通信プロトコルを採用して、リンク確立要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信したリンク確立応答を受信するステップと、
前記通信プロトコルを採用して、登録コマンドを前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信した登録応答を受信するステップと、をさらに含む請求項１～５のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項7】

第1のノード・リソース申請要求を第2の装置へ送信する前記ステップの前に、
前記通信プロトコルを採用して、コンテナ・スペーサ・モジュール作成要求を前記第2の装置へ送信し、前記通信プロトコルを採用して、前記第2の装置が送信したコンテナ・スペーサ・モジュール作成応答を受信するステップをさらに含む請求項１～５のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項8】

前記コンテナ・スペーサ・モジュール作成応答は、コンテナ・スペーサ・モジュールのポートを含む請求項７に記載のコンテナ・エンジンの実現方法。

【請求項9】

前記通信プロトコルは、リモート・プロシージャ・コール・プロトコルRPC、ソケット、プロセス間通信IPCの何れか一つを含む、請求項１～５のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項10】

管理ノードまたはワーカー・ノードに設けられた第2の装置に適用されるコンテナ・エンジンの実現方法であって、
通信プロトコルを採用して、第1の装置が送信したコンテナ操作要求を受信し、コンテナ操作を行うステップと、
前記通信プロトコルを採用して、コンテナ操作応答を前記第1の装置へ送信するステップと、を含むコンテナ・エンジンの実現方法。

【請求項11】

通信プロトコルを採用して、前記第1の装置が送信したコンテナ操作要求を受信する前記ステップの前に、
前記通信プロトコルを採用して、前記第1の装置が送信したノード・ステータス照会要求を受信し、ノード・ステータス情報を照会し、前記通信プロトコルを採用して、前記ノード・ステータス情報を含むノード・ステータス照会応答を前記第1の装置へ送信するステップ、
前記通信プロトコルを採用して、第1の装置が送信した第1のノード・リソース申請要求を受信し、前記第1の装置のために第1のノード・リソースを割り当て、前記通信プロトコルを採用して、第1のノード・リソース申請応答を前記第1の装置へ送信するステップ、
前記通信プロトコルを採用して、前記第1の装置が送信した第2のノード・リソース申請要求を受信し、前記第1の装置のために第2のノード・リソースを割り当て、前記通信プロトコルを採用して、第2のノード・リソース申請応答を前記第1の装置へ送信するステップ、または
前記通信プロトコルを採用して、前記第1の装置が送信したコンテナ・イメージ操作要求を受信し、コンテナ・イメージ操作を行い、前記通信プロトコルを採用して、コンテナ・イメージ操作応答を前記第1の装置へ送信するステップのうちの少なくとも一つをさらに含む請求項１０に記載のコンテナ・エンジンの実現方法。

【請求項12】

前記通信プロトコルを採用して、前記第1の装置が送信したコンソール・タイプ・パラメータであって、標準入力、標準エラーと特徴付け出力のリンク・タイプを示す前記コンソール・タイプ・パラメータを受信するステップをさらに含む請求項１０に記載のコンテナ・エンジンの実現方法。

【請求項13】

前記コンソール・タイプ・パラメータが、前記標準入力、標準エラーと標準出力を指定コンソールにリンクすることを示すために使用される場合、
前記通信プロトコルを採用して、前記第1の装置が送信した、前記第1の装置のポートを受信するステップと、
前記通信プロトコルを採用して、前記第1の装置のポートによって前記第1の装置が送信したコンテナの標準入力を受信し、前記コンテナの標準入力を前記コンテナに入力するステップと、
コンテナの標準出力と標準エラーを受信し、前記通信プロトコルを採用して、前記コンテナの標準出力と標準エラーを前記第1の装置のポートによって前記第1の装置に送信するステップと、をさらに含む請求項１２に記載のコンテナ・エンジンの実現方法。

【請求項14】

前記コンソール・タイプ・パラメータが、前記標準入力、標準エラーと標準出力を指定ファイルにリンクすることを示すために使用される場合、
前記通信プロトコルを採用して、前記第1の装置が送信した、前記指定ファイルのファイル名を受信するステップと、
受信した前記指定ファイルのファイル名をファイル名として前記指定ファイルを作成し、コンテナの標準入力と標準エラーを前記指定ファイルに書き込むステップとをさらに含む請求項１２に記載のコンテナ・エンジンの実現方法。

【請求項15】

通信プロトコルを採用して、前記第1の装置が送信したコンテナ操作要求を受信する前記ステップの前に、
前記第1の装置が送信したリンク確立要求を受信するために、前記通信プロトコルを採用して、事前設定された、前記第2の装置のアドレスとポートをリッスンし、前記通信プロトコルを採用して、リンク確立応答を前記第1の装置へ送信するステップと、
前記通信プロトコルを採用して、前記第1の装置が送信した登録コマンドを受信し、前記登録コマンドを実行し、前記通信プロトコルを採用して、登録応答を前記第1の装置へ送信するステップとをさらに含む請求項１０～１４のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項16】

第1の装置が送信した第1のノード・リソース申請要求を受信する前記ステップの前に、
前記通信プロトコルを採用して、前記第1の装置が送信したコンテナ・スペーサ・モジュール作成要求を受信し、コンテナ・スペーサ・モジュールを作成し、前記通信プロトコルを採用して、コンテナ・スペーサ・モジュール作成応答を前記第1の装置へ送信するステップをさらに含む請求項１０～１４のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項17】

前記コンテナ・スペーサ・モジュール作成応答は、コンテナ・スペーサ・モジュールのポートを含む請求項１６に記載のコンテナ・エンジンの実現方法。

【請求項18】

前記通信プロトコルは、リモート・プロシージャ・コール・プロトコルRPC、ソケット、プロセス間通信IPCの何れか一つを含む請求項１０～１４のいずれか一項に記載のコンテナ・エンジンの実現方法。

【請求項19】

管理ノードに設けられた第1の装置と、管理ノードまたはワーカー・ノードに設けられた第2の装置とを含むコンテナ・エンジンであって、
前記第1の装置は、
コンテナ操作要求をマスター・エージェント・サブモジュールへ送信するように配置されるコンテナ管理サブモジュールと、
通信プロトコルを採用して、コンテナ操作要求を前記第2の装置のコンテナ操作サブモジュールへ送信し、前記通信プロトコルを採用して、前記第2の装置のコンテナ操作サブモジュールが送信したコンテナ操作応答を受信するように配置されるマスター・エージェント・サブモジュールと、
を有するコンテナ・エンジン・コアモジュールを備え、
前記第2の装置は、
前記通信プロトコルを採用して、前記第1の装置のマスター・エージェント・サブモジュールが送信したコンテナ操作要求を受信し、前記コンテナ操作要求をコンテナ・ランタイム・モジュールに送信するように配置される前記コンテナ操作サブモジュールを含むコンテナ・スペーサ・モジュールと、
コンテナ操作を行い、コンテナ操作応答を前記コンテナ操作サブモジュールへ送信するように配置されるコンテナ・ランタイム・モジュールと、
を備え、
前記コンテナ操作サブモジュールはさらに、前記通信プロトコルを採用して、コンテナ操作応答を前記第1の装置のマスター・エージェント・サブモジュールへ送信するようにさらに配置されるコンテナ・エンジン。

【請求項20】

前記第1の装置と前記第2の装置との間はバス技術、有線ネットワーク技術、無線ネットワーク技術のうちの何れか一つのリンクが採用される請求項１９に記載のコンテナ・エンジン。

【手続補正3】

【補正対象書類名】明細書

【補正対象項目名】０００１

【補正方法】変更

【補正の内容】

【0001】

本開示は2021年10月18日に国家知識産権局へ提出された出願番号をCN202111212628.4とし、発明の名称を「コンテナ・エンジン及びコンテナ・エンジンの実現方法、電子機器、記憶媒体」とする中国特許出願の優先権を主張し、これら出願の全ての内容を援用によって引用することとする。

【手続補正4】

【補正対象書類名】明細書

【補正対象項目名】０００２

【補正方法】変更

【補正の内容】

【0002】

本開示の実施形態は、クラウド・コンピューティング・コンテナ技術分野に関するものであるが、これに限定されるものではなく、具体的には、コンテナ・エンジン及びコンテナ・エンジンの実現方法に関するものである。

【手続補正5】

【補正対象書類名】明細書

【補正対象項目名】０００５

【補正方法】変更

【補正の内容】

【0005】

本開示の実施形態は、コンテナ・エンジン及びコンテナ・エンジンの実現方法を提供する。

【国際調査報告】