JP2024501005A - コンテナクラスタのための管理方法および装置 - Google Patents

Abstract

本出願の実施形態は、コンテナクラスタのための管理方法を提供する。この方法は、コンテナクラスタ管理ＣＣＭがコンテナクラスタのインスタンス化要求メッセージを管理エンティティから受信することであって、要求メッセージはコンテナクラスタのインスタンス化パラメータを保持するものであることと、ＣＣＭがコンテナクラスタのインスタンス化パラメータに基づいてコンテナクラスタをインスタンス化することとを含み、コンテナクラスタのインスタンス化パラメータは、管理エンティティによって、コンテナクラスタ記述子ＣＣＤにアクセスすることによって決定される。本発明の実施形態の解決法を用いて、コンテナクラスタ記述子テンプレートおよびコンテナクラスタノード記述子テンプレートが定義され、コンテナクラスタのための動的管理がサポートされて、大規模コンテナクラスタの一貫性のある展開およびバッチ複製が実装される。

Description

本出願は、通信分野に関し、特に、コンテナクラスタのための管理方法および装置に関する。

ネットワーク機能仮想化（ＮＦＶ，Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）は、遠隔通信ネットワークオペレータが、ネットワークの資本費用ＣＡＰＥＸおよび運用費用ＯＰＥＸを節約する目標を達成しながらネットワークサービス（ＮＳ，Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ）の高速で効率的な展開および運用を実装するために、情報技術（ＩＴ，Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）の分野における仮想化技術を使用して、汎用サーバ、スイッチ、およびメモリにおける遠隔通信ネットワーク機能の一部（コアネットワーク機能など）の実装に際してソフトウェアとハードウェアとの切離しを実施することを意味する。ＮＦＶ技術を適用することによって、遠隔通信ネットワーク機能は、ソフトウェアの形で実装され、汎用サーバハードウェア上で稼働されることが可能であり、および新しいデバイスのインストールなしに必要に応じて、ネットワークの種々の物理位置に移行されること、これらの位置でインスタンス化（ｉｎｓｔａｎｔｉａｔｉｏｎ）されること、またはこれらの位置で展開されることが可能である。

ＮＦＶの標準化作業は、ネットワークサービスと、仮想化ネットワーク機能（ＶＮＦ，Ｖｉｒｔｕａｌｉｚｅｄ Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ）と、仮想リソースの動的な管理およびオーケストレーション（ＭＡＮＯ，Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｏｒｃｈｅｓｔｒａｔｉｏｎ）とに主に焦点を合わせており、ＭＡＮＯフレームワークにおける機能策定作業は、欧州電気通信標準化機構（ＥＴＳＩ，Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）の下でＮＦＶ業界標準部会のインタフェースおよびアーキテクチャ（ＩＦＡ，ＩｎｔｅｒＦａｃｅ ａｎｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）作業部会によって完了されており、および図１にＮＦＶの機能アーキテクチャが示されており、ＮＦＶシステム１００は、以下の機能エンティティを主に備える。

ＮＦＶオーケストレータ（ＮＦＶ ｏｒｃｈｅｓｔｒａｔｏｒ，ＮＦＶＯ）１０２：ＮＳのライフサイクル管理を主に担って、ネットワーク機能仮想化インフラストラクチャ（ＮＦＶＩ，ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎｓ ｖｉｒｔｕａｌｉｚａｔｉｏｎ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）１０４中の仮想リソースの割振りおよびスケジューリングを担う。ＮＦＶＯ１０２は、１つまたは複数の仮想化ネットワーク機能マネージャ（ＶＮＦＭ，Ｖｉｒｔｕａｌｉｚｅｄ Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｍａｎａｇｅｒ）１０６と通信し得、およびＮＳインスタンス化に関係付けられる動作、例えば、対応する設定情報をＶＮＦＭ１０６に送信すること、または１つもしくは複数のＶＮＦ１０８のステータス情報をＶＮＦＭ１０６から要求することを実施し得る。加えて、ＮＦＶＯ１０２はさらに、仮想化インフラストラクチャマネージャ（ＶＩＭ，ｖｉｒｔｕａｌｉｚｅｄ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｍａｎａｇｅｒ）１１０と通信して、ＮＦＶＩ１０４中のリソースのそれぞれに対する割振りおよび／または予約を実施して、リソース構成およびステータス情報などを交換し得る。

ＶＮＦＭ１０６：１つまたは複数のＶＮＦ１０８のライフサイクル管理、例えば、ＶＮＦ１０８をインスタンス化すること（ｉｎｓｔａｎｔｉａｔｉｎｇ）、ＶＮＦ１０８を更新すること（ｕｐｄａｔｉｎｇ）、ＶＮＦ１０８に照会すること、ＶＮＦ１０８をスケーリングすること（ｓｃａｌｉｎｇ）、およびＶＮＦ１０８を終結すること（ｔｅｒｍｉｎａｔｉｎｇ）を主に担う。ＶＮＦＭ１０６は、ＶＮＦ１０８と通信して、ＶＮＦ１０８のライフサイクルを管理して、設定情報、ステータス情報などをＶＮＦと交換し得る。ＮＦＶシステム１００が１つまたは複数のＶＮＦＭ１０６を備える場合があって、ＶＮＦＭ１０６が異なるタイプのＶＮＦ１０８に対するライフサイクル管理をそれぞれ実施することが、理解され得る。

ＮＦＶＩ１０４：ＮＦＶシステム１００のインフラストラクチャであって、仮想化された環境を確立して、仮想化された環境でＶＮＦ１０８を展開、管理、および実装するために、ハードウェアコンポーネント、ソフトウェアコンポーネント、およびこれらの組合せを含む。ＮＦＶＩ１０４は、コンピューティング（ｃｏｍｐｕｔｉｎｇ）ハードウェア１０４１、ストレージハードウェア１０４２、およびネットワークハードウェア１０４３を少なくとも含み得る。ＮＦＶＩ１０４の仮想化レイヤ１０４４が、ＶＮＦ１０８のための別の形の仮想マシンおよび仮想コンテナを提供するために、前述のハードウェアを抽象化して、ハードウェアをＶＮＦ１０８から切り離して、対応する仮想コンピューティング（ｖｉｒｔｕａｌ ｃｏｍｐｕｔｉｎｇ）リソース１０４５、仮想ストレージリソース１０４６、および仮想ネットワークリソース１０４７を取得し得る。

ＶＩＭ１１０： ＶＮＦ１０８と、コンピューティングハードウェア１０４１、ストレージハードウェア１０４２、ネットワークハードウェア１０４３、仮想コンピューティングリソース１０４５、仮想ストレージリソース１０４６、および仮想ネットワークリソース１０４７との間のインタラクションを制御および管理するように主に構成される。例えば、ＶＩＭ１１０は、リソース管理機能を実施し得、例えば具体的には、対応する仮想リソースを別の形の仮想マシンまたは仮想コンテナに追加すること、およびシステム稼働プロセスにおけるＮＦＶＩ１０４の障害情報を収集することを実施し得る。加えて、ＶＩＭ１１０は、ＶＮＦＭ１０６と通信し得、例えば、リソース割振り要求をＶＮＦＭ１０６から受信することと、リソース構成およびステータス情報をＶＮＦＭ１０６にフィードバックすることとを行い得る。

ＶＮＦ１０８：ＶＮＦ１０８は、１つまたは複数のＶＮＦ（普通は複数のＶＮＦ）を含み、および専用デバイスによって元々実装されていたネットワーク機能のグループに対応するように別の形の１つまたは複数の仮想マシンまたは仮想コンテナを稼働し得る。

要素管理システム（ＥＭＳ，ｅｌｅｍｅｎｔ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）１１２：ＶＮＦ１０８を構成および管理して、ＶＮＦＭ１０６に対する新しいＶＮＦ１０８のインスタンス化などのライフサイクル管理動作を開始するように構成され得る。ＮＦＶシステム１００が１つまたは複数のＥＭＳ１１２を含む場合があることが理解され得る。

オペレーションサポートシステム（ＯＳＳ，ｏｐｅｒａｔｉｏｎｓ ｓｕｐｐｏｒｔ ｓｙｓｔｅｍ）またはビジネスサポートシステム（ＢＳＳ，ｂｕｓｉｎｅｓｓ ｓｕｐｐｏｒｔ ｓｙｓｔｅｍ）１１４： 様々なエンドツーエンド遠隔通信ビジネスをサポートすることができる。ＯＳＳによってサポートされる管理機能は、ネットワーク構成、ビジネスプロビジョン、障害管理などを含み得、およびＢＳＳは、注文、支払い、および収益など、関係付けられるビジネスを処理して、製品管理、注文管理、収益管理、および顧客管理などの機能をサポートするように構成され得る。ＯＳＳ／ＢＳＳ１１４は、ＮＳをインスタンス化するようＮＦＶＯに要求するためのビジネスリクエスタとして使用され得ること、および、ＯＳＳ／ＢＳＳ１１４、またはＯＳＳ／ＢＳＳ１１４が依拠したコンピューティングデバイスは一般にビジネスリクエスタと相応に呼ばれ得ることに留意されたい。

図１に示されるＮＦＶシステム１００中では、前述の機能エンティティが異なるコンピューティングデバイス中で別々に展開されてもよく、またはいくつかの機能エンティティが同じコンピューティングデバイスに統合されてもよいことが、理解され得る。

現在、遠隔通信分野におけるネットワークトランスフォーメーションは、ネットワーク機能仮想化（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ，ＮＦＶ）からクラウドネイティブ（Ｃｌｏｕｄ－Ｎａｔｉｖｅ）に進化するプロセスを経つつある。クラウドネイティブは、ソフトウェアをクラウド環境で構築、稼働、および管理するための新しいシステム実装パラダイムであって、クラウドインフラストラクチャおよびプラットフォームサービスを十分に活用し、クラウド環境に適応して、（マイクロ）サービタイゼーション、スケーリング、分散化、高アベイラビリティ、マルチテナント、および自動化など、鍵となる特徴を有する、アーキテクチャプラクティスである。このトランスフォーメーションにおいて、ＮＦＶ管理およびオーケストレーション（Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｏｒｃｈｅｓｔｒａｔｉｏｎ，ＭＡＮＯ）の基準アーキテクチャにコンテナ管理を導入することは、ＮＦＶからクラウドネイティブへの進化の多くのプラクティスの鍵となるリンクである。

コンテナアズアサービス（Ｃｏｎｔａｉｎｅｒ ａｓ ａ Ｓｅｒｖｉｃｅ，ＣａａＳ）は、プラットフォームアズアサービス（ＰａａＳ，Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）の具体的なタイプである。一般に、コンテナは、ＬｉｎｕｘにおけるＣＧｒｏｕｐおよびＮａｍｅＳｐａｃｅなどのオペレーティングシステム隔離技術を使用して種々のプロセスを隔離する、オペレーティングシステムレベルの仮想化技術である。ハードウェア仮想化（Ｈｙｐｅｒｖｉｓｏｒ）技術とは異なり、コンテナ技術は仮想ハードウェアを有さず、およびコンテナ内部にはオペレーティングシステムはなくプロセスのみがある。コンテナ技術のこの重要な特徴のおかげで、コンテナは、仮想マシンと比較して、より軽量であり、およびより管理しやすい。コンテナの稼働状態では、コンテナのライフサイクルを統一された方式で管理するために、開始、停止、一時停止、および削除など、共通管理動作のグループが定義される。クラウドネイティブコンピューティングファウンデーション（Ｃｌｏｕｄ Ｎａｔｉｖｅ Ｃｏｍｐｕｔｉｎｇ Ｆｏｕｎｄａｔｉｏｎ）のＫｕｂｅｒｎｅｔｅｓプロジェクトは、コンテナ管理およびオーケストレーションのための、業界で現在認識されているデファクトスタンダードである。

コンテナアズアサービスアーキテクチャを遠隔通信ネットワーククラウドネイティブの進化プロセスにおいて導入することは、遠隔通信業界の開発運用（ＤｅｖＯｐｓ）にアジリティトランスフォーメーションをもたらす。このトランスフォーメーションに対応する変化は、従来の、粒度の粗い単一ネットワーク機能が、徐々に分解されてサービス化されること、またはさらにマイクロサービス化すらされることである。サービス化される機能のそれぞれは、独立して開発、送達、および維持されて、バージョンのアップグレードはより頻繁になる。しかし、コンテナ化されたネットワーク機能の急増は、相互運用性テストのワークロードを指数関数的に増大させることはない。安定したＡＰＩインタフェース定義が、インタフェース機能呼出しの一貫性および信頼性を確実にする。

現在、コンテナ管理およびオーケストレーション分野における最も一般的な適用は、オープンソースプラットフォームに基づくＧｏｏｇｌｅのＫｕｂｅｒｎｅｔｅｓ（略してＫ８Ｓ）コンテナクラスタ管理技術である。Ｋｕｂｅｒｎｅｔｅｓの核となる考えは、「あらゆるものはサービス中心であり、およびサービスを中心として動く」というものである。この考えに基づいて、Ｋｕｂｅｒｎｅｔｅｓ上に構築されるコンテナアプリケーションシステムは、物理マシン、仮想マシン、または企業私設クラウド上で独立して稼働することができ、および公衆クラウド上でホストされることもまた可能である。Ｋｕｂｅｒｎｅｔｅｓの別の特徴は自動化であり、サービスは、自動的にスケーリングされること、自動的に診断されること、および容易にアップグレードされることが可能である。

コンテナクラスタ管理の機能範囲は、コンテナクラスタ管理（コンテナクラスタの作成または削除）と、コンテナクラスタノード管理（クラスタ中のノードの追加／削除、およびクラスタのサイズの弾力的な更新）とを含む。コンテナクラスタは、必要に応じて動的に作成され得、すなわち、ＮＦＶ ＭＡＮＯは、管理されるコンテナ化されたＶＮＦのサイズと信頼性ポリシーとに基づいて、作成されるコンテナクラスタの量とクラスタのそれぞれの容量とを決定する。

コンテナクラスタの動的管理モードでは、遠隔通信クラウドの大規模コンテナ化ＶＮＦ管理およびオーケストレーションにおいて、コンテナクラスタの作成または更新を単純で素早いものにしてバッチ動作をより効率的にするためにどのようにコンテナクラスタを管理するかが、特に重要である。現在、オープンソースコミュニティは、Ｇｏｏｇｌｅ Ｋｕｂｅａｄｍなど、いくつかの基本的なコンテナクラスタ管理プロトタイプツールを有する。しかし、これらのプロトタイプツールは、遠隔通信クラウドの大規模コンテナクラスタ展開および管理の要件を満たすことができない。

従来技術における前述の技術的問題を解決するために、本出願の実施形態は、コンテナクラスタノードリソースプールのための管理方法および装置を提供する。詳細は次のとおりである。

本出願の実施形態は、コンテナクラスタノードリソースプールのための管理方法を提供し、この方法は、以下を含む。

コンテナクラスタ管理ＣＣＭが、コンテナクラスタのインスタンス化要求メッセージを管理エンティティから受信し、要求メッセージは、コンテナクラスタのインスタンス化パラメータを保持する。ＣＣＭは、コンテナクラスタのインスタンス化パラメータに基づいてコンテナクラスタをインスタンス化し、コンテナクラスタのインスタンス化パラメータは、管理エンティティによって、コンテナクラスタ記述子ＣＣＤにアクセスすることによって決定される。

この方法は、以下をさらに含む。

ＣＣＭは、コンテナクラスタノードのインスタンス化要求メッセージを管理エンティティから受信し、要求メッセージは、コンテナクラスタノードのインスタンス化パラメータを保持する。コンテナクラスタノードのインスタンス化パラメータは、管理エンティティによって、コンテナクラスタノード記述子ＣＣＮＤにアクセスすることによって決定され、または、ＣＣＭが、ＣＣＮＤにアクセスしてコンテナクラスタノードのインスタンス化パラメータを決定する。

ＣＣＭは、コンテナクラスタノードのインスタンス化パラメータに基づいてコンテナクラスタノードをインスタンス化し、コンテナクラスタのインスタンス化パラメータに基づいてコンテナクラスタノード上でＣＩＳＭインスタンスおよびＣＩＳインスタンスをインスタンス化する。

この方法は、以下をさらに含む。ＣＣＭは、コンテナクラスタの更新要求メッセージを管理エンティティから受信し、要求メッセージは、更新されることになるコンテナクラスタインスタンスのパラメータを保持する。ＣＣＭは、更新されることになるコンテナクラスタインスタンスのパラメータに基づいて、コンテナクラスタインスタンスを更新する。

この方法は、以下をさらに含む。ＣＣＭは、コンテナクラスタの削除要求メッセージを管理エンティティから受信し、削除要求メッセージは、削除されることになるコンテナクラスタインスタンスの識別情報、および／または削除動作のタイプを保持する。ＣＣＭは、コンテナクラスタインスタンスを削除する。

本出願の実施形態は、コンテナクラスタのための管理システムを提供し、このシステムは、
コンテナクラスタ記述子ＣＣＤに基づいてコンテナクラスタのインスタンス化パラメータを決定し、コンテナクラスタのインスタンス化パラメータをコンテナクラスタ管理ＣＣＭに送信するように構成された管理エンティティと、コンテナクラスタのインスタンス化パラメータに基づいてコンテナクラスタをインスタンス化するように構成されたＣＣＭとを含む。

管理エンティティは、コンテナクラスタノード記述子ＣＣＮＤにアクセスしてコンテナクラスタノードのインスタンス化パラメータを決定し、コンテナクラスタノードのインスタンス化パラメータをＣＣＭに送信するように、さらに構成される。

ＣＣＭは、コンテナクラスタノードのインスタンス化パラメータに基づいてコンテナクラスタノードをインスタンス化し、コンテナクラスタのインスタンス化パラメータに基づいてコンテナクラスタノード上でＣＩＳＭインスタンスおよびＣＩＳインスタンスをインスタンス化する。

本出願の実施形態は、前述の方法ステップを実施するように構成されたモジュールを含む、コンテナクラスタのための管理装置をさらに提供する。

本出願の実施形態は、プロセッサとメモリとを含む、コンテナクラスタのための管理装置をさらに提供し、プロセッサはメモリに結合され、メモリはコンピュータプログラムを記憶する。プロセッサは、メモリ中のコンピュータプログラムを呼び出して、前述の方法を管理装置が実施するのを可能にするように構成される。

本出願の実施形態は、コンピュータ可読記憶媒体をさらに提供し、記憶媒体はコンピュータプログラムを記憶する。コンピュータプログラムが実行されたとき、前述の方法が実施される。

本出願の実施形態は、コンピュータプログラム製品をさらに提供し、コンピュータプログラム製品はコンピュータプログラムコードを含む。コンピュータプログラムコードがコンピューティングデバイス上で稼働されたとき、コンピューティングデバイスは、前述の方法を実施することが可能にされる。

本発明の実施形態の解決法を用いて、コンテナクラスタ記述子テンプレートおよびコンテナクラスタノード記述子テンプレートが定義され、コンテナクラスタのための動的管理がサポートされ、大規模コンテナクラスタの一貫性のある展開およびバッチ複製が実装される。

実施形態または従来技術の説明で使用されることが必要な添付図面について、以下に簡潔に説明される。

従来技術におけるＮＦＶシステムのフレームワーク図である。 本出願の実施形態による、Ｋｕｂｅｒｎｅｔｅｓ（Ｋ８Ｓ）コンテナ管理およびオーケストレーションシステムのアーキテクチャ図である。 本出願の実施形態による、コンテナクラスタを管理するためのＮＦＶ管理およびオーケストレーションシステムのアーキテクチャ図である。 本出願の実施形態による、コンテナクラスタとコンテナクラスタノードと名前空間との間の論理関係の図である。 本出願の実施形態による、コンテナクラスタを作成することの概略フローチャートである。 本出願の実施形態による、コンテナクラスタを更新することの概略フローチャートである。 本出願の実施形態による、コンテナクラスタを削除することの概略フローチャートである。 本出願の実施形態による、管理エンティティ装置の概略モジュール図である。 本出願の実施形態による、ＣＣＭ装置の概略モジュール図である。 本出願の実施形態による、管理エンティティ装置のハードウェア構造の概略図である。 本出願の実施形態による、ＣＣＭ装置のハードウェア構造の概略図である。

以下、本出願の実施形態における技術的解決法について、本出願の実施形態における添付図面を参照しながら説明する。

図２を参照されたいが、これは、Ｋｕｂｅｒｎｅｔｅｓ（Ｋ８Ｓ）コンテナ管理およびオーケストレーションシステムのアーキテクチャ図である。

Ｋｕｂｅｒｎｅｔｅｓは、コンテナクラスタ中のインフラストラクチャリソースを、Ｋｕｂｅｒｎｅｔｅｓマスタノード（ｍａｓｔｅｒ）とワーカーノード（Ｎｏｄｅ）のグループとに分割する。マスタノード（管理ノードとも呼ばれる）上では、コンテナクラスタ管理に関係付けられるプロセス、例えば、アプリケーションプログラミングインタフェースサーバ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ Ｓｅｒｖｅｒ，ＡＰＩ Ｓｅｒｖｅｒ）およびレプリケーションコントローラ（Ｒｅｐｌｉｃａｔｉｏｎ Ｃｏｎｔｔｒｏｌｌｅｒ，ＲＣ）、のグループが稼働する。これらのプロセスは、コンテナクラスタ全体の、リソース管理、コンテナポッド（Ｐｏｄ）スケジューリング、スケーリング、セキュリティ制御、システム監視、および誤り訂正などの管理機能を実装する。ワーカーノードのそれぞれでは、Ｋｕｂｅｌｅｔ、Ｐｒｏｘｙ、およびＤｏｃｋｅｒという３つのコンポーネントが稼働されて、現ノード上のポッドのライフサイクルを管理することおよびサービスプロキシ機能を実装することを担う。図２に示されるように、ポッドは、少なくとも１つのコンテナを含み得る。この場合、ポッドは、１つまたは複数のコンテナを含むコンテナポッドとして理解され得る。

ＡＰＩサーバは、リソースオブジェクトに対する一意の操作エントリを提供して、他のすべてのコンポーネントは、ＡＰＩサーバによって提供されるＡＰＩインタフェースを通してリソースデータを操作する必要があって、関係付けられるリソースデータに対する「完全な照会」および「変化監視」を実施することによって、関係付けられるビジネス機能を実装する。

コントローラマネージャは、コンテナクラスタの管理および制御センタであって、Ｋｕｂｅｒｎｅｔｅｓクラスタの自動障害検出および回復を実装するという主目的を有する。例えば、ポッドの複製または除去は、ポッドインスタンスの量がＲＣの定義に確実に準拠するようにＲＣの定義に基づいて実施されることが可能であって、サービスのエンドポイント（Ｅｎｄｐｏｉｎｔ）オブジェクトの作成および更新と、ノードの発見、管理、および状態監視と、ローカルにキャッシュされたイメージファイルのクリーニングとは、サービス（Ｓｅｒｖｉｃｅ）とポッドとの間の管理関係に基づいて実施されることが可能である。

Ｋｕｂｅｌｅｔコンポーネントは、現ノード上のポッドの作成、修正、監視、および削除を含めた、完全なライフサイクル管理を担う。加えて、Ｋｕｂｅｌｅｔは、現ノードのステータス情報をＡＰＩサーバに定期的に報告する。

Ｐｒｏｘｙコンポーネントは、サービスのプロキシパターンとソフトウェアパターンとの間の負荷平衡化を実装するように構成される。

Ｄｏｃｋｅｒコンポーネントは、コンテナの稼働環境である。

欧州電気通信標準化機構（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ，ＥＴＳＩ）の下におけるＮＦＶ業界標準部会は、Ｒｅｌｅａｓｅ ４の特徴的な作業において、ＮＦＶ管理およびオーケストレーション（Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｏｒｃｈｅｓｔｒａｔｉｏｎ）システム管理コンテナの標準機能を定義している。図３に示されるように、この基準機能のフレームワークでは、右側の管理プレーンが、新たに導入された下記の２つの論理機能を有する。

コンテナインフラストラクチャサービス管理（Ｃｏｎｔａｉｎｅｒ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ，ＣＩＳＭ）（ＣａａＳ管理とも呼ばれ、そのオープンソースプロトタイプはＫｕｂｅｒｎｅｔｅｓである）は、コンテナ化されたＶＮＦによって呼び出されるコンテナオブジェクトを管理することを担い、これは、コンテナオブジェクトを作成、更新、および削除することと、ＣＩＳＭによって管理されるコンテナクラスタノードリソースプール中の対応するノードリソース（コンピューティング、ストレージ、およびネットワークリソース）に対してコンテナオブジェクトをスケジュールすることとを含む。ＥＴＳＩ標準におけるコンテナオブジェクトの対応する概念は、マネージドコンテナインフラストラクチャオブジェクト（Ｍａｎａｇｅｄ Ｃｏｎｔａｉｎｅｒ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｏｂｊｅｃｔ，ＭＣＩＯ）である。

コンテナクラスタ管理（Ｃｏｎｔａｉｎｅｒ Ｃｌｕｓｔｅｒ Ｍａｎａｇｅｍｅｎｔ，ＣＣＭ）は、コンテナクラスタを管理することを担い、これは、コンテナクラスタによって使用されるノードリソースプールを作成すること、およびノードをスケーリングすることを含む。コンテナクラスタは、監視および管理システム（例えば、図２におけるＫｕｂｅｒｎｅｔｅｓ Ｍａｓｔｅｒ）と、一連のコンピューティングノード（例えば、図２におけるノード、これは物理サーバ、ベアメタル、または仮想マシンであり得る）とによって形成されるセットである。コンテナクラスタは動的なシステムであり、システム中で複数のコンテナが展開されることが可能であって、システムはこれらのコンテナのステータスおよびコンテナ間の通信を監視することができる。ＥＴＳＩ標準におけるコンテナクラスタの対応する概念は、コンテナインフラストラクチャサービスクラスタ（Ｃｏｎｔａｉｎｅｒ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｓｅｒｖｉｃｅ Ｃｌｕｓｔｅｒ，ＣＩＳ Ｃｌｕｓｔｅｒ）である。

コンテナ化されたＶＮＦは、コンピューティング、ストレージ、およびネットワークリソースなどのＮＦＶＩリソースをカプセル化するコンテナ化されたワークロード（ｃｏｎｔａｉｎｅｒｉｚｅｄ ｗｏｒｋｌｏａｄ）として理解され得る。ワークロードによって呼び出されるコンテナオブジェクトＭＣＩＯは、稼働させることになるコンテナクラスタのノード上にスケジュールされる。コンテナクラスタは、ノード上の、ＣＩＳＭインスタンス（Ｋｕｂｅｒｎｅｔｅｓ ＭａｓｔｅｒなどのＣａａＳ管理プレーン機能）のイメージ、またはコンテナインフラストラクチャサービス（Ｃｏｎｔａｉｎｅｒ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｓｅｒｖｉｃｅ，ＣＩＳ）インスタンス（Ｋｕｂｅｒｎｅｔｅｓワーカーノード上のｋｕｂｅｌｅｔ、ｋｕｂｅ－ｐｒｏｘｙ、およびｄｏｃｋｅｒなど、ＣａａＳユーザプレーン機能）のイメージをロードする。ＥＴＳＩ ＮＦＶ標準では、コンテナクラスタのそれぞれにおけるＣＩＳＭは、名前空間（ｎａｍｅｓｐａｃｅ）の作成、読取り、更新、および削除（Ｃｒｅａｔｉｎｇ／Ｒｅａｄｉｎｇ／Ｕｐｄａｔｉｎｇ／Ｄｅｌｅｔｉｎｇ，ＣＲＵＤ）などの管理機能を提供する。名前空間は、具体的な識別子、リソース、ポリシー、および許可のグループによって形成される論理グループであって、サーバにおけるフォルダの機能に類似する機能を有する。ＮＦＶＯは、コンテナクラスタ中で複数の名前空間を作成して、名前空間を通してコンテナクラスタ中の複数のテナント（すなわち、コンテナ化されたＶＮＦ）のコンテナオブジェクトＭＣＩＯのリソースおよび識別子を隔離し得る。図４に、コンテナクラスタ（ＣＩＳ ｃｌｕｓｔｅｒ）とコンテナクラスタノード（ＣＩＳ ｃｌｕｓｔｅｒ ｎｏｄｅ）と名前空間（ｎａｍｅｓｐａｃｅ）との間の関係が示されている。ＣＩＳＭおよびＣＣＭは、ＮＦＶＯまたはＶＮＦＭに、それらの機能をノースバウンドインタフェース上で呼び出すための管理サービスを提供する。

本発明の解決法は、ＮＦＶテンプレートに基づくコンテナクラスタのための管理方法を提供し、コンテナクラスタ記述子テンプレートおよびコンテナクラスタノード記述子テンプレートを定義することと、新たに定義される記述子テンプレートをコンテナクラスタ管理プロセスにおいて適用することとによって、コンテナクラスタの動的管理がサポートされて、大規模コンテナクラスタの一貫性のある展開およびバッチ複製が実装される。

コンテナクラスタ記述子（ＣＣＤ，ＣＩＳ Ｃｌｕｓｔｅｒ Ｄｅｓｃｒｉｐｔｏｒ）は、コンテナクラスタの展開および動作挙動要件を記述して本発明の実施形態において定義される、ＮＦＶテンプレートファイルのタイプである。ＣＣＤについては、ＶＮＦＤ（Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒ）のテンプレートに類似するテンプレートを参照または使用されたい。テンプレートは、限定はされないが以下の基本的な展開情報を含む。

コンテナクラスタ記述子の名前情報、識別情報、プロバイダ情報、およびバージョン情報。

コンテナクラスタのサイズ（ｓｉｚｅ）、すなわち、コンテナクラスタに含まれるＣＩＳＭインスタンスの最大量および／またはＣＩＳインスタンスの最大量。

スケーリング動作の間にコンテナクラスタによって実施され得る最小ステップ、最大ステップ、および／または到達可能スケーリングレベル（Ｓｃａｌｅ ｌｅｖｅｌ）を含めた、コンテナクラスタのスケール（ｓｃａｌｅ）動作の基本的な特性。

コンテナクラスタ全体のアフィニティ／アンチアフィニティ規則は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンスが位置するアフィニティ／アンチアフィニティグループの識別情報であって、これは、ＣＣＤに基づいて作成されるコンテナクラスタインスタンスと、別のＣＣＤに基づいて作成されるコンテナクラスタインスタンスとの間のアフィニティ／アンチアフィニティ関係を示すためのものである。アフィニティグループは、リソース類似性に基づいて形成される論理関係グループであり、および同じアフィニティグループに属するオブジェクトは、展開中に類似するリソースを使用し、例えば、アフィニティグループ中のすべてのオブジェクトは、同じデータセンタ中で展開され、アンチアフィニティグループは、リソース差異に基づいて形成される論理関係グループであり、同じアンチアフィニティグループに属するオブジェクトは、展開中に異なるリソースを使用し、例えば、アンチアフィニティグループ中のすべてのオブジェクトは、異なるデータセンタ中で展開される。

コンテナクラスタ中で展開されるＣＩＳＭインスタンス間のアフィニティ／アンチアフィニティ規則は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳＭインスタンスが位置するアフィニティ／アンチアフィニティグループの識別情報を指し、およびこれは、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳＭインスタンスと、ＣＣＤに基づいて作成される同じコンテナクラスタインスタンス中の別のＣＩＳＭインスタンスとの間のアフィニティ／アンチアフィニティ関係を示すためのものである。

コンテナクラスタ中で展開されるＣＩＳインスタンス間のアフィニティ／アンチアフィニティ規則は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳインスタンスが位置するアフィニティ／アンチアフィニティグループの識別情報を指し、およびこれは、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳインスタンスと、ＣＣＤに基づいて作成される同じコンテナクラスタインスタンス中の別のＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ関係を示すためのものである。

コンテナクラスタ中で展開されるＣＩＳＭインスタンスとＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ規則は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳＭインスタンスおよびＣＩＳインスタンスが位置するアフィニティ／アンチアフィニティグループの識別情報を指し、およびこれは、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳＭインスタンスと、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ関係を示すためのものである。

１次コンテナクラスタ外部ネットワーク（ｐｒｉｍａｒｙ ＣＩＳ ｃｌｕｓｔｅｒ ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ）の特徴は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンスの１次外部ネットワークの基本的な設定情報、例えば、コンテナクラスタ中のコンテナが外部ネットワークに接続するためのＩＰアドレスおよびポートの特徴要件を指す。１次コンテナクラスタ外部ネットワークは、コンテナクラスタの外部公衆ネットワークであり、コンテナクラスタ中のコンテナ（ＯＳコンテナ）は、基礎をなすコンテナインフラストラクチャレイヤのネイティブネットワーク能力を通して、外部公衆ネットワークに間接的に接続される。

２次コンテナクラスタ外部ネットワーク（ｓｅｃｏｎｄａｒｙ ＣＩＳ ｃｌｕｓｔｅｒ ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ）の特徴は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンスの２次外部ネットワークの基本的な設定情報、例えば、コンテナクラスタによって使用されるコンテナネットワークインタフェース（Ｃｏｎｔａｉｎｅｒ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ，ＣＮＩ）の特徴要件を指し、２次コンテナクラスタ外部ネットワークは、コンテナクラスタの外部露出ネットワークを指し、およびコンテナクラスタ中のコンテナ（ＯＳコンテナ）は、１次ネットワークインタフェースとは異なる別のネットワークインタフェースを通して、直接に相互接続される。

コンテナクラスタノード記述子（ＣＣＮＤ，ＣＩＳ Ｃｌｕｓｔｅｒ Ｎｏｄｅ Ｄｅｓｃｒｉｐｔｏｒ）は、コンテナクラスタノードの展開および動作挙動要件を記述するＮＦＶテンプレートファイルのタイプである。ＣＣＮＤは、仮想コンピューティングまたはストレージリソース記述子の定義に類似し、限定はされないが以下の展開情報を含む。

ＣＣＮＤに基づいて作成されるコンテナクラスタノードのタイプ。例えば、ノードのタイプが物理マシン（ベアメタル）であるかまたは仮想マシンであるかを示す。

ハードウェアアクセラレーション、ネットワークインタフェース、およびローカルストレージについての、ＣＣＮＤに基づいて作成されるコンテナクラスタノードの要件。

ＣＣＮＤに基づいて作成されるコンテナクラスタ中のノード間のアフィニティ／アンチアフィニティ規則は、ＣＣＮＤに基づいて作成されるコンテナクラスタノードインスタンスが位置するアフィニティ／アンチアフィニティグループの識別情報を指し、およびこれは、ＣＣＮＤに基づいて作成されるコンテナクラスタノード（またはコンテナクラスタノードインスタンスと呼ばれる）と、ＣＣＮＤに基づいて作成される別のコンテナクラスタノードインスタンスとの間のアフィニティ／アンチアフィニティ関係を示すためのものである。

前述のテンプレートファイルに基づいて、本発明の実施形態１は、コンテナクラスタ作成（またはインスタンス化と呼ばれる）方法を提供する。図５に示されるように、この方法は、以下のステップを具体的に含む。

ステップ５０１： ＮＦＶ ＭＡＮＯ管理エンティティ（または、略して管理エンティティ、以下同様）が、コンテナクラスタ記述子ＣＣＤにアクセスして、作成されることになるコンテナクラスタ（またはコンテナクラスタインスタンスと呼ばれる）の展開情報をＣＣＤファイルから取得する。

管理エンティティは、ＮＦＶＯまたはＶＮＦＭであり得、およびどちらがこの実施形態における方法のすべてのステップを具体的に実施するかは、システム構成に依存する。これは本明細書において特に限定されない。

ステップ５０２： 管理エンティティは、ＣＣＤ中のコンテナクラスタの展開情報に基づいて、作成されることになるコンテナクラスタインスタンスのインスタンス化パラメータ、例えば、コンテナクラスタ記述子ＣＣＤの名前または識別情報と、コンテナクラスタのサイズと、コンテナクラスタの初期化中に作成されるＣＩＳＭインスタンスの量およびＣＩＳインスタンスの量と、コンテナクラスタ中のＣＩＳＭインスタンス間、ＣＩＳインスタンス間、およびＣＩＳＭインスタンスとＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ規則とを決定する。

管理エンティティは、コンテナクラスタ記述子ＣＣＤ中のコンテナクラスタの展開情報を、コンテナクラスタインスタンスのインスタンス化パラメータとして使用してもよく、または、展開情報を満たすことに基づいて別のネットワーク要素システム（ＯＳＳ／ＢＳＳなど）の入力を参照して、コンテナクラスタインスタンスのインスタンス化パラメータを決定してもよい。

ステップ５０３： 管理エンティティは、コンテナクラスタ作成要求をコンテナクラスタ管理ＣＣＭに送信し、要求メッセージは、作成されることになるコンテナクラスタのサイズと、コンテナクラスタの初期化中に作成されるＣＩＳＭインスタンスの量およびＣＩＳインスタンスの量と、コンテナクラスタ中のＣＩＳＭインスタンス間、ＣＩＳインスタンス間、およびＣＩＳＭインスタンスとＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ規則とを保持する。

ステップ５０４： ＣＣＭは、コンテナクラスタ作成応答を管理エンティティに返して、コンテナクラスタ作成要求メッセージがうまく受信されたことを示す。

ステップ５０５： ＣＣＭは、コンテナクラスタ管理プロセスの変更通知を管理エンティティに送って、コンテナクラスタインスタンス化プロセスが開始することを管理エンティティに示す。

ステップ５０６： 管理エンティティは、作成されることになるコンテナクラスタノードインスタンスのコンテナクラスタノード記述子ＣＣＮＤの識別情報をコンテナクラスタ記述子ＣＣＤから取得して、ＣＣＮＤの識別情報を使用してＣＣＮＤファイルを取得し、および管理エンティティは、ＣＣＮＤにアクセスして、作成されることになるコンテナクラスタノードインスタンスの展開情報を取得する。

ステップ５０７： 管理エンティティは、ＣＣＮＤ中のコンテナクラスタノードの展開情報に基づいて、作成されることになるコンテナクラスタノードインスタンスのインスタンス化パラメータ、例えば、コンテナクラスタノードのタイプと、コンテナクラスタノードが属するアフィニティ／アンチアフィニティグループとを決定する。

ステップ５０８： 管理エンティティは、コンテナクラスタノード作成要求をコンテナクラスタ管理ＣＣＭに送信し、要求メッセージは、作成されることになるコンテナクラスタノードの記述子の名前または識別情報と、コンテナクラスタノードのタイプと、コンテナクラスタノードが属するアフィニティ／アンチアフィニティグループとを保持する。

ステップ５０９： ＣＣＭは、コンテナクラスタノード作成応答を管理エンティティに返して、コンテナクラスタノード作成要求メッセージがうまく受信されたことを示す。

任意選択で、ステップ５０６からステップ５０９の代替方法として、ＣＣＭは、コンテナクラスタノード記述子ＣＣＮＤの識別情報をコンテナクラスタ記述子ＣＣＤから取得して、コンテナクラスタノード記述子ＣＣＮＤにアクセスすることによってコンテナクラスタノードのインスタンス化パラメータを決定する。

同様に、ＣＣＭは、コンテナクラスタ記述子ＣＣＤ中のコンテナクラスタの展開情報を、コンテナクラスタインスタンスのインスタンス化パラメータとして使用してもよく、または、展開情報を満たすことに基づいて別のネットワーク要素システム（ＯＳＳ／ＢＳＳなど）の入力を参照して、コンテナクラスタインスタンスのインスタンス化パラメータを決定してもよい。

ステップ５１０： ＣＣＭは、作成されることになるコンテナクラスタ中の初期化されたコンテナクラスタノードを作成するプロセスを完了して、それにより、コンテナクラスタインスタンスの作成をローカルに完了する。さらに、ＣＣＭは、コンテナクラスタ記述子ＣＣＤにアクセスして、展開されることになるＣＩＳＭインスタンスおよび／またはＣＩＳインスタンスのソフトウェアイメージ（ｉｍａｇｅ）情報を取得して、ＣＩＳＭインスタンスおよびＣＩＳインスタンスをコンテナクラスタノード上で展開し（任意選択で、ＣＩＳインスタンスはまた、作成されたＣＩＳＭインスタンスを使用して作成されてもよい）、およびＣＣＭは、コンテナクラスタインスタンスに関する情報、例えば、インスタンス化されたコンテナクラスタインスタンスによって使用されるＣＣＤ識別情報およびバージョンと、インスタンス化ステータスと、スケーリングステータスと、許容される最大スケーリングレベルと、外部ネットワーク情報と、ノードリソース情報とを作成する。

ＣＩＳＭインスタンスのソフトウェアイメージ、および／またはＣＩＳインスタンスのソフトウェアイメージは、ＮＦＶ－ＭＡＮＯ管理ドメイン中のコンテナクラスタのパッケージファイルに記憶されていてもよく、またはＮＦＶ－ＭＡＮＯ管理ドメイン外部のソフトウェアイメージレジストリ（ｉｍａｇｅ ｒｅｇｉｓｔｒｙ）に記憶されていてもよく、およびコンテナクラスタ記述子ＣＣＤは、ＣＩＳＭインスタンスのソフトウェアイメージおよび／もしくはＣＩＳインスタンスのソフトウェアイメージを記憶したコンテナクラスタのパッケージファイルを指すかまたは外部ソフトウェアイメージレジストリのディレクトリアドレスを指す、インデックス情報を含むことに留意されたい。

ステップ５１１： ＣＣＭは、コンテナクラスタ管理プロセスの変更通知を管理エンティティに送り、およびコンテナクラスタインスタンス化終了通知メッセージを管理エンティティに送信する。

本発明の実施形態２は、コンテナクラスタ更新方法を提供する。図６に示されるように、この方法は、以下のステップを具体的に含む。

ステップ６０１： 管理エンティティが、コンテナクラスタ更新要求をコンテナクラスタ管理ＣＣＭに送信し、要求メッセージは、更新されることになるコンテナクラスタインスタンスの識別情報と、スケーリングである更新動作のタイプと、スケーリングまたはスケーリングレベルによって到達されるターゲットコンテナクラスタのサイズと、スケーリングのターゲットコンテナクラスタのノード間のアフィニティ／アンチアフィニティ規則とを保持する。

ステップ６０２： ＣＣＭは、コンテナクラスタ更新応答を管理エンティティに返して、コンテナクラスタ更新要求メッセージがうまく受信されたことを示す。

ステップ６０３： ＣＣＭは、コンテナクラスタ管理プロセスの変更通知を管理エンティティに送って、コンテナクラスタ更新プロセスが開始することを管理エンティティに示す。

ステップ６０４： 管理エンティティは、更新されることになるコンテナクラスタノードインスタンスのコンテナクラスタノード記述子ＣＣＮＤの識別情報をコンテナクラスタ記述子ＣＣＤから取得して、ＣＣＮＤの識別情報を使用してＣＣＮＤファイルを取得し、および管理エンティティは、ＣＣＮＤにアクセスして、作成されることになるコンテナクラスタノードインスタンスの展開情報を取得する。

ステップ６０５： 管理エンティティは、ＣＣＮＤ中のコンテナクラスタノードインスタンスの展開情報に基づいて、作成されることになるコンテナクラスタノードインスタンスのインスタンス化パラメータ、例えば、コンテナクラスタノード記述子の名前または識別情報と、コンテナクラスタノードのタイプと、コンテナクラスタノードが属するアフィニティ／アンチアフィニティグループとを決定する。

ステップ６０６： 管理エンティティは、コンテナクラスタノード作成要求メッセージをコンテナクラスタ管理ＣＣＭに送信し、要求メッセージは、作成されることになるコンテナクラスタノードインスタンスのタイプと、コンテナクラスタノードインスタンスが属するアフィニティ／アンチアフィニティグループとを保持する。

ステップ６０７： ＣＣＭは、コンテナクラスタノード作成応答を管理エンティティに返して、コンテナクラスタノード作成要求メッセージがうまく受信されたことを示す。

任意選択で、ステップ６０４からステップ６０７の代替方法として、ＣＣＭは、コンテナクラスタノード記述子ＣＣＮＤの識別情報をコンテナクラスタ記述子ＣＣＤから取得して、コンテナクラスタノード記述子ＣＣＮＤにアクセスすることによってコンテナクラスタノードのインスタンス化パラメータを決定する。

ステップ６０８： ＣＣＭは、更新されることになるコンテナクラスタ中のコンテナクラスタノードインスタンスを作成するプロセスを完了して、新たに作成されたコンテナクラスタノードインスタンスに関する情報をローカルに生成する。

ステップ６０９： ＣＣＭは、コンテナクラスタ更新完了通知メッセージを管理エンティティに送って、コンテナクラスタ更新プロセスが終了することを管理エンティティに示す。

本発明の実施形態３は、コンテナクラスタ削除方法を提供する。図７に示されるように、この方法は、以下のステップを具体的に含む。

ステップ７０１： 管理エンティティが、コンテナクラスタの削除要求メッセージをコンテナクラスタ管理ＣＣＭに送信し、要求メッセージは、削除されることになるコンテナクラスタインスタンスの識別情報、および／または、削除動作のタイプ、例えば、強制削除（Ｆｏｒｃｅｆｕｌ ｄｅｌｅｔｉｏｎ）もしくは正常削除（Ｇｒａｃｅｆｕｌ ｄｅｌｅｔｉｏｎ）を保持する。

ステップ７０２： ＣＣＭは、要求メッセージ中の削除動作のタイプに基づいて、削除されることになるコンテナクラスタ中のＣＩＳＭインスタンスおよび／またはＣＩＳインスタンスをローカルにアンインストールし、コンテナクラスタノードによって占有されていたレイヤＩリソースを解放し、コンテナクラスタノードインスタンスを削除して、コンテナクラスタインスタンスを削除する。加えて、ＣＣＭは、コンテナクラスタインスタンスに関する情報を削除する。

ステップ７０３： ＣＣＭは、コンテナクラスタ削除応答を管理エンティティに返して、コンテナクラスタインスタンスがうまく削除されたことを示す。

本発明のこの実施形態では、コンテナクラスタ記述子ＣＣＤおよびコンテナクラスタノード記述子ＣＣＮＤを定義する情報モデルが、ＮＦＶテンプレートに追加される。ＣＣＤは、クラスタのサイズと、スケーリング属性と、クラスタ中のオブジェクトインスタンスのアフィニティ／アンチアフィニティ規則とを主に含む。ＣＣＮＤは、ノードのタイプと、ハードウェアアクセラレーション、ネットワークインタフェース、およびローカルストレージについてのノードの要件と、コンテナクラスタ中のノード間のアフィニティ／アンチアフィニティ規則とを含む。コンテナクラスタを作成、更新、または削除するプロセスにおいて、管理エンティティは、ＣＣＤにアクセスして、作成、更新、または削除されることになるコンテナクラスタに関する情報を取得し、ＣＣＮＤにアクセスして、コンテナクラスタ中のノードに関する情報を取得して、情報に基づいて、コンテナクラスタを作成、更新、または削除する要求をＣＣＭに送信する。ＣＣＭは、コンテナクラスタの作成、更新、または削除を完了した後、応答を管理エンティティに返す。

前述の実施形態における方法を実装することによって、本発明の実施形態における解決法は、コンテナクラスタの動的管理をサポートし、大規模コンテナクラスタの一貫性のある展開およびバッチ複製を実装することができる。

上記は、本出願の実施形態で提供される解決法について、ネットワーク要素間のインタラクションの観点から主に説明している。前述の機能を実装するために、ＮＦＶＯ、ＶＮＦＭ、ＣＣＭなどは、機能を実施するための対応するハードウェア構造および／またはソフトウェアモジュールを含むことが理解され得る。本明細書で開示される実施形態で説明される例のユニットおよびアルゴリズム動作との組合せで、本出願がハードウェアによってまたはハードウェアとコンピュータソフトウェアとの組合せによって実装されることが可能であることを、当業者なら容易に認識するはずである。機能がハードウェアによって実施されるか、またはコンピュータソフトウェアによって駆動されるハードウェアによって実施されるかは、技術的解決法の特定の適用および設計制約に依存する。当業者なら、説明される機能を、特定の適用ごとに種々の方法を使用して実装し得るが、この実装が本出願の範囲を超えると考えられるべきではない。

本出願の実施形態では、ＮＦＶＯ、ＶＮＦＭ、ＣＣＭなどにおける機能モジュールは、前述の方法例に基づいて分割され得る。例えば、機能モジュールは機能に対応して分割されてもよく、または、２つ以上の機能が１つの処理モジュールに統合されてもよい。統合されたモジュールは、ハードウェアの形で実装されてもよく、またはソフトウェア機能モジュールの形で実装されてもよい。本出願の実施形態におけるモジュールの分割は、例であり、論理機能の分割にすぎないことに留意されたい。実際の実装中には、別の分割方式が使用される場合がある。

例えば、機能モジュールが統合方式で分割されるとき、図８は、通信装置８０の構造の概略図を示す。通信装置８０は、送受信機モジュール８０１および処理モジュール８０２を含む。

例えば、通信装置８０は、ＮＦＶＯまたはＶＮＦＭの機能を実装するように構成される。例えば、通信装置８０は、図５に示される実施形態、図６に示される実施形態、または図７に示される実施形態におけるＮＦＶＯまたはＶＮＦＭである。

本出願の実施形態では、通信装置８０は、ＮＦＶＯもしくはＶＮＦＭであり得、または、ＮＦＶＯもしくはＶＮＦＭに適用されるチップであり得、または、前述のＮＦＶＯもしくはＶＮＦＭの機能を有する別の結合されたデバイスもしくはコンポーネントであり得る。通信装置８０がＮＦＶＯまたはＶＮＦＭであるとき、送受信機モジュール８０１は、アンテナ、無線周波数回路などを含む場合がある送受信機であり得、および処理モジュール８０２は、プロセッサ（または処理回路）であり得、例えば、１つまたは複数のＣＰＵを備える場合があるベースバンドプロセッサであり得る。通信装置８０が、前述のＮＦＶＯまたはＶＮＦＭの機能を有するコンポーネントであるとき、送受信機モジュール８０１は無線周波数ユニットであり得、および処理モジュール８０２は、プロセッサ（または処理ユニット）、例えばベースバンドプロセッサであり得る。通信装置８０がチップシステムであるとき、送受信機モジュール８０１は、チップ（例えば、ベースバンドチップ）の入出力インタフェースであり得、および処理モジュール８０２は、チップシステムのプロセッサ（または処理回路）であり得、および１つまたは複数の中央処理装置を備え得る。本出願の実施形態における送受信機モジュール８０１は、送受信機によって、または送受信機に関連付けられる回路コンポーネントによって実装され得、および処理モジュール８０２は、プロセッサによって、またはプロセッサに関連付けられる回路コンポーネント（または処理回路と呼ばれる）によって実装され得ることを理解されたい。

例えば、送受信機モジュール８０１は、図５に示される実施形態でＮＦＶＯもしくはＶＮＦＭによって実施されるすべての受信および送信動作、例えばＳ５０３を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。処理モジュール８０２は、図５に示される実施形態でＮＦＶＯもしくはＶＮＦＭによって実施される、受信および送信動作を除いたすべての動作、例えばＳ５０１、Ｓ５０２、およびＳ５０５を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。

別の例では、送受信機モジュール８０１は、図６に示される実施形態でＮＦＶＯもしくはＶＮＦＭによって実施されるすべての受信および送信動作、例えばＳ６０３を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。処理モジュール８０２は、図６に示される実施形態でＮＦＶＯによって実施される、受信および送信動作を除いたすべての動作、例えばＳ６０１、Ｓ６０２、およびＳ６０５を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。

別の例では、送受信機モジュール８０１は、図７に示される実施形態でＮＦＶＯもしくはＶＮＦＭによって実施されるすべての受信および送信動作、例えばＳ７０１を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。処理モジュール８０２は、図６に示される実施形態でＮＦＶＯによって実施される、受信および送信動作を除いたすべての動作、例えばＳ７０３を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。

同様に、通信装置８０はまた、図５に示される実施形態、図６に示される実施形態、または図７に示される実施形態におけるＣＣＭであるＣＣＭの機能を実装して、図５から図７に示される実施形態におけるＣＣＭによって実施されるすべての動作を実施するように構成され得、および詳細について再度説明はされない。

図９は、通信システムの概略組成図を示す。図９に示されるように、通信システム９０は、管理エンティティ９０１およびＣＣＭ９０２を備え得る。図９は添付図面の例にすぎず、および図９に示される通信システム９０に含められるネットワーク要素、およびネットワーク要素の量は、本出願の実施形態において限定されないことに留意されたい。

ＮＦＶＯ９０１は、図５から図７に示される方法実施形態における管理エンティティ９０１の機能を実装するように構成される。例えば、管理エンティティ９０１は、コンテナクラスタ記述子ファイルＣＣＤにアクセスし、作成されることになるコンテナクラスタの展開情報をファイルから取得し、ＣＣＤ中のコンテナクラスタの展開情報に基づいてコンテナクラスタのインスタンス化パラメータを決定し、およびコンテナクラスタ作成要求をコンテナクラスタ管理ＣＣＭに送信するように構成され得、要求メッセージは、作成されることになるコンテナクラスタのインスタンス化パラメータを保持する。

ＣＣＭ９０２は、図５から図７に示される方法実施形態におけるＣＣＭの機能を実装するように構成される。例えば、ＣＣＭ９０２は、コンテナクラスタ作成応答を管理エンティティ９０１に返して、コンテナクラスタの作成が成功または失敗であることと作成失敗の原因とを示し、コンテナクラスタインスタンスをローカルに作成し、および指定された量のコンテナクラスタノードの初期作成を完了する。

前述の方法実施形態におけるステップの、関連付けられるすべての内容が、通信システム９０の対応するネットワーク要素の機能説明について引用され得、およびここでは詳細について再度説明はされないことに留意されたい。

実装に関する前述の説明は、簡便な説明の目的で前述の機能モジュールの分割が例証のための例とされることを当業者が理解するのを可能にする。実際の適用では、前述の機能は、異なるモジュールに割り振られて要件に従って実装されることが可能であり、すなわち、装置の内部構造は、上述された機能のすべてまたはいくつかを実装するために、異なる機能モジュールに分割される。

本出願の実施形態は、図１０に示されるようなコンピューティングデバイス１０００を提供し、コンピューティングデバイス１０００は、プログラム命令および／またはデータを記憶するように構成された、少なくとも１つのメモリ１０３０を備える。メモリ１０３０は、プロセッサ１０２０に結合される。プロセッサ１０２０は、記憶されたプログラム命令を稼働することおよび／または記憶されたデータを処理することによって、対応する機能を実装する。コンピューティングデバイス１０００は、図５から図７に示される実施形態におけるＮＦＶＯまたはＶＮＦＭであり得、および実施形態で提供される方法におけるＮＦＶＯまたはＶＮＦＭの機能を実装することができる。コンピューティングデバイス１０００は、チップシステムであり得る。本出願の実施形態では、チップシステムは、チップを含み得、または、チップおよび別のディスクリートデバイスを含み得る。

コンピューティングデバイス１０００は、伝送媒体を使用して別のデバイスと通信するように構成された通信インタフェース１０１０をさらに備え得る。例えば、別のデバイスは、制御デバイスであり得る。プロセッサ１０２０は、通信インタフェース１０１０を通してデータを受信および送信し得る。

通信インタフェース１０１０とプロセッサ１０２０とメモリ１０３０との間の具体的な接続媒体は、本出願の実施形態では限定されない。本出願のこの実施形態では、メモリ１０３０とプロセッサ１０２０と通信インタフェース１０１０とは、図１０におけるバス１０４０を使用して相互に接続される。バスは、図１０では太線を使用して表されている。他のコンポーネント間の接続の方式は、概略的に説明されるにすぎず、限定として使用されるものではない。バスは、アドレスバス、データバス、制御バスなどとして分類され得る。説明を容易にするために、図１０におけるバスは１本の太線のみを使用して表されているが、これは、１本のバスまたは１つのタイプのバスしかないことを示すものではない。

本出願の実施形態では、プロセッサ１０２０は、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイもしくは別のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタ論理デバイス、またはディスクリートハードウェアコンポーネントであり得、および本出願の実施形態で開示される方法、ステップ、および論理ブロック図を実装または実施し得る。汎用プロセッサは、マイクロプロセッサ、任意の従来型プロセッサなどであり得る。本出願の実施形態に関して開示される方法のステップは、ハードウェアプロセッサを用いて直接に実行および完了されてもよく、または、プロセッサにおいてハードウェアとソフトウェアモジュールとの組合せを使用して実行および完了されてもよい。

本出願の実施形態では、メモリ１０３０は、ハードディスクドライブ（ｈａｒｄ ｄｉｓｋ ｄｒｉｖｅ，ＨＤＤ）もしくはソリッドステートドライブ（ｓｏｌｉｄ－ｓｔａｔｅ ｄｒｉｖｅ，ＳＳＤ）などの不揮発性メモリであり得、または、揮発性メモリ（ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、例えばランダムアクセスメモリ（ｒａｎｄｏｍ－ａｃｃｅｓｓ ｍｅｍｏｒｙ，ＲＡＭ）であり得る。メモリは、予期されるプログラムコードを命令またはデータ構造の形で保持または記憶することができてコンピュータによってアクセスされることができる他の任意の媒体であるが、それに限定されない。本出願の実施形態によるメモリはさらに、記憶機能を実装することができ、およびプログラム命令および／またはデータを記憶するように構成された、回路または他の任意の装置であってもよい。

本出願の実施形態は、図１１に示されるようなコンピューティングデバイス１１００をさらに提供し、コンピューティングデバイス１１００は、プログラム命令および／またはデータを記憶するように構成された、少なくとも１つのメモリ１１３０を含む。メモリ１１３０は、プロセッサ１１２０に結合される。プロセッサ１１２０は、記憶されたプログラム命令を稼働することおよび／または記憶されたデータを処理することによって、対応する機能を実装する。コンピューティングデバイス１０００は、図５から図７に示される実施形態におけるＣＣＭであり得、および実施形態で提供される方法におけるＣＣＭの機能を実装することができる。

コンピューティングデバイス１１００はまた、伝送媒体を使用して別のデバイスと通信するように構成された通信インタフェース１１１０を備える。プロセッサ１０２０は、通信インタフェース１１１０を通してデータを受信および送信し得る。

他の機能および構造は、前述のコンピューティングデバイス１０００のそれらと同様であり、およびここでは詳細について再度説明はされない。

本出願の実施形態は、命令を記憶するように構成されたコンピュータ可読記憶媒体をさらに提供する。命令がコンピューティングデバイスのプロセッサによって実行されたとき、コンピューティングデバイスは、本出願の任意の実施形態で提供される方法を実装することが可能にされる。

本出願の実施形態はコンピュータプログラム製品をさらに提供し、コンピュータプログラム製品は、コンピュータプログラムコードを含む。コンピュータプログラムコードがコンピューティングデバイス上で稼働されたとき、コンピューティングデバイスは、本出願の任意の実施形態で提供される方法を実施することが可能にされる。

本明細書で開示される実施形態で説明されるユニットおよびアルゴリズムステップの例との組合せで、本出願が電子ハードウェアを使用して、またはコンピュータソフトウェアと電子ハードウェアとの組合せを使用して実装され得ることを、当業者なら認識し得る。機能がハードウェアのモードで実行されるかまたはソフトウェアのモードで実行されるかは、技術的解決法の特定の適用および設計制約条件に依存する。当業者なら、説明される機能を、特定の適用ごとに種々の方法を使用して実装し得るが、この実装が本出願の実施形態の範囲を超えると考えられるべきではない。

最後に、前述の実施形態は、本出願の技術的解決法について説明するように意図されているにすぎず、本出願を限定するように意図されているのではないことに留意されたい。前述の実施形態を参照しながら本出願について詳細に説明されているが、本出願の実施形態で提供される技術的解決法の範囲を逸脱することなく、前述の実施形態で提供される技術的解決法に修正が加えられてもなおよく、またはそのいくつかの技術的特徴に等価な置換が行われてもよいことを、当業者なら理解するはずである。

本出願は、通信分野に関し、特に、コンテナクラスタのための管理方法および装置に関する。

ネットワーク機能仮想化（ＮＦＶ，Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）は、遠隔通信ネットワークオペレータが、ネットワークの資本費用ＣＡＰＥＸおよび運用費用ＯＰＥＸを節約する目標を達成しながらネットワークサービス（ＮＳ，Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ）の高速で効率的な展開および運用を実装するために、情報技術（ＩＴ，Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ）の分野における仮想化技術を使用して、汎用サーバ、スイッチ、およびメモリにおける遠隔通信ネットワーク機能の一部（コアネットワーク機能など）の実装に際してソフトウェアとハードウェアとの切離しを実施することを意味する。ＮＦＶ技術を適用することによって、遠隔通信ネットワーク機能は、ソフトウェアの形で実装され、汎用サーバハードウェア上で稼働されることが可能であり、および新しいデバイスのインストールなしに必要に応じて、ネットワークの種々の物理位置に移行されること、これらの位置でインスタンス化（ｉｎｓｔａｎｔｉａｔｉｏｎ）されること、またはこれらの位置で展開されることが可能である。

ＮＦＶの標準化作業は、ネットワークサービスと、仮想化ネットワーク機能（ＶＮＦ，Ｖｉｒｔｕａｌｉｚｅｄ Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ）と、仮想リソースの動的な管理およびオーケストレーション（ＭＡＮＯ，Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｏｒｃｈｅｓｔｒａｔｉｏｎ）とに主に焦点を合わせており、ＭＡＮＯフレームワークにおける機能策定作業は、欧州電気通信標準化機構（ＥＴＳＩ，Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ）の下でＮＦＶ業界標準部会のインタフェースおよびアーキテクチャ（ＩＦＡ，ＩｎｔｅｒＦａｃｅ ａｎｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）作業部会によって完了されており、および図１にＮＦＶの機能アーキテクチャが示されており、ＮＦＶシステム１００は、以下の機能エンティティを主に備える。

ＮＦＶオーケストレータ（ＮＦＶ ｏｒｃｈｅｓｔｒａｔｏｒ，ＮＦＶＯ）１０２：ＮＳのライフサイクル管理を主に担って、ネットワーク機能仮想化インフラストラクチャ（ＮＦＶＩ，ｎｅｔｗｏｒｋ ｆｕｎｃｔｉｏｎｓ ｖｉｒｔｕａｌｉｚａｔｉｏｎ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）１０４中の仮想リソースの割振りおよびスケジューリングを担う。ＮＦＶＯ１０２は、１つまたは複数の仮想化ネットワーク機能マネージャ（ＶＮＦＭ，Ｖｉｒｔｕａｌｉｚｅｄ Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｍａｎａｇｅｒ）１０６と通信し得、およびＮＳインスタンス化に関係付けられる動作、例えば、対応する設定情報をＶＮＦＭ１０６に送信すること、または１つもしくは複数のＶＮＦ１０８のステータス情報をＶＮＦＭ１０６から要求することを実施し得る。加えて、ＮＦＶＯ１０２はさらに、仮想化インフラストラクチャマネージャ（ＶＩＭ，ｖｉｒｔｕａｌｉｚｅｄ ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ｍａｎａｇｅｒ）１１０と通信して、ＮＦＶＩ１０４中のリソースのそれぞれに対する割振りおよび／または予約を実施して、リソース構成およびステータス情報などを交換し得る。

ＶＮＦＭ１０６：１つまたは複数のＶＮＦ１０８のライフサイクル管理、例えば、ＶＮＦ１０８をインスタンス化すること（ｉｎｓｔａｎｔｉａｔｉｎｇ）、ＶＮＦ１０８を更新すること（ｕｐｄａｔｉｎｇ）、ＶＮＦ１０８に照会すること、ＶＮＦ１０８をスケーリングすること（ｓｃａｌｉｎｇ）、およびＶＮＦ１０８を終結すること（ｔｅｒｍｉｎａｔｉｎｇ）を主に担う。ＶＮＦＭ１０６は、ＶＮＦ１０８と通信して、ＶＮＦ１０８のライフサイクルを管理して、設定情報、ステータス情報などをＶＮＦと交換し得る。ＮＦＶシステム１００が１つまたは複数のＶＮＦＭ１０６を備える場合があって、ＶＮＦＭ１０６が異なるタイプのＶＮＦ１０８に対するライフサイクル管理をそれぞれ実施することが、理解され得る。

ＮＦＶＩ１０４：ＮＦＶシステム１００のインフラストラクチャであって、仮想化された環境を確立して、仮想化された環境でＶＮＦ１０８を展開、管理、および実装するために、ハードウェアコンポーネント、ソフトウェアコンポーネント、およびこれらの組合せを含む。ＮＦＶＩ１０４は、コンピューティング（ｃｏｍｐｕｔｉｎｇ）ハードウェア１０４１、ストレージハードウェア１０４２、およびネットワークハードウェア１０４３を少なくとも含み得る。ＮＦＶＩ１０４の仮想化レイヤ１０４４が、ＶＮＦ１０８のための別の形の仮想マシンおよび仮想コンテナを提供するために、前述のハードウェアを抽象化して、ハードウェアをＶＮＦ１０８から切り離して、対応する仮想コンピューティング（ｖｉｒｔｕａｌ ｃｏｍｐｕｔｉｎｇ）リソース１０４５、仮想ストレージリソース１０４６、および仮想ネットワークリソース１０４７を取得し得る。

ＶＩＭ１１０： ＶＮＦ１０８と、コンピューティングハードウェア１０４１、ストレージハードウェア１０４２、ネットワークハードウェア１０４３、仮想コンピューティングリソース１０４５、仮想ストレージリソース１０４６、および仮想ネットワークリソース１０４７との間のインタラクションを制御および管理するように主に構成される。例えば、ＶＩＭ１１０は、リソース管理機能を実施し得、例えば具体的には、対応する仮想リソースを別の形の仮想マシンまたは仮想コンテナに追加すること、およびシステム稼働プロセスにおけるＮＦＶＩ１０４の障害情報を収集することを実施し得る。加えて、ＶＩＭ１１０は、ＶＮＦＭ１０６と通信し得、例えば、リソース割振り要求をＶＮＦＭ１０６から受信することと、リソース構成およびステータス情報をＶＮＦＭ１０６にフィードバックすることとを行い得る。

ＶＮＦ１０８：ＶＮＦ１０８は、１つまたは複数のＶＮＦ（普通は複数のＶＮＦ）を含み、および専用デバイスによって元々実装されていたネットワーク機能のグループに対応するように別の形の１つまたは複数の仮想マシンまたは仮想コンテナを稼働し得る。

要素管理システム（ＥＭＳ，ｅｌｅｍｅｎｔ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）１１２：ＶＮＦ１０８を構成および管理して、ＶＮＦＭ１０６に対する新しいＶＮＦ１０８のインスタンス化などのライフサイクル管理動作を開始するように構成され得る。ＮＦＶシステム１００が１つまたは複数のＥＭＳ１１２を含む場合があることが理解され得る。

オペレーションサポートシステム（ＯＳＳ，ｏｐｅｒａｔｉｏｎｓ ｓｕｐｐｏｒｔ ｓｙｓｔｅｍ）またはビジネスサポートシステム（ＢＳＳ，ｂｕｓｉｎｅｓｓ ｓｕｐｐｏｒｔ ｓｙｓｔｅｍ）１１４： 様々なエンドツーエンド遠隔通信ビジネスをサポートすることができる。ＯＳＳによってサポートされる管理機能は、ネットワーク構成、ビジネスプロビジョン、障害管理などを含み得、およびＢＳＳは、注文、支払い、および収益など、関係付けられるビジネスを処理して、製品管理、注文管理、収益管理、および顧客管理などの機能をサポートするように構成され得る。ＯＳＳ／ＢＳＳ１１４は、ＮＳをインスタンス化するようＮＦＶＯに要求するためのビジネスリクエスタとして使用され得ること、および、ＯＳＳ／ＢＳＳ１１４、またはＯＳＳ／ＢＳＳ１１４が依拠したコンピューティングデバイスは一般にビジネスリクエスタと相応に呼ばれ得ることに留意されたい。

図１に示されるＮＦＶシステム１００中では、前述の機能エンティティが異なるコンピューティングデバイス中で別々に展開されてもよく、またはいくつかの機能エンティティが同じコンピューティングデバイスに統合されてもよいことが、理解され得る。

現在、遠隔通信分野におけるネットワークトランスフォーメーションは、ネットワーク機能仮想化（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ，ＮＦＶ）からクラウドネイティブ（Ｃｌｏｕｄ－Ｎａｔｉｖｅ）に進化するプロセスを経つつある。クラウドネイティブは、ソフトウェアをクラウド環境で構築、稼働、および管理するための新しいシステム実装パラダイムであって、クラウドインフラストラクチャおよびプラットフォームサービスを十分に活用し、クラウド環境に適応して、（マイクロ）サービタイゼーション、スケーリング、分散化、高アベイラビリティ、マルチテナント、および自動化など、鍵となる特徴を有する、アーキテクチャプラクティスである。このトランスフォーメーションにおいて、ＮＦＶ管理およびオーケストレーション（Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｏｒｃｈｅｓｔｒａｔｉｏｎ，ＭＡＮＯ）の基準アーキテクチャにコンテナ管理を導入することは、ＮＦＶからクラウドネイティブへの進化の多くのプラクティスの鍵となるリンクである。

コンテナアズアサービス（Ｃｏｎｔａｉｎｅｒ ａｓ ａ Ｓｅｒｖｉｃｅ，ＣａａＳ）は、プラットフォームアズアサービス（ＰａａＳ，Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）の具体的なタイプである。一般に、コンテナは、ＬｉｎｕｘにおけるＣＧｒｏｕｐおよびＮａｍｅＳｐａｃｅなどのオペレーティングシステム隔離技術を使用して種々のプロセスを隔離する、オペレーティングシステムレベルの仮想化技術である。ハードウェア仮想化（Ｈｙｐｅｒｖｉｓｏｒ）技術とは異なり、コンテナ技術は仮想ハードウェアを有さず、およびコンテナ内部にはオペレーティングシステムはなくプロセスのみがある。コンテナ技術のこの重要な特徴のおかげで、コンテナは、仮想マシンと比較して、より軽量であり、およびより管理しやすい。コンテナの稼働状態では、コンテナのライフサイクルを統一された方式で管理するために、開始、停止、一時停止、および削除など、共通管理動作のグループが定義される。クラウドネイティブコンピューティングファウンデーション（Ｃｌｏｕｄ Ｎａｔｉｖｅ Ｃｏｍｐｕｔｉｎｇ Ｆｏｕｎｄａｔｉｏｎ）のＫｕｂｅｒｎｅｔｅｓプロジェクトは、コンテナ管理およびオーケストレーションのための、業界で現在認識されているデファクトスタンダードである。

コンテナアズアサービスアーキテクチャを遠隔通信ネットワーククラウドネイティブの進化プロセスにおいて導入することは、遠隔通信業界の開発運用（ＤｅｖＯｐｓ）にアジリティトランスフォーメーションをもたらす。このトランスフォーメーションに対応する変化は、従来の、粒度の粗い単一ネットワーク機能が、徐々に分解されてサービス化されること、またはさらにマイクロサービス化すらされることである。サービス化される機能のそれぞれは、独立して開発、送達、および維持されて、バージョンのアップグレードはより頻繁になる。しかし、コンテナ化されたネットワーク機能の急増は、相互運用性テストのワークロードを指数関数的に増大させることはない。安定したＡＰＩインタフェース定義が、インタフェース機能呼出しの一貫性および信頼性を確実にする。

現在、コンテナ管理およびオーケストレーション分野における最も一般的な適用は、オープンソースプラットフォームに基づくＧｏｏｇｌｅのＫｕｂｅｒｎｅｔｅｓ（略してＫ８Ｓ）コンテナクラスタ管理技術である。Ｋｕｂｅｒｎｅｔｅｓの核となる考えは、「あらゆるものはサービス中心であり、およびサービスを中心として動く」というものである。この考えに基づいて、Ｋｕｂｅｒｎｅｔｅｓ上に構築されるコンテナアプリケーションシステムは、物理マシン、仮想マシン、または企業私設クラウド上で独立して稼働することができ、および公衆クラウド上でホストされることもまた可能である。Ｋｕｂｅｒｎｅｔｅｓの別の特徴は自動化であり、サービスは、自動的にスケーリングされること、自動的に診断されること、および容易にアップグレードされることが可能である。

コンテナクラスタ管理の機能範囲は、コンテナクラスタ管理（コンテナクラスタの作成または削除）と、コンテナクラスタノード管理（クラスタ中のノードの追加／削除、およびクラスタのサイズの弾力的な更新）とを含む。コンテナクラスタは、必要に応じて動的に作成され得、すなわち、ＮＦＶ ＭＡＮＯは、管理されるコンテナ化されたＶＮＦのサイズと信頼性ポリシーとに基づいて、作成されるコンテナクラスタの量とクラスタのそれぞれの容量とを決定する。

コンテナクラスタの動的管理モードでは、遠隔通信クラウドの大規模コンテナ化ＶＮＦ管理およびオーケストレーションにおいて、コンテナクラスタの作成または更新を単純で素早いものにしてバッチ動作をより効率的にするためにどのようにコンテナクラスタを管理するかが、特に重要である。現在、オープンソースコミュニティは、Ｇｏｏｇｌｅ Ｋｕｂｅａｄｍなど、いくつかの基本的なコンテナクラスタ管理プロトタイプツールを有する。しかし、これらのプロトタイプツールは、遠隔通信クラウドの大規模コンテナクラスタ展開および管理の要件を満たすことができない。

従来技術における前述の技術的問題を解決するために、本出願の実施形態は、コンテナクラスタノードリソースプールのための管理方法および装置を提供する。詳細は次のとおりである。

本出願の実施形態は、コンテナクラスタノードリソースプールのための管理方法を提供し、この方法は、以下を含む。

コンテナクラスタ管理（ＣＣＭ）が、コンテナクラスタのインスタンス化要求メッセージを管理エンティティから受信し、要求メッセージは、コンテナクラスタのインスタンス化パラメータを保持する。ＣＣＭは、コンテナクラスタのインスタンス化パラメータに基づいてコンテナクラスタをインスタンス化し、コンテナクラスタのインスタンス化パラメータは、管理エンティティによって、コンテナクラスタ記述子（ＣＣＤ）にアクセスすることによって決定される。

この方法は、以下をさらに含む。

ＣＣＭは、コンテナクラスタノードのインスタンス化要求メッセージを管理エンティティから受信し、要求メッセージは、コンテナクラスタノードのインスタンス化パラメータを保持する。コンテナクラスタノードのインスタンス化パラメータは、管理エンティティによって、コンテナクラスタノード記述子（ＣＣＮＤ）にアクセスすることによって決定され、または、ＣＣＭが、ＣＣＮＤにアクセスしてコンテナクラスタノードのインスタンス化パラメータを決定する。

ＣＣＭは、コンテナクラスタノードのインスタンス化パラメータに基づいてコンテナクラスタノードをインスタンス化し、コンテナクラスタのインスタンス化パラメータに基づいてコンテナクラスタノード上でＣＩＳＭインスタンスおよびＣＩＳインスタンスをインスタンス化する。

この方法は、以下をさらに含む。ＣＣＭは、コンテナクラスタの更新要求メッセージを管理エンティティから受信し、要求メッセージは、更新されることになるコンテナクラスタインスタンスのパラメータを保持する。ＣＣＭは、更新されることになるコンテナクラスタインスタンスのパラメータに基づいて、コンテナクラスタインスタンスを更新する。

この方法は、以下をさらに含む。ＣＣＭは、コンテナクラスタの削除要求メッセージを管理エンティティから受信し、削除要求メッセージは、削除されることになるコンテナクラスタインスタンスの識別情報、および／または削除動作のタイプを保持する。ＣＣＭは、コンテナクラスタインスタンスを削除する。

本出願の実施形態は、コンテナクラスタのための管理システムを提供し、このシステムは、
コンテナクラスタ記述子（ＣＣＤ）に基づいてコンテナクラスタのインスタンス化パラメータを決定し、コンテナクラスタのインスタンス化パラメータをコンテナクラスタ管理（ＣＣＭ）に送信するように構成された管理エンティティと、コンテナクラスタのインスタンス化パラメータに基づいてコンテナクラスタをインスタンス化するように構成されたＣＣＭとを含む。

管理エンティティは、コンテナクラスタノード記述子（ＣＣＮＤ）にアクセスしてコンテナクラスタノードのインスタンス化パラメータを決定し、コンテナクラスタノードのインスタンス化パラメータをＣＣＭに送信するように、さらに構成される。

ＣＣＭは、コンテナクラスタノードのインスタンス化パラメータに基づいてコンテナクラスタノードをインスタンス化し、コンテナクラスタのインスタンス化パラメータに基づいてコンテナクラスタノード上でＣＩＳＭインスタンスおよびＣＩＳインスタンスをインスタンス化する。

本出願の実施形態は、前述の方法ステップを実施するように構成されたモジュールを含む、コンテナクラスタのための管理装置をさらに提供する。

本出願の実施形態は、プロセッサとメモリとを含む、コンテナクラスタのための管理装置をさらに提供し、プロセッサはメモリに結合され、メモリはコンピュータプログラムを記憶する。プロセッサは、メモリ中のコンピュータプログラムを呼び出して、前述の方法を管理装置が実施するのを可能にするように構成される。

本出願の実施形態は、コンピュータ可読記憶媒体をさらに提供し、記憶媒体はコンピュータプログラムを記憶する。コンピュータプログラムが実行されたとき、前述の方法が実施される。

本出願の実施形態は、コンピュータプログラム製品をさらに提供し、コンピュータプログラム製品はコンピュータプログラムコードを含む。コンピュータプログラムコードがコンピューティングデバイス上で稼働されたとき、コンピューティングデバイスは、前述の方法を実施することが可能にされる。

本発明の実施形態の解決法を用いて、コンテナクラスタ記述子テンプレートおよびコンテナクラスタノード記述子テンプレートが定義され、コンテナクラスタのための動的管理がサポートされ、大規模コンテナクラスタの一貫性のある展開およびバッチ複製が実装される。

実施形態または従来技術の説明で使用されることが必要な添付図面について、以下に簡潔に説明される。

従来技術におけるＮＦＶシステムのフレームワーク図である。 本出願の実施形態による、Ｋｕｂｅｒｎｅｔｅｓ（Ｋ８Ｓ）コンテナ管理およびオーケストレーションシステムのアーキテクチャ図である。 本出願の実施形態による、コンテナクラスタを管理するためのＮＦＶ管理およびオーケストレーションシステムのアーキテクチャ図である。 本出願の実施形態による、コンテナクラスタとコンテナクラスタノードと名前空間との間の論理関係の図である。 本出願の実施形態による、コンテナクラスタを作成することの概略フローチャートである。 本出願の実施形態による、コンテナクラスタを更新することの概略フローチャートである。 本出願の実施形態による、コンテナクラスタを削除することの概略フローチャートである。 本出願の実施形態による、管理エンティティ装置の概略モジュール図である。 本出願の実施形態による、ＣＣＭ装置の概略モジュール図である。 本出願の実施形態による、管理エンティティ装置のハードウェア構造の概略図である。 本出願の実施形態による、ＣＣＭ装置のハードウェア構造の概略図である。

以下、本出願の実施形態における技術的解決法について、本出願の実施形態における添付図面を参照しながら説明する。

図２を参照されたいが、これは、Ｋｕｂｅｒｎｅｔｅｓ（Ｋ８Ｓ）コンテナ管理およびオーケストレーションシステムのアーキテクチャ図である。

Ｋｕｂｅｒｎｅｔｅｓは、コンテナクラスタ中のインフラストラクチャリソースを、Ｋｕｂｅｒｎｅｔｅｓマスタノード（ｍａｓｔｅｒ）とワーカーノード（Ｎｏｄｅ）のグループとに分割する。マスタノード（管理ノードとも呼ばれる）上では、コンテナクラスタ管理に関係付けられるプロセス、例えば、アプリケーションプログラミングインタフェースサーバ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ Ｓｅｒｖｅｒ，ＡＰＩ Ｓｅｒｖｅｒ）およびレプリケーションコントローラ（Ｒｅｐｌｉｃａｔｉｏｎ Ｃｏｎｔｔｒｏｌｌｅｒ，ＲＣ）、のグループが稼働する。これらのプロセスは、コンテナクラスタ全体の、リソース管理、コンテナポッド（Ｐｏｄ）スケジューリング、スケーリング、セキュリティ制御、システム監視、および誤り訂正などの管理機能を実装する。ワーカーノードのそれぞれでは、Ｋｕｂｅｌｅｔ、Ｐｒｏｘｙ、およびＤｏｃｋｅｒという３つのコンポーネントが稼働されて、現ノード上のポッドのライフサイクルを管理することおよびサービスプロキシ機能を実装することを担う。図２に示されるように、ポッドは、少なくとも１つのコンテナを含み得る。この場合、ポッドは、１つまたは複数のコンテナを含むコンテナポッドとして理解され得る。

ＡＰＩサーバは、リソースオブジェクトに対する一意の操作エントリを提供して、他のすべてのコンポーネントは、ＡＰＩサーバによって提供されるＡＰＩインタフェースを通してリソースデータを操作する必要があって、関係付けられるリソースデータに対する「完全な照会」および「変化監視」を実施することによって、関係付けられるビジネス機能を実装する。

コントローラマネージャは、コンテナクラスタの管理および制御センタであって、Ｋｕｂｅｒｎｅｔｅｓクラスタの自動障害検出および回復を実装するという主目的を有する。例えば、ポッドの複製または除去は、ポッドインスタンスの量がＲＣの定義に確実に準拠するようにＲＣの定義に基づいて実施されることが可能であって、サービスのエンドポイント（Ｅｎｄｐｏｉｎｔ）オブジェクトの作成および更新と、ノードの発見、管理、および状態監視と、ローカルにキャッシュされたイメージファイルのクリーニングとは、サービス（Ｓｅｒｖｉｃｅ）とポッドとの間の管理関係に基づいて実施されることが可能である。

Ｋｕｂｅｌｅｔコンポーネントは、現ノード上のポッドの作成、修正、監視、および削除を含めた、完全なライフサイクル管理を担う。加えて、Ｋｕｂｅｌｅｔは、現ノードのステータス情報をＡＰＩサーバに定期的に報告する。

Ｐｒｏｘｙコンポーネントは、サービスのプロキシパターンとソフトウェアパターンとの間の負荷平衡化を実装するように構成される。

Ｄｏｃｋｅｒコンポーネントは、コンテナの稼働環境である。

欧州電気通信標準化機構（Ｅｕｒｏｐｅａｎ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｔａｎｄａｒｄｓ Ｉｎｓｔｉｔｕｔｅ，ＥＴＳＩ）の下におけるＮＦＶ業界標準部会は、Ｒｅｌｅａｓｅ ４の特徴的な作業において、ＮＦＶ管理およびオーケストレーション（Ｍａｎａｇｅｍｅｎｔ ａｎｄ Ｏｒｃｈｅｓｔｒａｔｉｏｎ）システム管理コンテナの標準機能を定義している。図３に示されるように、この基準機能のフレームワークでは、右側の管理プレーンが、新たに導入された下記の２つの論理機能を有する。

コンテナインフラストラクチャサービス管理（Ｃｏｎｔａｉｎｅｒ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｓｅｒｖｉｃｅ Ｍａｎａｇｅｍｅｎｔ，ＣＩＳＭ）（ＣａａＳ管理とも呼ばれ、そのオープンソースプロトタイプはＫｕｂｅｒｎｅｔｅｓである）は、コンテナ化されたＶＮＦによって呼び出されるコンテナオブジェクトを管理することを担い、これは、コンテナオブジェクトを作成、更新、および削除することと、ＣＩＳＭによって管理されるコンテナクラスタノードリソースプール中の対応するノードリソース（コンピューティング、ストレージ、およびネットワークリソース）に対してコンテナオブジェクトをスケジュールすることとを含む。ＥＴＳＩ標準におけるコンテナオブジェクトの対応する概念は、マネージドコンテナインフラストラクチャオブジェクト（Ｍａｎａｇｅｄ Ｃｏｎｔａｉｎｅｒ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｏｂｊｅｃｔ，ＭＣＩＯ）である。

コンテナクラスタ管理（Ｃｏｎｔａｉｎｅｒ Ｃｌｕｓｔｅｒ Ｍａｎａｇｅｍｅｎｔ，ＣＣＭ）は、コンテナクラスタを管理することを担い、これは、コンテナクラスタによって使用されるノードリソースプールを作成すること、およびノードをスケーリングすることを含む。コンテナクラスタは、監視および管理システム（例えば、図２におけるＫｕｂｅｒｎｅｔｅｓ Ｍａｓｔｅｒ）と、一連のコンピューティングノード（例えば、図２におけるノード、これは物理サーバ、ベアメタル、または仮想マシンであり得る）とによって形成されるセットである。コンテナクラスタは動的なシステムであり、システム中で複数のコンテナが展開されることが可能であって、システムはこれらのコンテナのステータスおよびコンテナ間の通信を監視することができる。ＥＴＳＩ標準におけるコンテナクラスタの対応する概念は、コンテナインフラストラクチャサービスクラスタ（Ｃｏｎｔａｉｎｅｒ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｓｅｒｖｉｃｅ Ｃｌｕｓｔｅｒ，ＣＩＳ Ｃｌｕｓｔｅｒ）である。

コンテナ化されたＶＮＦは、コンピューティング、ストレージ、およびネットワークリソースなどのＮＦＶＩリソースをカプセル化するコンテナ化されたワークロード（ｃｏｎｔａｉｎｅｒｉｚｅｄ ｗｏｒｋｌｏａｄ）として理解され得る。ワークロードによって呼び出されるコンテナオブジェクトＭＣＩＯは、稼働させることになるコンテナクラスタのノード上にスケジュールされる。コンテナクラスタは、ノード上の、ＣＩＳＭインスタンス（Ｋｕｂｅｒｎｅｔｅｓ ＭａｓｔｅｒなどのＣａａＳ管理プレーン機能）のイメージ、またはコンテナインフラストラクチャサービス（Ｃｏｎｔａｉｎｅｒ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ Ｓｅｒｖｉｃｅ，ＣＩＳ）インスタンス（Ｋｕｂｅｒｎｅｔｅｓワーカーノード上のｋｕｂｅｌｅｔ、ｋｕｂｅ－ｐｒｏｘｙ、およびｄｏｃｋｅｒなど、ＣａａＳユーザプレーン機能）のイメージをロードする。ＥＴＳＩ ＮＦＶ標準では、コンテナクラスタのそれぞれにおけるＣＩＳＭは、名前空間（ｎａｍｅｓｐａｃｅ）の作成、読取り、更新、および削除（Ｃｒｅａｔｉｎｇ／Ｒｅａｄｉｎｇ／Ｕｐｄａｔｉｎｇ／Ｄｅｌｅｔｉｎｇ，ＣＲＵＤ）などの管理機能を提供する。名前空間は、具体的な識別子、リソース、ポリシー、および許可のグループによって形成される論理グループであって、サーバにおけるフォルダの機能に類似する機能を有する。ＮＦＶＯは、コンテナクラスタ中で複数の名前空間を作成して、名前空間を通してコンテナクラスタ中の複数のテナント（すなわち、コンテナ化されたＶＮＦ）のコンテナオブジェクトＭＣＩＯのリソースおよび識別子を隔離し得る。図４に、コンテナクラスタ（ＣＩＳ ｃｌｕｓｔｅｒ）とコンテナクラスタノード（ＣＩＳ ｃｌｕｓｔｅｒ ｎｏｄｅ）と名前空間（ｎａｍｅｓｐａｃｅ）との間の関係が示されている。ＣＩＳＭおよびＣＣＭは、ＮＦＶＯまたはＶＮＦＭに、それらの機能をノースバウンドインタフェース上で呼び出すための管理サービスを提供する。

本発明の解決法は、ＮＦＶテンプレートに基づくコンテナクラスタのための管理方法を提供し、コンテナクラスタ記述子テンプレートおよびコンテナクラスタノード記述子テンプレートを定義することと、新たに定義される記述子テンプレートをコンテナクラスタ管理プロセスにおいて適用することとによって、コンテナクラスタの動的管理がサポートされて、大規模コンテナクラスタの一貫性のある展開およびバッチ複製が実装される。

コンテナクラスタ記述子（ＣＣＤ，ＣＩＳ Ｃｌｕｓｔｅｒ Ｄｅｓｃｒｉｐｔｏｒ）は、コンテナクラスタの展開および動作挙動要件を記述して本発明の実施形態において定義される、ＮＦＶテンプレートファイルのタイプである。ＣＣＤについては、ＶＮＦＤ（Ｖｉｒｔｕａｌ Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｄｅｓｃｒｉｐｔｏｒ）のテンプレートに類似するテンプレートを参照または使用されたい。テンプレートは、限定はされないが以下の基本的な展開情報を含む。

コンテナクラスタ記述子の名前情報、識別情報、プロバイダ情報、およびバージョン情報。

コンテナクラスタのサイズ（ｓｉｚｅ）、すなわち、コンテナクラスタに含まれるＣＩＳＭインスタンスの最大量および／またはＣＩＳインスタンスの最大量。

スケーリング動作の間にコンテナクラスタによって実施され得る最小ステップ、最大ステップ、および／または到達可能スケーリングレベル（Ｓｃａｌｅ ｌｅｖｅｌ）を含めた、コンテナクラスタのスケール（ｓｃａｌｅ）動作の基本的な特性。

コンテナクラスタ全体のアフィニティ／アンチアフィニティ規則は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンスが位置するアフィニティ／アンチアフィニティグループの識別情報であって、これは、ＣＣＤに基づいて作成されるコンテナクラスタインスタンスと、別のＣＣＤに基づいて作成されるコンテナクラスタインスタンスとの間のアフィニティ／アンチアフィニティ関係を示すためのものである。アフィニティグループは、リソース類似性に基づいて形成される論理関係グループであり、および同じアフィニティグループに属するオブジェクトは、展開中に類似するリソースを使用し、例えば、アフィニティグループ中のすべてのオブジェクトは、同じデータセンタ中で展開され、アンチアフィニティグループは、リソース差異に基づいて形成される論理関係グループであり、同じアンチアフィニティグループに属するオブジェクトは、展開中に異なるリソースを使用し、例えば、アンチアフィニティグループ中のすべてのオブジェクトは、異なるデータセンタ中で展開される。

コンテナクラスタ中で展開されるＣＩＳＭインスタンス間のアフィニティ／アンチアフィニティ規則は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳＭインスタンスが位置するアフィニティ／アンチアフィニティグループの識別情報を指し、およびこれは、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳＭインスタンスと、ＣＣＤに基づいて作成される同じコンテナクラスタインスタンス中の別のＣＩＳＭインスタンスとの間のアフィニティ／アンチアフィニティ関係を示すためのものである。

コンテナクラスタ中で展開されるＣＩＳインスタンス間のアフィニティ／アンチアフィニティ規則は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳインスタンスが位置するアフィニティ／アンチアフィニティグループの識別情報を指し、およびこれは、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳインスタンスと、ＣＣＤに基づいて作成される同じコンテナクラスタインスタンス中の別のＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ関係を示すためのものである。

コンテナクラスタ中で展開されるＣＩＳＭインスタンスとＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ規則は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳＭインスタンスおよびＣＩＳインスタンスが位置するアフィニティ／アンチアフィニティグループの識別情報を指し、およびこれは、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳＭインスタンスと、ＣＣＤに基づいて作成されるコンテナクラスタインスタンス中のＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ関係を示すためのものである。

１次コンテナクラスタ外部ネットワーク（ｐｒｉｍａｒｙ ＣＩＳ ｃｌｕｓｔｅｒ ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ）の特徴は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンスの１次外部ネットワークの基本的な設定情報、例えば、コンテナクラスタ中のコンテナが外部ネットワークに接続するためのＩＰアドレスおよびポートの特徴要件を指す。１次コンテナクラスタ外部ネットワークは、コンテナクラスタの外部公衆ネットワークであり、コンテナクラスタ中のコンテナ（ＯＳコンテナ）は、基礎をなすコンテナインフラストラクチャレイヤのネイティブネットワーク能力を通して、外部公衆ネットワークに間接的に接続される。

２次コンテナクラスタ外部ネットワーク（ｓｅｃｏｎｄａｒｙ ＣＩＳ ｃｌｕｓｔｅｒ ｅｘｔｅｒｎａｌ ｎｅｔｗｏｒｋ）の特徴は、ＣＣＤに基づいて作成されるコンテナクラスタインスタンスの２次外部ネットワークの基本的な設定情報、例えば、コンテナクラスタによって使用されるコンテナネットワークインタフェース（Ｃｏｎｔａｉｎｅｒ Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ，ＣＮＩ）の特徴要件を指し、２次コンテナクラスタ外部ネットワークは、コンテナクラスタの外部露出ネットワークを指し、およびコンテナクラスタ中のコンテナ（ＯＳコンテナ）は、１次ネットワークインタフェースとは異なる別のネットワークインタフェースを通して、直接に相互接続される。

コンテナクラスタノード記述子（ＣＣＮＤ，ＣＩＳ Ｃｌｕｓｔｅｒ Ｎｏｄｅ Ｄｅｓｃｒｉｐｔｏｒ）は、コンテナクラスタノードの展開および動作挙動要件を記述するＮＦＶテンプレートファイルのタイプである。ＣＣＮＤは、仮想コンピューティングまたはストレージリソース記述子の定義に類似し、限定はされないが以下の展開情報を含む。

ＣＣＮＤに基づいて作成されるコンテナクラスタノードのタイプ。例えば、ノードのタイプが物理マシン（ベアメタル）であるかまたは仮想マシンであるかを示す。

ハードウェアアクセラレーション、ネットワークインタフェース、およびローカルストレージについての、ＣＣＮＤに基づいて作成されるコンテナクラスタノードの要件。

ＣＣＮＤに基づいて作成されるコンテナクラスタ中のノード間のアフィニティ／アンチアフィニティ規則は、ＣＣＮＤに基づいて作成されるコンテナクラスタノードインスタンスが位置するアフィニティ／アンチアフィニティグループの識別情報を指し、およびこれは、ＣＣＮＤに基づいて作成されるコンテナクラスタノード（またはコンテナクラスタノードインスタンスと呼ばれる）と、ＣＣＮＤに基づいて作成される別のコンテナクラスタノードインスタンスとの間のアフィニティ／アンチアフィニティ関係を示すためのものである。

前述のテンプレートファイルに基づいて、本発明の実施形態１は、コンテナクラスタ作成（またはインスタンス化と呼ばれる）方法を提供する。図５に示されるように、この方法は、以下のステップを具体的に含む。

ステップ５０１： ＮＦＶ ＭＡＮＯ管理エンティティ（または、略して管理エンティティ、以下同様）が、コンテナクラスタ記述子（ＣＣＤ）にアクセスして、作成されることになるコンテナクラスタ（またはコンテナクラスタインスタンスと呼ばれる）の展開情報をＣＣＤファイルから取得する。

管理エンティティは、ＮＦＶＯまたはＶＮＦＭであり得、およびどちらがこの実施形態における方法のすべてのステップを具体的に実施するかは、システム構成に依存する。これは本明細書において特に限定されない。

ステップ５０２： 管理エンティティは、ＣＣＤ中のコンテナクラスタの展開情報に基づいて、作成されることになるコンテナクラスタインスタンスのインスタンス化パラメータ、例えば、コンテナクラスタ記述子（ＣＣＤ）の名前または識別情報と、コンテナクラスタのサイズと、コンテナクラスタの初期化中に作成されるＣＩＳＭインスタンスの量およびＣＩＳインスタンスの量と、コンテナクラスタ中のＣＩＳＭインスタンス間、ＣＩＳインスタンス間、およびＣＩＳＭインスタンスとＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ規則とを決定する。

管理エンティティは、コンテナクラスタ記述子（ＣＣＤ）中のコンテナクラスタの展開情報を、コンテナクラスタインスタンスのインスタンス化パラメータとして使用してもよく、または、展開情報を満たすことに基づいて別のネットワーク要素システム（ＯＳＳ／ＢＳＳなど）の入力を参照して、コンテナクラスタインスタンスのインスタンス化パラメータを決定してもよい。

ステップ５０３： 管理エンティティは、コンテナクラスタ作成要求をコンテナクラスタ管理（ＣＣＭ）に送信し、要求メッセージは、作成されることになるコンテナクラスタのサイズと、コンテナクラスタの初期化中に作成されるＣＩＳＭインスタンスの量およびＣＩＳインスタンスの量と、コンテナクラスタ中のＣＩＳＭインスタンス間、ＣＩＳインスタンス間、およびＣＩＳＭインスタンスとＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ規則とを保持する。

ステップ５０４： ＣＣＭは、コンテナクラスタ作成応答を管理エンティティに返して、コンテナクラスタ作成要求メッセージがうまく受信されたことを示す。

ステップ５０５： ＣＣＭは、コンテナクラスタ管理プロセスの変更通知を管理エンティティに送って、コンテナクラスタインスタンス化プロセスが開始することを管理エンティティに示す。

ステップ５０６： 管理エンティティは、作成されることになるコンテナクラスタノードインスタンスのコンテナクラスタノード記述子（ＣＣＮＤ）の識別情報をコンテナクラスタ記述子（ＣＣＤ）から取得して、ＣＣＮＤの識別情報を使用してＣＣＮＤファイルを取得し、および管理エンティティは、ＣＣＮＤにアクセスして、作成されることになるコンテナクラスタノードインスタンスの展開情報を取得する。

ステップ５０７： 管理エンティティは、ＣＣＮＤ中のコンテナクラスタノードの展開情報に基づいて、作成されることになるコンテナクラスタノードインスタンスのインスタンス化パラメータ、例えば、コンテナクラスタノードのタイプと、コンテナクラスタノードが属するアフィニティ／アンチアフィニティグループとを決定する。

ステップ５０８： 管理エンティティは、コンテナクラスタノード作成要求をコンテナクラスタ管理（ＣＣＭ）に送信し、要求メッセージは、作成されることになるコンテナクラスタノードの記述子の名前または識別情報と、コンテナクラスタノードのタイプと、コンテナクラスタノードが属するアフィニティ／アンチアフィニティグループとを保持する。

ステップ５０９： ＣＣＭは、コンテナクラスタノード作成応答を管理エンティティに返して、コンテナクラスタノード作成要求メッセージがうまく受信されたことを示す。

任意選択で、ステップ５０６からステップ５０９の代替方法として、ＣＣＭは、コンテナクラスタノード記述子（ＣＣＮＤ）の識別情報をコンテナクラスタ記述子（ＣＣＤ）から取得して、コンテナクラスタノード記述子（ＣＣＮＤ）にアクセスすることによってコンテナクラスタノードのインスタンス化パラメータを決定する。

同様に、ＣＣＭは、コンテナクラスタ記述子（ＣＣＤ）中のコンテナクラスタの展開情報を、コンテナクラスタインスタンスのインスタンス化パラメータとして使用してもよく、または、展開情報を満たすことに基づいて別のネットワーク要素システム（ＯＳＳ／ＢＳＳなど）の入力を参照して、コンテナクラスタインスタンスのインスタンス化パラメータを決定してもよい。

ステップ５１０： ＣＣＭは、作成されることになるコンテナクラスタ中の初期化されたコンテナクラスタノードを作成するプロセスを完了して、それにより、コンテナクラスタインスタンスの作成をローカルに完了する。さらに、ＣＣＭは、コンテナクラスタ記述子（ＣＣＤ）にアクセスして、展開されることになるＣＩＳＭインスタンスおよび／またはＣＩＳインスタンスのソフトウェアイメージ（ｉｍａｇｅ）情報を取得して、ＣＩＳＭインスタンスおよびＣＩＳインスタンスをコンテナクラスタノード上で展開し（任意選択で、ＣＩＳインスタンスはまた、作成されたＣＩＳＭインスタンスを使用して作成されてもよい）、およびＣＣＭは、コンテナクラスタインスタンスに関する情報、例えば、インスタンス化されたコンテナクラスタインスタンスによって使用されるＣＣＤ識別情報およびバージョンと、インスタンス化ステータスと、スケーリングステータスと、許容される最大スケーリングレベルと、外部ネットワーク情報と、ノードリソース情報とを作成する。

ＣＩＳＭインスタンスのソフトウェアイメージ、および／またはＣＩＳインスタンスのソフトウェアイメージは、ＮＦＶ－ＭＡＮＯ管理ドメイン中のコンテナクラスタのパッケージファイルに記憶されていてもよく、またはＮＦＶ－ＭＡＮＯ管理ドメイン外部のソフトウェアイメージレジストリ（ｉｍａｇｅ ｒｅｇｉｓｔｒｙ）に記憶されていてもよく、およびコンテナクラスタ記述子（ＣＣＤ）は、ＣＩＳＭインスタンスのソフトウェアイメージおよび／もしくはＣＩＳインスタンスのソフトウェアイメージを記憶したコンテナクラスタのパッケージファイルを指すかまたは外部ソフトウェアイメージレジストリのディレクトリアドレスを指す、インデックス情報を含むことに留意されたい。

ステップ５１１： ＣＣＭは、コンテナクラスタ管理プロセスの変更通知を管理エンティティに送り、およびコンテナクラスタインスタンス化終了通知メッセージを管理エンティティに送信する。

本発明の実施形態２は、コンテナクラスタ更新方法を提供する。図６に示されるように、この方法は、以下のステップを具体的に含む。

ステップ６０１： 管理エンティティが、コンテナクラスタ更新要求をコンテナクラスタ管理（ＣＣＭ）に送信し、要求メッセージは、更新されることになるコンテナクラスタインスタンスの識別情報と、スケーリングである更新動作のタイプと、スケーリングまたはスケーリングレベルによって到達されるターゲットコンテナクラスタのサイズと、スケーリングのターゲットコンテナクラスタのノード間のアフィニティ／アンチアフィニティ規則とを保持する。

ステップ６０２： ＣＣＭは、コンテナクラスタ更新応答を管理エンティティに返して、コンテナクラスタ更新要求メッセージがうまく受信されたことを示す。

ステップ６０３： ＣＣＭは、コンテナクラスタ管理プロセスの変更通知を管理エンティティに送って、コンテナクラスタ更新プロセスが開始することを管理エンティティに示す。

ステップ６０４： 管理エンティティは、更新されることになるコンテナクラスタノードインスタンスのコンテナクラスタノード記述子（ＣＣＮＤ）の識別情報をコンテナクラスタ記述子（ＣＣＤ）から取得して、ＣＣＮＤの識別情報を使用してＣＣＮＤファイルを取得し、および管理エンティティは、ＣＣＮＤにアクセスして、作成されることになるコンテナクラスタノードインスタンスの展開情報を取得する。

ステップ６０５： 管理エンティティは、ＣＣＮＤ中のコンテナクラスタノードインスタンスの展開情報に基づいて、作成されることになるコンテナクラスタノードインスタンスのインスタンス化パラメータ、例えば、コンテナクラスタノード記述子の名前または識別情報と、コンテナクラスタノードのタイプと、コンテナクラスタノードが属するアフィニティ／アンチアフィニティグループとを決定する。

ステップ６０６： 管理エンティティは、コンテナクラスタノード作成要求メッセージをコンテナクラスタ管理（ＣＣＭ）に送信し、要求メッセージは、作成されることになるコンテナクラスタノードインスタンスのタイプと、コンテナクラスタノードインスタンスが属するアフィニティ／アンチアフィニティグループとを保持する。

ステップ６０７： ＣＣＭは、コンテナクラスタノード作成応答を管理エンティティに返して、コンテナクラスタノード作成要求メッセージがうまく受信されたことを示す。

任意選択で、ステップ６０４からステップ６０７の代替方法として、ＣＣＭは、コンテナクラスタノード記述子（ＣＣＮＤ）の識別情報をコンテナクラスタ記述子（ＣＣＤ）から取得して、コンテナクラスタノード記述子（ＣＣＮＤ）にアクセスすることによってコンテナクラスタノードのインスタンス化パラメータを決定する。

ステップ６０８： ＣＣＭは、更新されることになるコンテナクラスタ中のコンテナクラスタノードインスタンスを作成するプロセスを完了して、新たに作成されたコンテナクラスタノードインスタンスに関する情報をローカルに生成する。

ステップ６０９： ＣＣＭは、コンテナクラスタ更新完了通知メッセージを管理エンティティに送って、コンテナクラスタ更新プロセスが終了することを管理エンティティに示す。

本発明の実施形態３は、コンテナクラスタ削除方法を提供する。図７に示されるように、この方法は、以下のステップを具体的に含む。

ステップ７０１： 管理エンティティが、コンテナクラスタの削除要求メッセージをコンテナクラスタ管理（ＣＣＭ）に送信し、要求メッセージは、削除されることになるコンテナクラスタインスタンスの識別情報、および／または、削除動作のタイプ、例えば、強制削除（Ｆｏｒｃｅｆｕｌ ｄｅｌｅｔｉｏｎ）もしくは正常削除（Ｇｒａｃｅｆｕｌ ｄｅｌｅｔｉｏｎ）を保持する。

ステップ７０２： ＣＣＭは、要求メッセージ中の削除動作のタイプに基づいて、削除されることになるコンテナクラスタ中のＣＩＳＭインスタンスおよび／またはＣＩＳインスタンスをローカルにアンインストールし、コンテナクラスタノードによって占有されていたレイヤＩリソースを解放し、コンテナクラスタノードインスタンスを削除して、コンテナクラスタインスタンスを削除する。加えて、ＣＣＭは、コンテナクラスタインスタンスに関する情報を削除する。

ステップ７０３： ＣＣＭは、コンテナクラスタ削除応答を管理エンティティに返して、コンテナクラスタインスタンスがうまく削除されたことを示す。

本発明のこの実施形態では、コンテナクラスタ記述子（ＣＣＤ）およびコンテナクラスタノード記述子（ＣＣＮＤ）を定義する情報モデルが、ＮＦＶテンプレートに追加される。ＣＣＤは、クラスタのサイズと、スケーリング属性と、クラスタ中のオブジェクトインスタンスのアフィニティ／アンチアフィニティ規則とを主に含む。ＣＣＮＤは、ノードのタイプと、ハードウェアアクセラレーション、ネットワークインタフェース、およびローカルストレージについてのノードの要件と、コンテナクラスタ中のノード間のアフィニティ／アンチアフィニティ規則とを含む。コンテナクラスタを作成、更新、または削除するプロセスにおいて、管理エンティティは、ＣＣＤにアクセスして、作成、更新、または削除されることになるコンテナクラスタに関する情報を取得し、ＣＣＮＤにアクセスして、コンテナクラスタ中のノードに関する情報を取得して、情報に基づいて、コンテナクラスタを作成、更新、または削除する要求をＣＣＭに送信する。ＣＣＭは、コンテナクラスタの作成、更新、または削除を完了した後、応答を管理エンティティに返す。

前述の実施形態における方法を実装することによって、本発明の実施形態における解決法は、コンテナクラスタの動的管理をサポートし、大規模コンテナクラスタの一貫性のある展開およびバッチ複製を実装することができる。

上記は、本出願の実施形態で提供される解決法について、ネットワーク要素間のインタラクションの観点から主に説明している。前述の機能を実装するために、ＮＦＶＯ、ＶＮＦＭ、ＣＣＭなどは、機能を実施するための対応するハードウェア構造および／またはソフトウェアモジュールを含むことが理解され得る。本明細書で開示される実施形態で説明される例のユニットおよびアルゴリズム動作との組合せで、本出願がハードウェアによってまたはハードウェアとコンピュータソフトウェアとの組合せによって実装されることが可能であることを、当業者なら容易に認識するはずである。機能がハードウェアによって実施されるか、またはコンピュータソフトウェアによって駆動されるハードウェアによって実施されるかは、技術的解決法の特定の適用および設計制約に依存する。当業者なら、説明される機能を、特定の適用ごとに種々の方法を使用して実装し得るが、この実装が本出願の範囲を超えると考えられるべきではない。

本出願の実施形態では、ＮＦＶＯ、ＶＮＦＭ、ＣＣＭなどにおける機能モジュールは、前述の方法例に基づいて分割され得る。例えば、機能モジュールは機能に対応して分割されてもよく、または、２つ以上の機能が１つの処理モジュールに統合されてもよい。統合されたモジュールは、ハードウェアの形で実装されてもよく、またはソフトウェア機能モジュールの形で実装されてもよい。本出願の実施形態におけるモジュールの分割は、例であり、論理機能の分割にすぎないことに留意されたい。実際の実装中には、別の分割方式が使用される場合がある。

例えば、機能モジュールが統合方式で分割されるとき、図８は、通信装置８０の構造の概略図を示す。通信装置８０は、送受信機モジュール８０１および処理モジュール８０２を含む。

例えば、通信装置８０は、ＮＦＶＯまたはＶＮＦＭの機能を実装するように構成される。例えば、通信装置８０は、図５に示される実施形態、図６に示される実施形態、または図７に示される実施形態におけるＮＦＶＯまたはＶＮＦＭである。

本出願の実施形態では、通信装置８０は、ＮＦＶＯもしくはＶＮＦＭであり得、または、ＮＦＶＯもしくはＶＮＦＭに適用されるチップであり得、または、前述のＮＦＶＯもしくはＶＮＦＭの機能を有する別の結合されたデバイスもしくはコンポーネントであり得る。通信装置８０がＮＦＶＯまたはＶＮＦＭであるとき、送受信機モジュール８０１は、アンテナ、無線周波数回路などを含む場合がある送受信機であり得、および処理モジュール８０２は、プロセッサ（または処理回路）であり得、例えば、１つまたは複数のＣＰＵを備える場合があるベースバンドプロセッサであり得る。通信装置８０が、前述のＮＦＶＯまたはＶＮＦＭの機能を有するコンポーネントであるとき、送受信機モジュール８０１は無線周波数ユニットであり得、および処理モジュール８０２は、プロセッサ（または処理ユニット）、例えばベースバンドプロセッサであり得る。通信装置８０がチップシステムであるとき、送受信機モジュール８０１は、チップ（例えば、ベースバンドチップ）の入出力インタフェースであり得、および処理モジュール８０２は、チップシステムのプロセッサ（または処理回路）であり得、および１つまたは複数の中央処理装置を備え得る。本出願の実施形態における送受信機モジュール８０１は、送受信機によって、または送受信機に関連付けられる回路コンポーネントによって実装され得、および処理モジュール８０２は、プロセッサによって、またはプロセッサに関連付けられる回路コンポーネント（または処理回路と呼ばれる）によって実装され得ることを理解されたい。

例えば、送受信機モジュール８０１は、図５に示される実施形態でＮＦＶＯもしくはＶＮＦＭによって実施されるすべての受信および送信動作、例えばＳ５０３を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。処理モジュール８０２は、図５に示される実施形態でＮＦＶＯもしくはＶＮＦＭによって実施される、受信および送信動作を除いたすべての動作、例えばＳ５０１、Ｓ５０２、およびＳ５０５を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。

別の例では、送受信機モジュール８０１は、図６に示される実施形態でＮＦＶＯもしくはＶＮＦＭによって実施されるすべての受信および送信動作、例えばＳ６０３を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。処理モジュール８０２は、図６に示される実施形態でＮＦＶＯによって実施される、受信および送信動作を除いたすべての動作、例えばＳ６０１、Ｓ６０２、およびＳ６０５を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。

別の例では、送受信機モジュール８０１は、図７に示される実施形態でＮＦＶＯもしくはＶＮＦＭによって実施されるすべての受信および送信動作、例えばＳ７０１を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。処理モジュール８０２は、図７に示される実施形態でＮＦＶＯによって実施される、受信および送信動作を除いたすべての動作、例えばＳ７０３を実施するように構成されること、および／または、本明細書で説明される技術の別のプロセスをサポートするように構成されることがあり得る。

同様に、通信装置８０はまた、図５に示される実施形態、図６に示される実施形態、または図７に示される実施形態におけるＣＣＭであるＣＣＭの機能を実装して、図５から図７に示される実施形態におけるＣＣＭによって実施されるすべての動作を実施するように構成され得、および詳細について再度説明はされない。

図９は、通信システムの概略組成図を示す。図９に示されるように、通信システム９０は、管理エンティティ９０１およびＣＣＭ９０２を備え得る。図９は添付図面の例にすぎず、および図９に示される通信システム９０に含められるネットワーク要素、およびネットワーク要素の量は、本出願の実施形態において限定されないことに留意されたい。

ＮＦＶＯ９０１は、図５から図７に示される方法実施形態における管理エンティティ９０１の機能を実装するように構成される。例えば、管理エンティティ９０１は、コンテナクラスタ記述子（ＣＣＤ）ファイルにアクセスし、作成されることになるコンテナクラスタの展開情報をファイルから取得し、ＣＣＤ中のコンテナクラスタの展開情報に基づいてコンテナクラスタのインスタンス化パラメータを決定し、およびコンテナクラスタ作成要求をコンテナクラスタ管理（ＣＣＭ）に送信するように構成され得、要求メッセージは、作成されることになるコンテナクラスタのインスタンス化パラメータを保持する。

ＣＣＭ９０２は、図５から図７に示される方法実施形態におけるＣＣＭの機能を実装するように構成される。例えば、ＣＣＭ９０２は、コンテナクラスタ作成応答を管理エンティティ９０１に返して、コンテナクラスタの作成が成功または失敗であることと作成失敗の原因とを示し、コンテナクラスタインスタンスをローカルに作成し、および指定された量のコンテナクラスタノードの初期作成を完了する。

前述の方法実施形態におけるステップの、関連付けられるすべての内容が、通信システム９０の対応するネットワーク要素の機能説明について引用され得、およびここでは詳細について再度説明はされないことに留意されたい。

実装に関する前述の説明は、簡便な説明の目的で前述の機能モジュールの分割が例証のための例とされることを当業者が理解するのを可能にする。実際の適用では、前述の機能は、異なるモジュールに割り振られて要件に従って実装されることが可能であり、すなわち、装置の内部構造は、上述された機能のすべてまたはいくつかを実装するために、異なる機能モジュールに分割される。

本出願の実施形態は、図１０に示されるようなコンピューティングデバイス１０００を提供し、コンピューティングデバイス１０００は、プログラム命令および／またはデータを記憶するように構成された、少なくとも１つのメモリ１０３０を備える。メモリ１０３０は、プロセッサ１０２０に結合される。プロセッサ１０２０は、記憶されたプログラム命令を稼働することおよび／または記憶されたデータを処理することによって、対応する機能を実装する。コンピューティングデバイス１０００は、図５から図７に示される実施形態におけるＮＦＶＯまたはＶＮＦＭであり得、および実施形態で提供される方法におけるＮＦＶＯまたはＶＮＦＭの機能を実装することができる。コンピューティングデバイス１０００は、チップシステムであり得る。本出願の実施形態では、チップシステムは、チップを含み得、または、チップおよび別のディスクリートデバイスを含み得る。

コンピューティングデバイス１０００は、伝送媒体を使用して別のデバイスと通信するように構成された通信インタフェース１０１０をさらに備え得る。例えば、別のデバイスは、制御デバイスであり得る。プロセッサ１０２０は、通信インタフェース１０１０を通してデータを受信および送信し得る。

通信インタフェース１０１０とプロセッサ１０２０とメモリ１０３０との間の具体的な接続媒体は、本出願の実施形態では限定されない。本出願のこの実施形態では、メモリ１０３０とプロセッサ１０２０と通信インタフェース１０１０とは、図１０におけるバス１０４０を使用して相互に接続される。バスは、図１０では太線を使用して表されている。他のコンポーネント間の接続の方式は、概略的に説明されるにすぎず、限定として使用されるものではない。バスは、アドレスバス、データバス、制御バスなどとして分類され得る。説明を容易にするために、図１０におけるバスは１本の太線のみを使用して表されているが、これは、１本のバスまたは１つのタイプのバスしかないことを示すものではない。

本出願の実施形態では、プロセッサ１０２０は、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、フィールドプログラマブルゲートアレイもしくは別のプログラマブル論理デバイス、ディスクリートゲートもしくはトランジスタ論理デバイス、またはディスクリートハードウェアコンポーネントであり得、および本出願の実施形態で開示される方法、ステップ、および論理ブロック図を実装または実施し得る。汎用プロセッサは、マイクロプロセッサ、任意の従来型プロセッサなどであり得る。本出願の実施形態に関して開示される方法のステップは、ハードウェアプロセッサを用いて直接に実行および完了されてもよく、または、プロセッサにおいてハードウェアとソフトウェアモジュールとの組合せを使用して実行および完了されてもよい。

本出願の実施形態では、メモリ１０３０は、ハードディスクドライブ（ｈａｒｄ ｄｉｓｋ ｄｒｉｖｅ，ＨＤＤ）もしくはソリッドステートドライブ（ｓｏｌｉｄ－ｓｔａｔｅ ｄｒｉｖｅ，ＳＳＤ）などの不揮発性メモリであり得、または、揮発性メモリ（ｖｏｌａｔｉｌｅ ｍｅｍｏｒｙ）、例えばランダムアクセスメモリ（ｒａｎｄｏｍ－ａｃｃｅｓｓ ｍｅｍｏｒｙ，ＲＡＭ）であり得る。メモリは、予期されるプログラムコードを命令またはデータ構造の形で保持または記憶することができてコンピュータによってアクセスされることができる他の任意の媒体であるが、それに限定されない。本出願の実施形態によるメモリはさらに、記憶機能を実装することができ、およびプログラム命令および／またはデータを記憶するように構成された、回路または他の任意の装置であってもよい。

本出願の実施形態は、図１１に示されるようなコンピューティングデバイス１１００をさらに提供し、コンピューティングデバイス１１００は、プログラム命令および／またはデータを記憶するように構成された、少なくとも１つのメモリ１１３０を含む。メモリ１１３０は、プロセッサ１１２０に結合される。プロセッサ１１２０は、記憶されたプログラム命令を稼働することおよび／または記憶されたデータを処理することによって、対応する機能を実装する。コンピューティングデバイス１１００は、図５から図７に示される実施形態におけるＣＣＭであり得、および実施形態で提供される方法におけるＣＣＭの機能を実装することができる。

コンピューティングデバイス１１００はまた、伝送媒体を使用して別のデバイスと通信するように構成された通信インタフェース１１１０を備える。プロセッサ１０２０は、通信インタフェース１１１０を通してデータを受信および送信し得る。

他の機能および構造は、前述のコンピューティングデバイス１０００のそれらと同様であり、およびここでは詳細について再度説明はされない。

本出願の実施形態は、命令を記憶するように構成されたコンピュータ可読記憶媒体をさらに提供する。命令がコンピューティングデバイスのプロセッサによって実行されたとき、コンピューティングデバイスは、本出願の任意の実施形態で提供される方法を実装することが可能にされる。

本出願の実施形態はコンピュータプログラム製品をさらに提供し、コンピュータプログラム製品は、コンピュータプログラムコードを含む。コンピュータプログラムコードがコンピューティングデバイス上で稼働されたとき、コンピューティングデバイスは、本出願の任意の実施形態で提供される方法を実施することが可能にされる。

本明細書で開示される実施形態で説明されるユニットおよびアルゴリズムステップの例との組合せで、本出願が電子ハードウェアを使用して、またはコンピュータソフトウェアと電子ハードウェアとの組合せを使用して実装され得ることを、当業者なら認識し得る。機能がハードウェアのモードで実行されるかまたはソフトウェアのモードで実行されるかは、技術的解決法の特定の適用および設計制約条件に依存する。当業者なら、説明される機能を、特定の適用ごとに種々の方法を使用して実装し得るが、この実装が本出願の実施形態の範囲を超えると考えられるべきではない。

最後に、前述の実施形態は、本出願の技術的解決法について説明するように意図されているにすぎず、本出願を限定するように意図されているのではないことに留意されたい。前述の実施形態を参照しながら本出願について詳細に説明されているが、本出願の実施形態で提供される技術的解決法の範囲を逸脱することなく、前述の実施形態で提供される技術的解決法に修正が加えられてもなおよく、またはそのいくつかの技術的特徴に等価な置換が行われてもよいことを、当業者なら理解するはずである。

Claims (23)

1. コンテナクラスタのための管理方法であって、前記方法は、
   コンテナクラスタ管理ＣＣＭによってコンテナクラスタのインスタンス化要求メッセージを管理エンティティから受信するステップであって、前記要求メッセージは前記コンテナクラスタのインスタンス化パラメータを保持する、ステップと、
   前記ＣＣＭによって前記コンテナクラスタの前記インスタンス化パラメータに基づいて前記コンテナクラスタをインスタンス化するステップと
   を含み、
   前記コンテナクラスタの前記インスタンス化パラメータは、前記管理エンティティによって、コンテナクラスタ記述子ＣＣＤにアクセスすることによって決定される、コンテナクラスタのための管理方法。
2. 前記ＣＣＭによって前記コンテナクラスタの前記インスタンス化パラメータに基づいて前記コンテナクラスタをインスタンス化する前記ステップは、
   前記ＣＣＭによってコンテナクラスタノードのインスタンス化要求メッセージを前記管理エンティティから受信するステップであって、前記要求メッセージは前記コンテナクラスタノードのインスタンス化パラメータを保持し、および前記コンテナクラスタノードの前記インスタンス化パラメータは、前記管理エンティティによって、コンテナクラスタノード記述子ＣＣＮＤにアクセスすることによって決定される、ステップ、または、
   前記ＣＣＭによって前記ＣＣＮＤにアクセスして前記コンテナクラスタノードの前記インスタンス化パラメータを決定するステップと、
   前記ＣＣＭによって、前記コンテナクラスタノードの前記インスタンス化パラメータに基づいて前記コンテナクラスタノードをインスタンス化し、および前記コンテナクラスタの前記インスタンス化パラメータに基づいて、前記コンテナクラスタノード上でコンテナインフラストラクチャサービス管理ＣＩＳＭインスタンスおよび／またはコンテナインフラストラクチャサービスＣＩＳインスタンスをインスタンス化するステップと
   を含む、請求項１に記載の管理方法。
3. 前記ＣＣＭによって前記コンテナクラスタの前記インスタンス化パラメータに基づいて前記コンテナクラスタノード上でＣＩＳＭインスタンスおよびＣＩＳインスタンスをインスタンス化する前記ステップは、
   前記ＣＣＭによって前記コンテナクラスタノード上で前記コンテナインフラストラクチャサービス管理ＣＩＳＭインスタンスおよび／もしくは前記コンテナインフラストラクチャサービスＣＩＳインスタンスを作成するステップ、または、
   前記ＣＣＭによって前記コンテナクラスタノード上で前記コンテナインフラストラクチャサービス管理ＣＩＳＭインスタンスを作成し、および前記ＣＩＳＭインスタンスによって前記コンテナクラスタノード上で前記ＣＩＳインスタンスをさらに作成するステップ
   を含む、請求項２に記載の管理方法。
4. 前記コンテナクラスタの前記インスタンス化パラメータは、前記コンテナクラスタ記述子ＣＣＤの名前または識別情報と、前記コンテナクラスタのサイズと、前記コンテナクラスタの初期化中に作成されるＣＩＳＭインスタンスの量およびＣＩＳインスタンスの量と、前記コンテナクラスタ中の前記ＣＩＳＭインスタンス間、前記ＣＩＳインスタンス間、および前記ＣＩＳＭインスタンスと前記ＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ規則とのうちの１つまたは複数を含む、請求項１に記載の管理方法。
5. 前記コンテナクラスタノードの前記インスタンス化パラメータは、前記コンテナクラスタノード記述子の名前または識別情報と、コンテナクラスタノードのタイプと、前記コンテナクラスタノードが属するアフィニティ／アンチアフィニティグループとのうちの１つまたは複数を含む、請求項２に記載の管理方法。
6. 前記ＣＣＭによって前記コンテナクラスタの更新要求メッセージを前記管理エンティティから受信するステップであって、前記要求メッセージは、更新されることになるコンテナクラスタインスタンスのパラメータを保持する、ステップと、
   前記ＣＣＭによって、前記更新されることになるコンテナクラスタインスタンスの前記パラメータに基づいて前記コンテナクラスタを更新するステップと
   請求項１に記載の管理方法。
7. 前記ＣＣＭによって、前記更新されることになるコンテナクラスタインスタンスの前記パラメータに基づいて前記コンテナクラスタを更新する前記ステップは、
   前記ＣＣＭによって前記コンテナクラスタノードの作成要求メッセージを前記管理エンティティから受信するステップであって、前記作成要求メッセージは前記コンテナクラスタノードのインスタンス化パラメータを保持する、ステップ、または、
   前記ＣＣＭによってＣＣＮＤにアクセスして前記コンテナクラスタノードの前記インスタンス化パラメータを決定するステップと、
   前記ＣＣＭによって前記コンテナクラスタノードの前記インスタンス化パラメータに基づいて前記コンテナクラスタノードを作成するステップと
   を含む、請求項６に記載の管理方法。
8. 前記更新されることになるコンテナクラスタインスタンスの前記パラメータは、
   前記コンテナクラスタインスタンスの識別情報と、スケーリングである更新動作のタイプと、前記スケーリングまたはスケーリングレベルによって到達されるターゲットコンテナクラスタのサイズと、前記スケーリングの前記ターゲットコンテナクラスタのノード間のアフィニティ／アンチアフィニティ規則とのうちの１つまたは複数を含む、請求項６に記載の管理方法。
9. 前記ＣＣＭによって前記コンテナクラスタの削除要求メッセージを前記管理エンティティから受信するステップであって、前記削除要求メッセージは、削除されることになるコンテナクラスタインスタンスの識別情報、および／または削除動作のタイプを保持する、ステップと、
   前記ＣＣＭによって前記コンテナクラスタインスタンスを削除するステップと
   請求項１に記載の管理方法。
10. 前記ＣＣＭによって前記コンテナクラスタインスタンスを削除する前記ステップは、前記コンテナクラスタに含まれるコンテナクラスタノードのそれぞれと、前記ノード上のＣＩＳＭインスタンスおよび／またはＣＩＳインスタンスとを削除し、前記コンテナクラスタノードによって占有されていたレイヤＩリソースを解放し、および前記コンテナクラスタインスタンスを削除するステップを特に含む、請求項９に記載の管理方法。
11. 前記管理エンティティは、ネットワーク機能仮想化オーケストレータＮＦＶＯまたは仮想化ネットワーク機能マネージャＶＮＦＭである、請求項１乃至１０のいずれか一項に記載の管理方法。
12. コンテナクラスタのための管理方法であって、前記方法は、
    管理エンティティによって、コンテナクラスタ記述子ＣＣＤにアクセスして、前記コンテナクラスタのインスタンス化パラメータを決定するステップと、
    前記管理エンティティによって前記コンテナクラスタの前記インスタンス化パラメータをコンテナクラスタ管理ＣＣＭに送信するステップと、
    前記ＣＣＭによって前記コンテナクラスタの前記インスタンス化パラメータに基づいて前記コンテナクラスタをインスタンス化するステップと
    を含む、コンテナクラスタのための管理方法。
13. 前記ＣＣＭによって前記コンテナクラスタの前記インスタンス化パラメータに基づいて前記コンテナクラスタをインスタンス化する前記ステップは、
    前記管理エンティティによって、コンテナクラスタノード記述子ＣＣＮＤにアクセスして、前記コンテナクラスタノードのインスタンス化パラメータを決定するステップと、
    前記管理エンティティによって前記コンテナクラスタノードの前記インスタンス化パラメータを前記ＣＣＭに送信するステップ、または、
    前記ＣＣＭによって前記ＣＣＮＤにアクセスして前記コンテナクラスタノードの前記インスタンス化パラメータを決定するステップと、
    前記ＣＣＭによって、前記コンテナクラスタノードの前記インスタンス化パラメータに基づいて前記コンテナクラスタノードをインスタンス化して、前記コンテナクラスタノードの前記インスタンス化パラメータに基づいて、前記コンテナクラスタノード上でコンテナインフラストラクチャサービス管理ＣＩＳＭインスタンスおよび／またはコンテナインフラストラクチャサービスＣＩＳインスタンスをインスタンス化するステップと
    を含む、請求項１２に記載の管理方法。
14. 前記ＣＣＭによって前記コンテナクラスタの前記インスタンス化パラメータに基づいて前記コンテナクラスタノード上でＣＩＳＭインスタンスおよびＣＩＳインスタンスをインスタンス化する前記ステップは、
    前記ＣＣＭによって前記コンテナクラスタノード上で前記ＣＩＳＭインスタンスおよび／もしくは前記ＣＩＳインスタンスを作成するステップ、または、
    前記ＣＣＭによって前記コンテナクラスタノード上で前記ＣＩＳＭインスタンスを作成して、前記ＣＩＳＭインスタンスによって前記コンテナクラスタノード上で前記ＣＩＳインスタンスをさらに作成するステップ
    を含む、請求項１３に記載の管理方法。
15. 前記コンテナクラスタの前記インスタンス化パラメータは、前記コンテナクラスタ記述子ＣＣＤの名前または識別情報と、前記コンテナクラスタのサイズと、前記コンテナクラスタの初期化中に作成されるＣＩＳＭインスタンスの量およびＣＩＳインスタンスの量と、前記コンテナクラスタ中の前記ＣＩＳＭインスタンス間、前記ＣＩＳインスタンス間、および前記ＣＩＳＭインスタンスと前記ＣＩＳインスタンスとの間のアフィニティ／アンチアフィニティ規則とのうちの１つまたは複数を含む、請求項１２に記載の管理方法。
16. 前記コンテナクラスタノードの前記インスタンス化パラメータは、前記コンテナクラスタノード記述子ＣＣＮＤの名前または識別情報と、コンテナクラスタノードのタイプと、前記コンテナクラスタノードが属するアフィニティ／アンチアフィニティグループとのうちの１つまたは複数を含む、請求項１３に記載の管理方法。
17. コンテナクラスタのための管理システムであって、前記システムは、
    コンテナクラスタ記述子ＣＣＤにアクセスして前記コンテナクラスタのインスタンス化パラメータを決定し、および前記コンテナクラスタの前記インスタンス化パラメータをコンテナクラスタ管理ＣＣＭに送信するように構成された管理エンティティと、
    前記コンテナクラスタの前記インスタンス化パラメータに基づいて前記コンテナクラスタをインスタンス化するように構成された前記ＣＣＭと
    を備える、管理システム。
18. 前記管理エンティティは、コンテナクラスタノード記述子ＣＣＮＤにアクセスして、前記コンテナクラスタノードのインスタンス化パラメータを決定するようにさらに構成され、
    前記管理エンティティは、前記コンテナクラスタノードの前記インスタンス化パラメータを前記ＣＣＭに送り、
    前記ＣＣＭは、前記コンテナクラスタノードの前記インスタンス化パラメータに基づいて前記コンテナクラスタノードをインスタンス化して、前記コンテナクラスタノードの前記インスタンス化パラメータに基づいて、前記コンテナクラスタノード上でコンテナインフラストラクチャサービス管理ＣＩＳＭインスタンスおよび／またはコンテナインフラストラクチャサービスＣＩＳインスタンスをインスタンス化する、
    請求項１７に記載の管理システム。
19. 前記ＣＣＭは、ＣＣＮＤにアクセスしてコンテナクラスタノードのインスタンス化パラメータを決定するようにさらに構成され、
    前記ＣＣＭは、前記コンテナクラスタノードの前記インスタンス化パラメータに基づいて前記コンテナクラスタノードをインスタンス化して、前記コンテナクラスタノードの前記インスタンス化パラメータに基づいて、前記コンテナクラスタノード上でコンテナインフラストラクチャサービス管理ＣＩＳＭインスタンスおよび／またはコンテナインフラストラクチャサービスＣＩＳインスタンスをインスタンス化する、
    請求項１７に記載の管理システム。
20. 前記ＣＣＭによって前記コンテナクラスタの前記インスタンス化パラメータに基づいて前記コンテナクラスタノード上でＣＩＳＭインスタンスおよびＣＩＳインスタンスを前記インスタンス化することは、
    前記ＣＣＭによって前記コンテナクラスタノード上で前記ＣＩＳＭインスタンスおよび／もしくは前記ＣＩＳインスタンスを作成すること、または、
    前記ＣＣＭによって前記コンテナクラスタノード上で前記ＣＩＳＭインスタンスを作成して、前記ＣＩＳＭインスタンスによって前記コンテナクラスタノード上で前記ＣＩＳインスタンスをさらに作成すること
    を含む、請求項１８に記載の管理システム。
21. 請求項１乃至１１のいずれか一項に記載の方法のステップを実施するように構成されたモジュールを備える、コンテナクラスタのための管理装置。
22. プロセッサとメモリとを備える、コンテナクラスタのための管理装置であって、前記プロセッサは前記メモリに結合され、前記メモリはコンピュータプログラムを記憶し、および前記プロセッサは、前記メモリ中の前記コンピュータプログラムを呼び出して、請求項１乃至１１のいずれか一項に記載の前記方法を前記管理装置が実施するのを可能にするように構成された、管理装置。
23. コンピュータ可読記憶媒体であって、前記記憶媒体はコンピュータプログラムを記憶し、および前記コンピュータプログラムが実行されたときに請求項１乃至１１のいずれか一項に記載の方法が実装される、コンピュータ可読記憶媒体。

Images