JP7580397B2 - コンテナ化されたワークロードの分離を変更する方法、コンピュータ・システム、およびコンピュータ・プログラム。 - Google Patents

Description

本発明は、全般的に情報処理の分野に関する。特に本発明は、コンテナ化されたワークロードの分離をトリガ要因の検出に応答して動的に変更することに関する。

新たな情報技術（ＩＴ：ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ）提供モデルは、共有されるリソース、ソフトウェア、および情報がインターネット上でコンピュータおよびその他デバイスにオンデマンドで提供されるクラウド・コンピューティングである。クラウド・コンピューティングは、ＩＴのコストおよび複雑性を大幅に軽減し、その一方で、ワークロードの最適化およびサービスの提供を改善することができる。この手法では、ＨＴＴＰ上で従来のウェブ・ブラウザを通してアクセス可能なインターネット・ベースのリソースから、アプリケーション・インスタンスがホストされて、利用可能にされることが可能である。例示の用途としては、電子メール、カレンダー、連絡先管理、およびインスタント・メッセージなど、メッセージ機能の一般的なセットを提供するものが考えられる。その場合、ユーザはインターネット上でサービスに直接アクセスすることになるであろう。このサービスを使用すると、企業は、その電子メール、カレンダー、もしくは共同作業インフラストラクチャ、またはそのいずれかの組み合わせをクラウドに置くことになり、エンド・ユーザは、適切なクライアントを使用して自身の電子メールにアクセスし、またはカレンダーの操作を実行することになるであろう。

クラウド・コンピュート・リソースは、典型的には、１つ以上のネットワーク・アプリケーションを実行する大規模なサーバ・ファームに格納され、データ・センター設備内の物理的なサーバにマッピングされた仮想サーバ、つまりいわゆる「仮想マシン」（ＶＭ：ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）の内部でアプリケーションが実行される仮想化アーキテクチャが使用されるのが典型的である。仮想マシンは、典型的には、仮想マシンに物理リソースを割り当てる制御プログラムであるハイパーバイザの上で実行される。最新のハイパーバイザは、ハードウェア支援仮想化を使用することが多く、ハードウェア支援仮想化は、主としてホストＣＰＵの、仮想化特有のハードウェア能力を使用することにより、効率的且つ完全な仮想化を提供する。

オペレーティング・システム（ＯＳ：ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ）レベル仮想化が、仮想化のもう１つの手法である。ＯＳレベル仮想化は、オペレーティング・システムのカーネルが、分離されたユーザ空間インスタンスを複数サポートすることにより、コンピュータのリソースがパーティショニングされることを可能にし、ユーザ空間インスタンスは、通常はコンテナと呼ばれる。したがって、この仮想化の手法は、コンテナ・ベースの仮想化と呼ばれることが多い。より一般的には、ＯＳレベル仮想化にはＬｉｎｕｘ（Ｒ）上の「Ｃｏｎｔａｉｎｅｒ」、ＦｒｅｅＢＳＤ上の「Ｊａｉｌ」、およびＳｏｌａｒｉｓ上の「Ｚｏｎｅ」などが含まれるが、これらに限定はされない。コンテナは、例として、Ｌｉｎｕｘ（Ｒ）Ｃｏｎｔａｉｎｅｒ（ＬＸＣ）、Ｄｏｃｋｅｒ、およびＣｏｒｅＯＳ Ｒｏｃｋｅｔ（ｒｋｔ）により実装され得る。コンテナは、エンド・ユーザには個々のマシンと区別がつかない場合もある。クラウド環境では、コンテナ・ベースの仮想化（例えばＤｏｃｋｅｒ）が広く使用される。例として、現在の多くのデータ・センターでは、ワークロードがコンテナ内部で実行される。コンテナは、ワークロードからの需要の変化に対して、より優れた俊敏性およびオーケストレーションを提供することができる。多数の技術がコンテナ・ベースの仮想化において使用される。当該の技術には、例として、後述する名前空間およびｃｇｒｏｕｐが含まれる。登録商標Ｌｉｎｕｘ（Ｒ）は、この商標の世界規模での所有者であるＬｉｎｕｓ Ｔｏｒｖａｌｄｓの独占的被許諾者、Ｌｉｎｕｘ Ｆｏｕｎｄａｔｉｏｎからのサブライセンスに従い使用される。

代表的なコンテナ・クラウド・コンピュータ環境では、ホストはＬｉｎｕｘ（Ｒ）カーネルなどのオペレーティング・システムを実行する。上述した「コンテナ」という専門用語は、単一のオペレーティング・システム・カーネルを使用して、制御ホスト上で分離されたコンピューティング・ワークロード（コンテナ）を実行する、ＯＳレベル仮想化メカニズムを指す。この手法では、単一のオペレーティング・システムによって管理されるリソースを分離されたグループに事実上パーティショニングし、分離されたグループ間のリソース使用に関する競合する需要のバランスを改善する。他のタイプの仮想化とは対照的に、命令レベルのエミュレーションも、ジャストインタイム・コンパイルも要求されない。さらにコンテナは、特別な解釈メカニズムなしに、コアＣＰＵにネイティブな命令を実行することができる。コンテナを作成して入力する方法を提供することにより、オペレーティング・システムは、別個のマシン上で実行されていると各アプリケーションに錯覚させ、その一方で同時に、各アプリケーションは基礎をなすリソースの多くを共有する。

Ｌｉｎｕｘ（Ｒ）カーネルは「名前空間」と呼ばれる機能を有する。Ｌｉｎｕｘ（Ｒ）コンテナの主要な構成要素であるＬｉｎｕｘ（Ｒ）カーネル名前空間は、ネットワーク、プロセス、ユーザ、およびファイル・システムなどの種々の「ユーザ空間」内にアプリケーションを分離する。名前空間は、プロセスの集合に対してシステム・リソースを分離し、仮想化する。仮想化できるリソースのいくつかの例として、プロセスＩＤ、ホスト名、ユーザＩＤ、および同様のものが挙げられる。名前空間は、典型的には、名前空間のタイプ、ならびに当該のタイプの特定のインスタンスを指す。Ｌｉｎｕｘ（Ｒ）オペレーティング・システムは、名前空間の各タイプの単一のインスタンスにより初期化される。初期化後、追加の名前空間を作成または結合できる。

Ｌｉｎｕｘ（Ｒ）カーネルはさらに、リソース（ＣＰＵ、メモリ、ブロックＩ／Ｏ、ネットワークなど）の制限および優先順位付けを可能にするコントロール・グループという機能性を提供し、これは「ｃｇｒｏｕｐ」としても知られている。ｃｇｒｏｕｐ機能性は、ＣＰＵの数および使用率、ディスク・パフォーマンス、メモリ、ならびにその他プロセス制限など、様々なホスト・リソースを制限する。

コンテナ技術は、カーネルによるｃｇｒｏｕｐおよび名前空間のサポートを組み合わせて、アプリケーションのための分離された実行環境を提供する。

コンテナは、ホスト・オペレーティング・システムとカーネルを共有する。したがって、コンテナは、カーネルの様々な脆弱性の悪用のために使用されるおそれがあり得る。ホスト・カーネルの構成に脆弱性がある場合、ホスト・カーネルの脆弱性がセキュリティ・ホールをもたらして、そこからコンテナが他のコンテナまたはホスト・システムに対する非特権アクセスを得るおそれがある。そのような脆弱性の適例は、カーネルのローカル特権昇格「Ｄｉｒｔｙ ＣＯＷ」（ＣＶＥ－２０１６－５１９５）である。悪意のあるユーザがコンテナを「脱出」してカーネルおよび他のコンテナに対するアクセスを得ることを可能にする、既知の悪用が存在する。さらなるホスト・カーネルの脆弱性および付随する悪用が引き続き発見されるであろうことは間違いない。

この問題に対処する解決策は、これまでのところ不十分である。そのような手法の１つは、１つ以上の仮想マシンを使用してコンテナの実行を分離することを伴う。この手法では、コンテナ・ワークロードは、通常のｃｇｒｏｕｐベースのコンテナではなく、１つ以上の仮想マシンの内部で起動される。しかしながら、仮想マシンは典型的に、ｃｇｒｏｕｐベースのコンテナに比べてより遅く、リソース使用量がより多い。結果として、この手法（すなわち、常に１つ以上の仮想マシンの内部でワークロードを実行すること）は、リソースの深刻な浪費につながる。

したがって、当該技術分野において、前述の問題に対処する必要性がある。

第１の側面から考察すると、本発明は、ホスト・カーネルをそれぞれ有する１つ以上のコンピュート・ノードを有するシステムにおいて、コンテナ化されたワークロードの分離を変更する方法を提供し、方法は、デフォルト・コンテナ・ランタイムを使用してワークロードをコンテナ化するステップであって、デフォルト・コンテナ・ランタイムは、コンピュート・ノードのホスト・カーネルの、ｃｇｒｏｕｐおよび名前空間を含むリソース制限能力を使用して、ｃｇｒｏｕｐベースの１つ以上のコンテナをコンピュート・ノード上に生成する、コンテナ化するステップ、デフォルト・コンテナ・ランタイムにより生成されたｃｇｒｏｕｐベースの１つ以上のコンテナにおいて実行されているコンテナ化されたワークロードの少なくとも一部を、スタンバイ・コンテナ・ランタイムにより起動された１つ以上の仮想マシン（ＶＭ）に、トリガ要因の検出に応答してマイグレーションするステップであって、トリガ要因は、認識された脅威、コンプライアンス要件の変更、およびその組み合わせからなるグループから選択される、マイグレーションするステップ、を含む。

さらなる側面から考察すると、本発明は、コンテナ化されたワークロードの分離を変更するコンピュータ・システムを提供し、コンピュータ・システムは、１つ以上のプロセッサ、１つ以上のコンピュータ可読ストレージ・デバイス、および１つ以上のプロセッサのうちの少なくとも１つによる実行のために１つ以上のコンピュータ可読ストレージ・デバイスのうちの少なくとも１つに記憶されたプログラム命令を含み、プログラム命令は、デフォルト・コンテナ・ランタイムを使用してワークロードをコンテナ化することであって、デフォルト・コンテナ・ランタイムは、コンピュート・ノードのホスト・カーネルの、ｃｇｒｏｕｐおよび名前空間を含むリソース制限能力を使用して、ｃｇｒｏｕｐベースの１つ以上のコンテナをコンピュート・ノード上に生成する、コンテナ化すること、デフォルト・コンテナ・ランタイムにより生成されたｃｇｒｏｕｐベースの１つ以上のコンテナにおいて実行されているコンテナ化されたワークロードの少なくとも一部を、スタンバイ・コンテナ・ランタイムにより起動された１つ以上の仮想マシン（ＶＭ）に、トリガ要因の検出に応答してマイグレーションすることであって、トリガ要因は、認識された脅威、コンプライアンス要件の変更、およびその組み合わせからなるグループから選択される、マイグレーションすること、のために実行可能である。

さらなる側面から考察すると、本発明は、ホスト・カーネルをそれぞれ有する１つ以上のコンピュート・ノードを有するシステムにおいて、コンテナ化されたワークロードの分離を変更するコンピュータ・プログラム製品を提供し、コンピュータ・プログラム製品は、本発明の各ステップを実行する方法を実行するために処理回路により実行される命令を記憶し処理回路によって読み取り可能なコンピュータ可読ストレージ媒体を含む。

さらなる側面から考察すると、本発明は、コンピュータ可読媒体上に記憶されデジタル・コンピュータの内部メモリ内にロード可能なコンピュータ・プログラムを提供し、コンピュータ・プログラムは、前記プログラムがコンピュータ上で実行されると本発明の各ステップを実行するソフトウェア・コード部分を含む。

本開示の実施形態は、コンテナ化されたワークロードの分離を、認識された脅威もしくはコンプライアンス要件の変更またはその両方などのトリガ要因の検出に応答して動的に変更する方法、装置、およびコンピュータ・プログラム製品を含む。例として、コンテナ化されたワークロードの分離は、コンテナ化されたワークロードを実行するホスト・オペレーティング・システムの脅威レベルの変化に動的に対応するために増大されてもよい。一部の実施形態において、ワークロードは、デフォルト・コンテナ・ランタイム（例えばｒｕｎＣ）を使用してコンテナ化され、デフォルト・コンテナ・ランタイムは、コンピュート・ノードのホスト・カーネルの、ｃｇｒｏｕｐおよび名前空間を含むリソース制限能力を使用して、ｃｇｒｏｕｐベースの１つ以上のコンテナをコンピュート・ノード上に生成する。一部の実施形態において、コンテナ化されたワークロードの少なくとも一部が、ホスト・カーネルの脆弱性などの認識された脅威に応答してｃｇｒｏｕｐベースの１つ以上のコンテナにおける実行からスタンバイ・コンテナ・ランタイム（例えばｒｕｎＶ）により起動される１つ以上の仮想マシン（ＶＭ）にマイグレーションされる。一部の実施形態において、ＣＲＩＵ、つまりユーザ空間でのチェックポイント／リストア（ｃｈｅｃｋｐｏｉｎｔ／ｒｅｓｔｏｒｅ ｉｎ ｕｓｅｒｓｐａｃｅ）を使用して、ｃｇｒｏｕｐベースの１つ以上のコンテナのｃｇｒｏｕｐおよび名前空間が、サービスの中断なしに１つ以上のＶＭ上の１つ以上のＶＭランタイムにライブ・マイグレーションされる。

以下、本発明について、次の図面に示されている好適な実施形態を参照しながら、単なる例として記載する。

以下、添付の図面に関連して各実施形態について記載するが、図面では、同じ表示は同じ構成要素を表す。

１つ以上の実施形態によるクラウド・コンピューティング・ノードを示す。 １つ以上の実施形態によるクラウド・コンピューティング環境を示す。 １つ以上の実施形態による抽象化モデル層を示す。 １つ以上の実施形態による、複数のコンピュート・ノードを示し、コンピュート・ノードのうちの少なくとも１つは複数の仮想マシンを含む。 １つ以上の実施形態による、複数のコンピュート・ノードを示し、コンピュート・ノードのうちの少なくとも１つは複数のコンテナを含む。 １つ以上の実施形態による、複数のコンピュート・ノードを含むコンテナ・オーケストレーション・システムを示し、コンピュート・ノードの少なくとも１つが、複数のコンテナを起動するコンテナ・ランタイム（例えばｒｕｎＣ）を含む。 １つ以上の実施形態による、複数のコンピュート・ノードを含むコンテナ・オーケストレーション・システムを示し、コンピュート・ノードの少なくとも１つが、ｃｇｒｏｕｐおよび名前空間を使用して作成されたコンテナではなく複数の従来の仮想マシンにおいてワークロードを起動するように変更されたコンテナ・ランタイム（例えばｒｕｎＶ）を含む。 １つ以上の実施形態による、複数のコンピュート・ノードを含むコンテナ・オーケストレーション・システムを示し、コンピュート・ノードの少なくとも１つは、複数の実行中コンテナと、複数の仮想マシンを起動できるハイパーバイザ・ベースのコンテナ・ランタイム（例えばｒｕｎＶ）と、ホストから複数の仮想マシンに実行中コンテナのｃｇｒｏｕｐおよび名前空間をライブ・マイグレーションするためにトリガ要因の検出に応答して利用されるユーザ空間でのチェックポイント／リストア（ＣＲＩＵ）とを含む。 １つ以上の実施形態による、ＣＲＩＵを使用して複数の実行中コンテナのｃｇｒｏｕｐおよび名前空間をホストから複数の仮想マシンにライブ・マイグレーションすることにより、コンテナ化されたワークロードの分離をトリガ要因の検出に応答して動的に変更する、説明のための方法のフロー図である。 １つ以上の実施形態による、図８のコンテナ・オーケストレーション・システムに相当するがサービス・メッシュを介したトラフィック・シェーピングをさらに用いる、コンテナ・オーケストレーション・システムを示す。

１つ以上の実施形態によれば、コンテナ化されたワークロードの分離が、認識された脅威もしくはコンプライアンス要件の変更またはその両方などのトリガ要因の検出に基づいて動的に変更される。例として、コンテナ化されたワークロードの分離は、コンテナ化されたワークロードを実行するホスト・オペレーティング・システムの脅威レベルの変化に動的に対応するために増大されてもよい。１つ以上の実施形態において、ワークロードは、デフォルト・コンテナ・ランタイム（例えばｒｕｎＣ）を使用してコンテナ化され、デフォルト・コンテナ・ランタイムは、コンピュート・ノードのホスト・カーネルの、ｃｇｒｏｕｐおよび名前空間を含むリソース制限能力を使用して、ｃｇｒｏｕｐベースの１つ以上のコンテナをコンピュート・ノード上に生成する。１つ以上の実施形態において、コンテナ化されたワークロードの少なくとも一部が、認識された脅威（例えばホスト・カーネルの脆弱性）または他のトリガ要因（例えばコンプライアンス要件の変更）に応答してｃｇｒｏｕｐベースの１つ以上のコンテナにおける実行からスタンバイ・コンテナ・ランタイム（例えばｒｕｎＶ）により起動された１つ以上の仮想マシン（ＶＭ）にマイグレーションされる。一部の実施形態において、ＣＲＩＵ、つまりユーザ空間でのチェックポイント／リストアを使用して、ｃｇｒｏｕｐベースの１つ以上のコンテナのｃｇｒｏｕｐおよび名前空間が、サービスの中断なしに１つ以上のＶＭ上の１つ以上のＶＭランタイムにライブ・マイグレーションされる。

当然のことながら、本開示はクラウド・コンピューティングについての詳細な記載を含むものの、本願明細書に記載する教示の実装はクラウド・コンピューティング環境に限定されない。むしろ、本発明の実施形態は、現在周知の、または後に開発される、ほかの任意のタイプのコンピューティング環境に関連して実装することができる。

クラウド・コンピューティングは、最小限の管理作業またはサービス・プロバイダとの相互作用で迅速にプロビジョニングおよびリリースできる構成可能なコンピューティング・リソース（例えばネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールに対するオンデマンドの便利なネットワーク・アクセスを実現する、サービス提供のモデルである。このクラウド・モデルは、少なくとも５つの特徴と、少なくとも３つのサービス・モデルと、少なくとも４つの展開モデルとを含み得る。

特徴は以下のとおりである。
オンデマンド・セルフサービス：クラウド消費者は、サーバ時間およびネットワーク・ストレージなどのコンピューティング能力を、サービスのプロバイダとの人的な相互作用をする必要なく、必要に応じて自動的に、一方的にプロビジョニングできる。
広範なネットワーク・アクセス：各能力はネットワーク上で利用可能であり、異種のシン・クライアントまたはシック・クライアントのプラットフォーム（例えばモバイル電話、ラップトップ、およびＰＤＡ（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ：携帯情報端末））による使用を促進する標準のメカニズムを通してアクセスされる。
リソース・プーリング：プロバイダのコンピューティング・リソースは、マルチ・テナント・モデルを使用して複数の消費者にサービスを提供するようプールされ、種々の物理リソースおよび仮想リソースが需要に応じて動的に割り当ておよび再割り当てされる。一般に、消費者は、提供されるリソースの正確な場所についての制御権または知識を有しないという点で、非場所依存の感覚があるが、より高い抽象化レベルでは場所（例えば国、州、またはデータ・センター）を指定できることもある。
迅速な伸縮性：各能力は、迅速且つ伸縮自在に、場合によっては自動的にプロビジョニングされて、素早くスケール・アウトすること、および迅速に解放され素早くスケール・インすることができる。多くの場合、消費者には、プロビジョニングに利用可能な各能力は無制限であるように見え、任意の量をいつでも購入できる。
測定されるサービス：クラウド・システムは、サービスのタイプ（例えばストレージ、処理、帯域幅、およびアクティブなユーザ・アカウント）に適した或る抽象化レベルでの計測能力を活用することによって、リソースの使用を自動的に制御および最適化する。リソース使用量は、モニタリング、制御、およびレポート可能であり、利用されるサービスのプロバイダおよび消費者の双方に透明性が提供される。

サービス・モデルは以下のとおりである。
ソフトウェア・アズ・ア・サービス（ＳａａＳ：Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：消費者に提供される能力は、クラウド・インフラストラクチャ上で実行されるプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザなどのシン・クライアント・インターフェース（例えばウェブ・ベースの電子メール）を通して様々なクライアント・デバイスからアクセス可能である。消費者は、ネットワーク、サーバ、オペレーティング・システム、ストレージを含む基礎をなすクラウド・インフラストラクチャも、個々のアプリケーションの能力さえも、管理または制御しないが、限られたユーザ別のアプリケーション構成設定は例外とされることもある。
プラットフォーム・アズ・ア・サービス（ＰａａＳ：Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）：消費者に提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、消費者が作成または入手したアプリケーションを、クラウド・インフラストラクチャ上に展開することである。消費者は、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む基礎をなすクラウド・インフラストラクチャの管理または制御は行わないが、展開されたアプリケーション、さらに場合によってはアプリケーション・ホスティング環境構成を制御する。
インフラストラクチャ・アズ・ア・サービス（ＩａａＳ：Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：消費者に提供される能力は、処理、ストレージ、ネットワーク、およびその他基本的なコンピューティング・リソースのプロビジョニングであり、消費者はそこで、オペレーティング・システムおよびアプリケーションを含み得る任意のソフトウェアを展開し実行することができる。消費者は、基礎をなすクラウド・インフラストラクチャの管理または制御は行わないが、オペレーティング・システム、ストレージ、展開されたアプリケーションを制御し、場合によっては、選ばれたネットワーキング・コンポーネント（例えばホスト・ファイアウォール）を限定的に制御する。
コンテナ・アズ・ア・サービス（ＣａａＳ：Ｃｏｎｔａｉｎｅｒｓ ａｓ ａ Ｓｅｒｖｉｃｅ）は、ユーザがコンテナ・ベースの仮想化を通してコンテナ、アプリケーション、およびクラスタを展開および管理できるようにするクラウド・コンピューティング・サービス・モデルである。ＣａａＳは、概して、クラウド・コンピューティング・サービス・モデルのスペクトルにおいて、どちらも上述されているインフラストラクチャ・アズ・ア・サービス（ＩａａＳ）とプラットフォーム・アズ・ア・サービス（ＰａａＳ）との間に位置する。ただし、典型的には、ＣａａＳはＩａａＳのサブセットとみなされるが、ＣａａＳは（ＩａａＳ環境をサポートするために従来使用される仮想マシンまたはベアメタル・ハードウェア・ホスト・システムとは対照的に）その基本的なリソースとしてコンテナを含む。

展開モデルは以下のとおりである。
プライベート・クラウド：クラウド・インフラストラクチャは、或る組織のみのために運用される。クラウド・インフラストラクチャは、組織またはサード・パーティによって管理可能であり、構内または構外に存在し得る。
コミュニティ・クラウド：クラウド・インフラストラクチャは、いくつかの組織によって共有され、共有される関心事（例えばミッション、セキュリティ要件、ポリシー、およびコンプライアンス意識）を有する特定のコミュニティをサポートする。クラウド・インフラストラクチャは、組織またはサード・パーティによって管理可能であり、構内または構外に存在し得る。
パブリック・クラウド：クラウド・インフラストラクチャは、公衆または大規模業界団体に利用可能にされ、クラウド・サービスを販売する組織によって所有される。
ハイブリッド・クラウド：クラウド・インフラストラクチャは、２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）の複合であり、各クラウドは一意のエンティティのままであるが、データおよびアプリケーションのポータビリティを実現する標準化された、または専有の技術（例えばクラウド間のロード・バランシングのためのクラウド・バースト）によってバインドされる。

クラウド・コンピューティング環境は、サービス指向であり、ステートレス性、疎結合性、モジュール性、および意味的相互運用性に焦点を合わせる。クラウド・コンピューティングの中心には、相互接続されたノードのネットワークを含むインフラストラクチャがある。

以下、図１を参照する。クラウド・コンピューティング・ノードの例の略図が示されている。クラウド・コンピューティング・ノード１０は、適切なクラウド・コンピューティング・ノードの一例でしかなく、なんら意味することも目的としていない。

以下、図１を参照する。クラウド・コンピューティング・ノードの例の略図が示されている。クラウド・コンピューティング・ノード１０は、適切なクラウド・コンピューティング・ノードの一例でしかなく、本願明細書に記載される本発明の実施形態の用途または機能性の範囲について、いかなる制限を意味することも目的としていない。いずれにせよ、クラウド・コンピューティング・ノード１０は、上記に記載された機能性のいずれかの実装もしくは実行またはその両方ができる。

クラウド・コンピューティング・ノード１０内には、コンピュータ・システム／サーバ１２があり、これは、多数の他の汎用または専用のコンピューティング・システム環境もしくはコンピューティング・システム構成とともに動作可能である。コンピュータ・システム／サーバ１２とともに使用するのに適していると考えられる周知のコンピューティング・システム、環境、もしくは構成、またはそのいずれかの組み合わせの例としては、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルド・デバイスまたはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラマブル家庭用電化製品、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記のシステムまたはデバイスのいずれかを含む分散型クラウド・コンピューティング環境、ならびに同様のものが挙げられるが、これらに限定はされない。

コンピュータ・システム／サーバ１２については、コンピュータ・システムによって実行されるプログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的文脈において記載することができる。一般に、プログラム・モジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含み得る。コンピュータ・システム／サーバ１２は、通信ネットワークを通してリンクされているリモート処理デバイスによってタスクが実行される、分散型クラウド・コンピューティング環境において実施されてもよい。分散型クラウド・コンピューティング環境では、プログラム・モジュールは、メモリ・ストレージ・デバイスを含むローカルおよびリモート両方のコンピュータ・システム・ストレージ媒体に位置し得る。

図１に示されているように、クラウド・コンピューティング・ノード１０内のコンピュータ・システム／サーバ１２は、汎用コンピューティング・デバイスの形態で示されている。コンピュータ・システム／サーバ１２のコンポーネントには、１つ以上のプロセッサまたは処理ユニット１６、システム・メモリ２８、およびシステム・メモリ２８を含む様々なシステム・コンポーネントをプロセッサ１６に結合するバス１８が含まれ得るが、これらに限定はされない。

バス１８は、メモリ・バスまたはメモリ・コントローラ、周辺機器用バス、アクセラレーテッド・グラフィックス・ポート、および様々なバス・アーキテクチャのいずれかを使用するプロセッサ・バスまたはローカル・バスを含む、いくつかのタイプのバス構造の任意のもの１つ以上を表現する。限定ではなく例として、そのようなアーキテクチャには、業界標準アーキテクチャ（ＩＳＡ：Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ：Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（ＥＩＳＡ：Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ：Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカル・バス、およびペリフェラル・コンポーネント・インターコネクト（ＰＣＩ：Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスが含まれる。

コンピュータ・システム／サーバ１２は、典型的には、様々なコンピュータ・システム可読媒体を含む。そのような媒体は、コンピュータ・システム／サーバ１２によってアクセス可能な任意の利用可能な媒体としてよく、揮発性および不揮発性の媒体、ならびにリムーバブルおよび非リムーバブルの媒体の両方を含む。

システム・メモリ２８は、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）３０もしくはキャッシュ・メモリ３２またはその両方など、揮発性メモリの形態のコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ１２は、このほか、リムーバブル／非リムーバブルの揮発性／不揮発性コンピュータ・システム・ストレージ媒体をさらに含んでもよい。単なる例として、非リムーバブルの不揮発性磁気媒体（図示はしておらず、典型的には「ハード・ドライブ」と呼ばれる）、およびその他非リムーバブルの不揮発性媒体（例えば「ソリッドステート・ドライブ」）に対する読み取りおよび書き込みのために、ストレージ・システム３４を提供できる。図示してはいないが、リムーバブル不揮発性磁気ディスク（例えば「フレキシブル・ディスク」）に対する読み取りおよび書き込みのための磁気ディスク・ドライブ、およびＣＤ－ＲＯＭ（ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ：コンパクト・ディスク読み取り専用メモリ）、ＤＶＤ－ＲＯＭ、またはその他の光媒体などのリムーバブル不揮発性光ディスクに対する読み取りもしくは書き込みまたはその両方のための光ディスク・ドライブを提供できる。そのような事例では、それぞれを、１つ以上のデータ媒体インターフェースによってバス１８に接続できる。さらに後述されるように、メモリ２８は、本発明の１つ以上の特徴を実行するように構成されたコンピュータ可読命令を含むプログラム・モジュール４２のセット（例えば少なくとも１つ）を記憶するコンピュータ・プログラム製品を含んでもよい。

プログラム・モジュール４２のセット（少なくとも１つ）を有するプログラム／ユーティリティ４０は、限定ではなく例として、オペレーティング・システム、１つ以上のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データと同様にメモリ２８に記憶されてもよい。オペレーティング・システム、１つ以上のアプリケーション・プログラム、その他プログラム・モジュール、およびプログラム・データ、またはその何らかの組み合わせのそれぞれが、ネットワーキング環境の実装を含んでもよい。一部の実施形態において、プログラム・モジュール４２は、本発明の１つ以上の実施形態の１つ以上の機能もしくは方法論またはその両方を、広く実行するようになっている。

コンピュータ・システム／サーバ１２はさらに、例えばキーボード、ポインティング・デバイス、ディスプレイ２４などの１つ以上の外部デバイス１４、もしくはユーザがコンピュータ・システム／サーバ１２と相互作用できるようにする１つ以上のデバイス、もしくはコンピュータ・システム／サーバ１２が１つ以上のほかのコンピューティング・デバイスと通信できるようにする任意のデバイス（例えばネットワーク・カード、モデムなど）、またはそのいずれかの組み合わせと通信してもよい。そのような通信は、入出力（Ｉ／Ｏ：Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）インターフェース２２を介して発生できる。さらにコンピュータ・システム／サーバ１２は、ローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、一般的なワイド・エリア・ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、もしくはパブリック・ネットワーク（例えばインターネット）、またはそのいずれかの組み合わせなどの１つ以上のネットワークと、ネットワーク・アダプタ２０を介して通信できる。図示されているように、ネットワーク・アダプタ２０は、コンピュータ・システム／サーバ１２の他のコンポーネントとバス１８を介して通信する。図示されてはいないが、当然のことながら、他のハードウェアもしくはソフトウェアまたはその両方のコンポーネントを、コンピュータ・システム／サーバ１２とともに使用できるであろう。例としては、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ・ストレージ・システムなどが挙げられるが、これに限定はされない。

以下、図２を参照する。説明のためのクラウド・コンピューティング環境５０が示されている。図のように、クラウド・コンピューティング環境５０は、１つ以上のクラウド・コンピューティング・ノード１０を含み、例として携帯情報端末（ＰＤＡ）または携帯電話５４Ａ、デスクトップ・コンピュータ５４Ｂ、ラップトップ・コンピュータ５４Ｃ、もしくは自動車用コンピュータ・システム５４Ｎ、またはそのいずれかの組み合わせなど、クラウド消費者により使用されるローカル・コンピューティング・デバイスが、クラウド・コンピューティング・ノード１０と通信できる。ノード１０は、互いに通信し得る。ノード１０は、上述のプライベート・クラウド、コミュニティ・クラウド、パブリック・クラウド、もしくはハイブリッド・クラウド、またはその組み合わせなどの１つ以上のネットワークにおいて、物理的または仮想的にグループ化されてもよい（図示せず）。これにより、クラウド・コンピューティング環境５０は、インフラストラクチャ、プラットフォーム、もしくはソフトウェア、またはそのいずれかの組み合わせをサービスとして提供することができ、それらのためにクラウド消費者がローカル・コンピューティング・デバイス上にリソースを維持する必要はない。当然のことながら、図２に示されているコンピューティング・デバイス５４Ａ～Ｎのタイプは、説明のみを目的としており、コンピューティング・ノード１０およびクラウド・コンピューティング環境５０は、任意のタイプのネットワークもしくはネットワーク・アドレス指定可能な接続（例えばウェブ・ブラウザを使用）またはその両方によって、任意のタイプのコンピュータ化デバイスと通信できる。

以下、図３を参照する。クラウド・コンピューティング環境５０（図２）によって提供される機能抽象化層のセットが示されている。図３に示されているコンポーネント、層、および機能は、説明のみを目的としており、本発明の実施形態はこれらに限定されないことをあらかじめ理解されたい。図示されているように、以下の層および対応する機能が提供される。

ハードウェアおよびソフトウェア層６０は、ハードウェア・コンポーネントおよびソフトウェア・コンポーネントを含む。ハードウェア・コンポーネントの例としては、メインフレーム６１、ＲＩＳＣ（縮小命令セット・コンピュータ（Ｒｅｄｕｃｅｄ Ｉｎｓｔｒｕｃｔｉｏｎ Ｓｅｔ Ｃｏｍｐｕｔｅｒ））アーキテクチャ・ベースのサーバ６２、サーバ６３、ブレード・サーバ６４、ストレージ・デバイス６５、ならびにネットワークおよびネットワーキング・コンポーネント６６が挙げられる。一部の実施形態において、ソフトウェア・コンポーネントは、ネットワーク・アプリケーション・サーバ・ソフトウェア６７およびデータベース・ソフトウェア６８を含む。

仮想化層７０は、抽象化層を提供し、抽象化層から、仮想サーバ７１、仮想ストレージ７２、仮想プライベート・ネットワークを含む仮想ネットワーク７３、仮想アプリケーションおよびオペレーティング・システム７４、ならびに仮想クライアント７５を例とする仮想エンティティが提供されてもよい。

一例において、管理層８０は下記の機能を提供してもよい。リソース・プロビジョニング８１は、クラウド・コンピューティング環境内でタスクを実行するために利用されるコンピューティング・リソースおよびその他のリソースの動的な調達を提供する。計測および価格決定８２は、クラウド・コンピューティング環境内でリソースが利用されるときのコストの追跡と、こうしたリソースの消費に対する請求またはインボイスの作成とを提供する。一例において、これらのリソースはアプリケーション・ソフトウェア・ライセンスを含んでもよい。セキュリティは、クラウド消費者およびタスクのアイデンティティ確認、ならびにデータおよびその他のリソースの保護を提供する。ユーザ・ポータル８３は、消費者およびシステム管理者に、クラウド・コンピューティング環境に対するアクセスを提供する。サービス・レベル管理８４は、必要なサービス・レベルが満たされるようにクラウド・コンピューティング・リソースの割り当ておよび管理を提供する。サービス・レベル合意（ＳＬＡ：Ｓｅｒｖｉｃｅ Ｌｅｖｅｌ Ａｇｒｅｅｍｅｎｔ）計画および達成８５は、ＳＬＡに従い将来の要求が予想されるクラウド・コンピューティング・リソースの事前準備および調達を提供する。

ワークロード層９０は、クラウド・コンピューティング環境が利用される目的となり得る機能性の例を提供する。この層から提供され得るワークロードおよび機能の例としては、マッピングおよびナビゲーション９１、ソフトウェア開発およびライフサイクル管理９２、仮想教室教育配信９３、データ分析処理９４、トランザクション処理９５、ならびにモバイル・デスクトップ９６が挙げられる。

図４および図５はそれぞれ、本発明の一部の実施形態に従って使用され得る複数のコンピュート・ノード４００および５００（「ホスト・デバイス」とも呼ばれる）を示す。図４のコンピュート・ノード４００は、対象の実マシンの完全な代わりとなり、且つ完全なオペレーティング・システム４０３の実行に必要なレベルの機能性を提供する、例示的な複数のシステムＶＭ、すなわち完全仮想化ＶＭを含む。図５のコンピュート・ノード５００は、例示的なＯＳレベルの仮想化システムを複数含み、このシステムは、通常はコンテナと呼ばれてエンド・ユーザには実マシンのような外観および操作性を持ち得る分離された複数のユーザ空間インスタンスをカーネルがサポートすることにより、コンピュータのリソースのパーティショニングを可能にする。本発明の一部の実施形態は、様々なタイプの仮想化とともに使用されてもよい。例として、本発明の一部の実施形態は、仮想マシンの管理（ＯｐｅｎＳｔａｃｋなど）およびコンテナの管理（Ｋｕｂｅｒｎｅｔｅｓなど）とともに使用されてもよい。

例として、コンテナ管理システム（例えばＫｕｂｅｒｎｅｔｅｓ、Ｄｏｃｋｅｒ Ｓｗａｒｍ）が、クラスタ規模のシステムにおいてコンテナのライフサイクル（作成、読み取り、更新、および削除（ＣＲＵＤ：Ｃｒｅａｔｅ，Ｒｅａｄ，Ｕｐｄａｔｅ，ａｎｄ Ｄｅｌｅｔｅ））を管理するために利用されてもよい。典型的な例として、コンテナ作成リクエストが受信されると、スケジューラが、リクエストされたコンテナが実行されるホストを選択する。次に、選択されたホスト内のエージェントがコンテナを起動する。当然のことながら、「ホスト」および「ノード」という用語は、本願明細書において交換可能なように使用され、プロセッサと、メモリと、他のホスト／ノードと相互作用するための通信メカニズムとを少なくとも伴うハードウェア装置またはハードウェア・システムを指す。

図４および図５は、完全仮想化およびＯＳレベル仮想化を使用するコンピュート・ノード４００および５００をそれぞれ示している。本発明の一部の実施形態は、これらのタイプのコンピュート・ノードのいずれかとともに使用されてもよく、さらに、単一または複数のコンピュート・ノードにわたるこれらのコンピュート・ノードの組み合わせを備えたハイブリッド環境において使用されてもよい。

図４に示されているように、コンピュート・ノード４００はそれぞれ、プロセッサ（またはＣＰＵ）４０７、メモリ４０８、ネットワーク・インターフェース・カード（ＮＩＣ：ｎｅｔｗｏｒｋ ｉｎｔｅｒｆａｃｅ ｃａｒｄ）４０９、およびディスク・ドライブ４１０を含み得るハードウェア４０６を含む。ディスク・ドライブ４１０は、ソリッド・ステート・ドライブもしくはハード・ディスク・ドライブ、またはこの２つの何らかの組み合わせを含んでもよい。コンピュート・ノード４００は、ハードウェア上でホスト・オペレーティング・システム４０５を実行する。コンピュート・ノード４００はさらに、ハードウェア４０６を共有および管理するためのハイパーバイザ４０４を含み、相互に分離された異なる複数の環境４０１が同じ物理マシン４００上で実行できる。ハイパーバイザ４０４は、ハードウェア支援仮想化を使用してもよく、ハードウェア支援仮想化は、主としてホストＣＰＵ４０７の、仮想化特有のハードウェア能力を使用することにより、効率的且つ完全な仮想化を提供する。各コンピュート・ノード４００は、１つ以上の仮想マシン４０１を含み、そのそれぞれが、ゲスト・オペレーティング・システム４０３と、ゲスト・オペレーティング・システム４０３上で実行される１つ以上のアプリケーション・プログラム（またはアプリケーション）４０２とを含む。

同様に、図５に示されているように、コンピュート・ノード５００はそれぞれ、プロセッサ（またはＣＰＵ）５０７、メモリ５０８、ネットワーク・インターフェース・カード（ＮＩＣ）５０９、およびディスク・ドライブ５１０を含み得るハードウェア５０６を含む。ディスク・ドライブ５１０は、ソリッド・ステート・ドライブもしくはハード・ディスク・ドライブ、またはこの２つの何らかの組み合わせを含んでもよい。コンピュート・ノード５００は、ハードウェア上でホスト・オペレーティング・システム５０５を実行する。各コンピュート・ノード５００は、１つ以上のコンテナ５０１を含み、そのそれぞれが、１つ以上のアプリケーション５０２を含む。

一部の実施形態によれば、コンピュート・ノード５００は、１つ以上のポッド５０３を含んでもよく、そのそれぞれが１つ以上のコンテナ５０１を含み、そのそれぞれが１つ以上のアプリケーション５０２を含む。例として、Ｋｕｂｅｒｎｅｔｅｓでは、コンテナはポッド内で実行される。

「Ｋｕｂｅｒｎｅｔｅｓ」は、コンテナ化されたワークロードおよびサービスを管理する、ポータブル且つ拡張可能なオープンソースのプラットフォームである。Ｋｕｂｅｒｎｅｔｅｓは、宣言的な構成および自動化の両方を促進する。Ｋｕｂｅｒｎｅｔｅｓプロジェクトは、２０１４年にＧｏｏｇｌｅによってオープンソース化された。Ｋｕｂｅｒｎｅｔｅｓは、ユーザ・ワークロードのためにコンピューティング、ネットワーキング、およびストレージ・インフラストラクチャをオーケストレーションする。Ｋｕｂｅｒｎｅｔｅｓは、オーケストレーション・フレームワークの一例である。他のオーケストレーション・フレームワークには、Ｄｏｃｋｅｒ Ｓｗａｒｍ、ＬＸＤ、Ｒａｎｃｈｅｒ、およびＡｐａｃｈｅ Ａｕｒｏｒａ／Ｍｅｓｏｓが含まれるが、これらに限定はされない。

複数のコンピュート・ノード内のコンテナ化されたワークロードは、コンテナ・オーケストレーション・マネージャ（ＣＯＭ：ｃｏｎｔａｉｎｅｒ ｏｒｃｈｅｓｔｒａｔｉｏｎ ｍａｎａｇｅｒ）によって管理されてもよい。コンテナ・オーケストレーション・マネージャ（ＣＯＭ）の一例は、Ｋｕｂｅｒｎｅｔｅｓマスタである。

いくつかのバイナリ・コンポーネント（例えばマスタ・コンポーネント、ノード・コンポーネント、およびアドオン）が、機能するＫｕｂｅｒｎｅｔｅｓクラスタを提供するために利用される。

マスタ・コンポーネントは、Ｋｕｂｅｒｎｅｔｅｓクラスタの制御プレーン（「Ｋｕｂｅｒｎｅｔｅｓ制御プレーン」とも呼ばれる）を提供する。マスタ・コンポーネントには、ｋｕｂｅ－ａｐｉｓｅｒｖｅｒ、ｅｔｃｄ、ｋｕｂｅ－ｓｃｈｅｄｕｌｅｒ、ｋｕｂｅ－ｃｏｎｔｒｏｌｌｅｒ－ｍａｎａｇｅｒ、およびｃｌｏｕｄ－ｃｏｎｔｒｏｌｌｅｒ－ｍａｎａｇｅｒが含まれ得るが、これらに限定はされない。マスタ・コンポーネントは、Ｋｕｂｅｒｎｅｔｅｓクラスタについてのグローバルな決定を下す。例としてマスタ・コンポーネントは、スケジューリングを処理する。さらにマスタ・コンポーネントは、クラスタ・イベントの検出およびそれに対する応答に利用される。例としてマスタ・コンポーネントは、レプリケーション・コントローラの「レプリカ」フィールドが満たされていない場合に、新しいポッドを開始することを担当する。マスタ・コンポーネントは、クラスタ内の任意のマシン上で実行できる。とはいえ、セットアップ・スクリプトは、典型的にはすべてのマスタ・コンポーネントを同じマシン上で開始し、そのマシン上ではユーザ・コンテナを実行しない。

ノード・コンポーネントは、Ｋｕｂｅｒｎｅｔｅｓクラスタ内のすべてのコンピュート・ノード上で実行される。ノード・コンポーネントは、実行中のポッドを維持すること、およびＫｕｂｅｒｎｅｔｅｓランタイム環境を提供することを担当する。ノード・コンポーネントには、ｋｕｂｅｌｅｔ、ｋｕｂｅ－ｐｒｏｘｙ、およびコンテナ・ランタイムが含まれ得るが、これらに限定はされない。

ｋｕｂｅｌｅｔは、ポッド内でコンテナが実行されていることを確認するエージェントである。ｋｕｂｅｌｅｔは、様々なメカニズムを通して提供されるＰｏｄＳｐｅｃｓのセットにおいて指定されたコンテナが、実行されていて、且つ健全であることを保証する。

ｋｕｂｅ－ｐｒｏｘｙは、ネットワーク・プロキシである。ｋｕｂｅ－ｐｒｏｘｙは、コンピュート・ノード上でネットワーク・ルールを維持して接続転送を実行することにより、Ｋｕｂｅｒｎｅｔｅｓサービスの抽象化を可能にする。

コンテナ・ランタイムは、コンテナの実行を担当するソフトウェアである。より具体的には、コンテナ・ランタイムは、コンテナのライフサイクルを処理するノード・コンポーネントである。コンテナ・ランタイムは、コンテナ・ワークロードの作成、開始、停止、および除去などの基本的な概念を実装する。Ｋｕｂｅｒｎｅｔｅｓは、Ｄｏｃｋｅｒ、ｃｏｎｔａｉｎｅｒｄ、ＣＲＩ－Ｏ、およびｒｋｔｌｅｔを含むがこれらに限定されない、いくつかのランタイムをサポートする。

より一般的には、Ｋｕｂｅｒｎｅｔｅｓは、Ｋｕｂｅｒｎｅｔｅｓが提供するコンテナ・ランタイム・インターフェース（ＣＲＩ：Ｃｏｎｔａｉｎｅｒ Ｒｕｎｔｉｍｅ Ｉｎｔｅｒｆａｃｅ）の任意の実装をサポートする。ＣＲＩは、様々なコンテナ・ランタイムが容易にプラグインされることを可能にする。Ｋｕｂｅｒｎｅｔｅｓ １．５においてＣＲＩが導入される前は、デフォルトのＤｏｃｋｅｒイメージ・リポジトリおよびそのデフォルトのＯＣＩ互換ランタイムであるｒｕｎＣのみが使用されていた。オープン・コンテナ・イニシアチブ（ＯＣＩ：Ｏｐｅｎ Ｃｏｎｔａｉｎｅｒ Ｉｎｉｔｉａｔｉｖｅ）が、ＯＣＩ互換コンテナ・ランタイムのＡＰＩを詳述するランタイム仕様を作成した。ｒｕｎＣ、ｒｕｎＶ、およびＩｎｔｅｌのＣｌｅａｒ Ｃｏｎｔａｉｎｅｒｓ（「ｃｃ－ｒｕｎｔｉｍｅ」としても周知である）が、ＯＣＩ互換コンテナ・ランタイムの例である。ｒｕｎＣには、コンテナのチェックポイントおよびリストアを行う、後述のＣＲＩＵ、つまりユーザ空間でのチェックポイント／リストアのサポートが組み込まれている。ｒｕｎＶは、ＯＣＩのためのハイパーバイザ・ベースのＤｏｃｋｅｒランタイムである。ｒｕｎＶは、「Ｈｙｐｅｒ ｒｕｎＶ」とも呼ばれる。

ＣＲＩランタイムは、より高い抽象化レベルにあり、ＯＣＩ互換ランタイムと混同されるべきではない。ＣＲＩランタイムは、「ＣＲＩシム（ｓｈｉｍ）」とも呼ばれる。ＣＲＩシムには、ｃｒｉ－ｃｏｎｔａｉｎｅｒｄ、ＣＲＩ－Ｏ、ｄｏｃｋｅｒｓｈｉｍ、およびｆｒａｋｔｉが含まれる。一部のＣＲＩシム（例えばｃｒｉ－ｃｏｎｔａｉｎｅｒｄ、ＣＲＩ－Ｏ、およびｄｏｃｋｅｒｓｈｉｍ）は、ＯＣＩ互換ランタイムを呼び出す一方で、他のＣＲＩシム（例えばｆｒａｋｔｉ）は、モノリシックなソリューションである。

少なくとも一部のＣＲＩシムは、単一のコンピュート・ノード上で実行される複数のランタイムをサポートする。例として、ＣＲＩ－Ｏは、信頼されたサンドボックスおよび信頼されていないサンドボックスの概念をサポートする。Ｋｕｂｅｒｎｅｔｅｓでは、１つ以上のＶＭベースのポッドおよび１つ以上のｃｇｒｏｕｐ／名前空間ベースのポッドの複合が、ポッド・アノテーションおよびデフォルトのＣＲＩ－Ｏ構成に基づいて、単一のコンピュート・ノード上で実行され得る。ＶＭベースのポッドの内部で実行されるコンテナは、ｒｕｎＣにより行われるのと同様に、名前空間およびｃｇｒｏｕｐにより分離され、管理され得る。

アドオンは、クラスタ機能の実装を担当するポッドおよびサービスである。アドオンには、クラスタＤＮＳ（すなわち、ＫｕｂｅｒｎｅｔｅｓサービスのＤＮＳレコードを提供するＤＮＳサーバ）、ダッシュボード（すなわち、クラスタ内で実行されているアプリケーションならびにクラスタ自体をユーザが管理し、トラブルシューティングを行うことを可能にする、Ｋｕｂｅｒｎｅｔｅｓクラスタのウェブ・ベースのＵＩ）、コンテナ・リソース・モニタリング（すなわち、コンテナについての一般的な時系列のメトリクスを中央データベースに記録すること、ならびにそのデータベースに記録されたデータを閲覧するためのＵＩを提供することを担当する）、およびクラスタ・レベル・ロギング（すなわち、検索／閲覧インターフェースを備えた中央ログ・ストアにコンテナ・ログを保存することを担当する）が含まれるが、これらに限定はされない。

１つ以上の実施形態によれば、ＣＲＩＵの機能を使用して、コンテナ化されたワークロードの１つのランタイム（例えばｒｕｎＣ）から別のランタイム（例えばｒｕｎＶ）へのライブ・マイグレーションが、サービスの中断なしに達成され得る。概して、ＣＲＩＵは、ソースにおいて実行中コンテナの状態を凍結し、デスティネーションにおいて同じ実行状態でコンテナをリストアする能力を提供する。ＣＲＩＵプロセスは、典型的には次の動作を含む：１）ソースとデスティネーションとの間でコンテナのファイル・システムを同期する（凍結前／ダンプ）、２）ソースにてコンテナのプロセスを凍結する、３）ソースにてコンテナを（例えばチェックポイント・ディレクトリ内のダンプ・ファイルに）ダンプする、４）ソースとデスティネーションとの間でコンテナのファイル・システムを同期する（凍結後／ダンプ）、５）デスティネーションにてダンプ・ファイルをコピーする、６）デスティネーションにてコンテナを再開する、７）デスティネーションにて、コンテナの凍結されたプロセスを再開する、８）ソースにてコンテナを停止する、さらに９）ソースにてコンテナを破壊する。

図６は、１つ以上の実施形態による、複数のコンピュート・ノード６０２を含むコンテナ・オーケストレーション・システム６００を示し、コンピュート・ノードの少なくとも１つが、複数のコンテナ６０６を起動するコンテナ・ランタイム（例えばｒｕｎＣ）６０４を含む。コンテナ・オーケストレーション・システム６００は、クラスタとも呼ばれることがある（例えば、コンテナ・オーケストレーション・システム６００はＫｕｂｅｒｎｅｔｅｓクラスタに相当し得る）。コンピュート・ノード６０２は、コンテナ・オーケストレーション・マネージャ（ＣＯＭ）６１０によって管理されてもよい。例として、Ｋｕｂｅｒｎｅｔｅｓでは、各コンピュート・ノード６０２は１つ以上のポッド６０８を実行するのに必要なサービス（すなわちノード・コンポーネント）を含み、Ｋｕｂｅｒｎｅｔｅｓマスタ・コンポーネントによって管理される。各コンピュート・ノード６０２上のサービスは、コンテナ・ランタイム６０４（例えばｒｕｎＣ）、当該のコンピュート・ノード上で実行されるコンテナ・ライフサイクル動作に関するコンテナ・オーケストレーション・マネージャ（ＣＯＭ）６１０からの命令をリッスンするエージェント６１２（例えばｋｕｂｅｌｅｔ）、およびネットワーク・プロキシ（例えばｋｕｂｅ－ｐｒｏｘｙ）を含んでもよい。コンテナ・オーケストレーション・マネージャ（ＣＯＭ）６１０は、Ｋｕｂｅｒｎｅｔｅｓマスタ・コンポーネントのうちの１つ以上の、少なくとも一部を含んでもよい。

コンテナ・ランタイム６０４（例えばｒｕｎＣ）は、コンピュート・ノード・レベルで１つ以上のコンテナ６０６を管理する。コンテナ・オーケストレーション・マネージャ（ＣＯＭ）６１０は、分散型システム（Ｋｕｂｅｒｎｅｔｅｓクラスタ）レベルで各コンテナ・ランタイム６０４（例えばｒｕｎＣ）を管理する（すなわち１つ以上のコンテナ・ランタイム（例えばｒｕｎＣ）を管理する）。

当然のことながら、コンテナ６０６は、コンテナ・ランタイム６０４（例えばｒｕｎＣ）を使用して、コンピュート・ノードのホスト・カーネルの、ｃｇｒｏｕｐおよび名前空間などのリソース制限能力を用いてコンピュート・ノード６０２上に生成される。ｒｕｎＣは、オープン・コンテナ・イニシアチブ（ＯＣＩ）仕様に従ってコンテナを生成し、実行するコマンド・ライン・ツールである。ｒｕｎＣは、ライトウェイト・ユニバーサル・コンテナ・ランタイムであり、Ｌｉｎｕｘ（Ｒ）ｃｇｒｏｕｐおよび名前空間を使用して分離を提供する。ｒｕｎＣは、ＯＣＩ互換コンテナ・ランタイムの一例である。当業者であれば当然のことながら、ｒｕｎＣの代わりに、またはｒｕｎＣに加えて、他のコンテナ・ランタイムが使用されてもよい。例としてｒｕｎＣは、ｒｕｎＣを呼び出すＣＲＩ－ＯなどのＣＲＩランタイム（ＣＲＩシム）とともに使用されてもよい。

図６に示されている実施形態において、コンテナ・オーケストレーション・システム６００は、イングレス・トラフィック・コントローラ６１４を含む。図６では、イングレス・トラフィック・コントローラ６１４がコンテナ・オーケストレーション・マネージャ（ＣＯＭ）６１０と別個に示されているが、コンテナ・オーケストレーション・マネージャ（ＣＯＭ）６１０およびイングレス・トラフィック・コントローラ６１４は同じマシン上で実行されてもよい。イングレス・トラフィック・コントローラ６１４は、管理者６１６によって設定されてもよい。

Ｋｕｂｅｒｎｅｔｅｓにおいて、イングレスは、Ｋｕｂｅｒｎｅｔｅｓクラスタ内のサービスに対するＫｕｂｅｒｎｅｔｅｓクラスタ外部からのアクセスを管理するＡＰＩオブジェクトである。アクセスは、どのインバウンド接続がクラスタ内のどのＫｕｂｅｒｎｅｔｅｓサービスに到達するかを定義するルール（「ルーティング・ルール」と呼ばれる）の集合を作成することによって設定できる。トラフィック・ルーティングは、イングレス・リソース上に定義されたルーティング・ルールによって制御される。ルーティング・ルールは、典型的には、一箇所（「イングレス・リソース」と呼ばれる）に統合される。イングレスは、例として、ロード・バランシング、ＳＳＬターミネーション、および名前ベースのルーティングなどを提供することができる。イングレスは、クラスタ外部からクラスタ内のサービスへのＨＴＴＰおよびＨＴＴＰＳルートを公開する。

図６に示されているイングレス・トラフィック・コントローラ６１４などのイングレス・コントローラは、イングレスを実行することを担当する。例として、Ｇｏｏｇｌｅコンピュート・エンジン（ＧＣＥ：Ｇｏｏｇｌｅ Ｃｏｍｐｕｔｅ Ｅｎｇｉｎｅ）／Ｇｏｏｇｌｅ Ｋｕｂｅｒｎｅｔｅｓエンジン（ＧＫＥ：Ｇｏｏｇｌｅ Ｋｕｂｅｒｎｅｔｅｓ Ｅｎｇｉｎｅ）は、マスタ上にイングレス・コントローラを展開（デプロイ）する。ＧＣＥ／ＧＫＥ以外の環境では、いくつかのイングレス・コントローラのいずれか（例えばＮｇｉｎｘイングレス・コントローラ）が展開に利用可能である。

図７は、１つ以上の実施形態による、複数のコンピュート・ノード７０２を含むコンテナ・オーケストレーション・システム７００を示し、コンピュート・ノードの少なくとも１つが、ｃｇｒｏｕｐおよび名前空間を使用して作成されたコンテナではなく複数の従来の仮想マシン７０８においてワークロード７０６を起動するように変更されたコンテナ・ランタイム７０４（例えばｒｕｎＶ）を含む。このタイプのセットアップは、例として、ワークロード７０６が非常に重要な性質のもの（例えば金融取引およびハイパーレジャー・ブロックチェーンのバリデーション）であり、「Ｄｉｒｔｙ ＣＯＷ」などのカーネルの脆弱性から保護する必要がある場合に有用である。コンテナ・オーケストレーション・システム７００は、クラスタとも呼ばれることがある（例えば、コンテナ・オーケストレーション・システム７００はＫｕｂｅｒｎｅｔｅｓクラスタに相当し得る）。コンピュート・ノード７０２は、コンテナ・オーケストレーション・マネージャ（ＣＯＭ）７１０によって管理されてもよい。例として、Ｋｕｂｅｒｎｅｔｅｓでは、各コンピュート・ノード７０２は１つ以上のポッドを実行するのに必要なサービス（すなわちノード・コンポーネント）を含み、Ｋｕｂｅｒｎｅｔｅｓマスタ・コンポーネントによって管理される。各コンピュート・ノード７０２上のサービスは、コンテナ・ランタイム７０４（例えばｒｕｎＶまたはその他ＯＣＩランタイム仕様のハイパーバイザ・ベースのランタイム実装）、当該のコンピュート・ノード上で実行されるコンテナ・ライフサイクル動作に関するコンテナ・オーケストレーション・マネージャ（ＣＯＭ）７１０からの命令をリッスンするエージェント７１２（例えばｋｕｂｅｌｅｔ）、およびネットワーク・プロキシ（例えばｋｕｂｅ－ｐｒｏｘｙ）を含んでもよい。コンテナ・オーケストレーション・マネージャ（ＣＯＭ）７１０は、Ｋｕｂｅｒｎｅｔｅｓマスタ・コンポーネントのうちの１つ以上の、少なくとも一部を含んでもよい。

コンテナ・ランタイム７０４（例えばｒｕｎＶ）は、コンピュート・ノード・レベルでワークロード７０６を管理する。コンテナ・オーケストレーション・マネージャ（ＣＯＭ）７１０は、分散型システム（Ｋｕｂｅｒｎｅｔｅｓクラスタ）レベルで各コンテナ・ランタイム７０４（例えばｒｕｎＶ）を管理する（すなわち１つ以上のコンテナ・ランタイム（例えばｒｕｎＶ）を管理する）。

Ｈｙｐｅｒ ｒｕｎＶ（「ｒｕｎＶ」とも呼ばれる）は、ＯＣＩランタイムのためのハイパーバイザ・ベースのランタイム（すなわちＯＣＩ互換ランタイム）であり、ｒｕｎＣと同様に機能する。ただし、ｒｕｎＣとは異なり、ｒｕｎＶはｃｇｒｏｕｐおよび名前空間を使用せず、ハイパーバイザを使用して（Ｄｏｃｋｅｒ）イメージを実行する。当業者には当然のことながら、ＯＣＩランタイム仕様の他のハイパーバイザ・ベースのランタイム実装が、ｒｕｎＶの代わりに、またはｒｕｎＶに加えて使用されてもよい。ｒｕｎＶなどのハイパーバイザ・ベースのランタイムは、本願明細書において「ＶＭベースのコンテナ・ランタイム」とも呼ばれる。このほか、ＯＣＩランタイム仕様のハイパーバイザ・ベースのランタイム実装の例として、Ｉｎｔｅｌ（Ｒ）Ｃｌｅａｒ Ｃｏｎｔａｉｎｅｒｓ（「ｃｃ－ｒｕｎｔｉｍｅ」としても周知である）およびＶＭＷａｒｅのＶＳｐｈｅｒｅ Ｉｎｔｅｇｒａｔｅｄ Ｃｏｎｔａｉｎｅｒｓ（ＶＩＣ）が挙げられるが、これらに限定はされない。さらに、ｒｕｎＶおよびその他ＯＣＩランタイム仕様のハイパーバイザ・ベースのランタイム実装は、ＣＲＩ－Ｏなど、ハイパーバイザ・ベースのランタイムを呼び出すＣＲＩランタイム（ＣＲＩシム）とともに使用されてもよい。Ｉｎｔｅｌは、Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏｎまたはその子会社の米国およびその他の国々における商標または登録商標である。ＶＭｗａｒｅは、ＶＭｗａｒｅ，Ｉｎｃ．またはその子会社の米国もしくはその他の法域またはその両方における登録商標または商標である。

図８は、１つ以上の実施形態による、複数のコンピュート・ノード８０２を含むコンテナ・オーケストレーション・システム８００を示し、コンピュート・ノードの少なくとも１つは、複数の実行中コンテナ８０６と、複数の仮想マシン８１０を起動できるハイパーバイザ・ベースのコンテナ・ランタイム８０５（例えばｒｕｎＶ）と、ホスト８０２から複数の仮想マシン８１０に実行中コンテナ８０６のｃｇｒｏｕｐおよび名前空間をライブ・マイグレーションするためにトリガ要因の検出に応答して利用されるユーザ空間でのチェックポイント／リストア（ＣＲＩＵ）８２０とを含む。ホスト８０２から複数の仮想マシン８１０へのｃｇｒｏｕｐおよび名前空間のライブ・マイグレーションは、複数の仮想マシン８１０上で実行されるｃｇｒｏｕｐベースのコンテナ８０８を確立する。

１つ以上の実施形態によれば、コンテナ・オーケストレーション・マネージャ（ＣＯＭ）８１１は、完全マイグレーション・モードまたは部分マイグレーション・モードのいずれかを始動させることによってトリガ要因の検出に応答するように（例えば管理者８０１によって）設定されてもよい。例として、検出されるトリガ要因次第で、ＣＯＭ８１１の管理者８０１は、完全なワークロードを通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムからＶＭベースのコンテナ・ランタイムに移行させる完全マイグレーション・モードを選択してもよく、またはロード・バランシングを活用することによって通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムならびにＶＭベースのコンテナ・ランタイムにわたりコンテナを水平にスケーリングする部分マイグレーション・モードを選択してもよい。

例として、ｃｇｒｏｕｐベースのコンテナにおいて実行されているワークロードは、ホスト・カーネルの脆弱性などのトリガ要因の検出に応答してマイグレーションすることができる。一部の実施形態において、このマイグレーションは、サービスの中断を招くことなく発生することができる。なお、ｃｇｒｏｕｐベースのコンテナで実行されているワークロードは、ホスト・カーネルの脆弱性の代わりに、またはそれに加えて他の１つ以上のトリガ要因が検出されることに応答して、マイグレーションされてもよいことは、当業者に理解されるであろう。この手法は、例えば、実行中のサービスのコンプライアンス要件がサービス・アップタイムの中断なしに変更される必要があるシナリオにおいても使用できる。

コンテナ・ランタイム８０４（例えばｒｕｎＣ）は、コンピュート・ノード・レベルでコンテナ８０６を管理する。コンテナ・ランタイム８０４（例えばｒｕｎＣ）は、本願明細書において「デフォルト・コンテナ・ランタイム」とも呼ばれる。

ハイパーバイザ・ベースのコンテナ・ランタイム８０５（例えばｒｕｎＶ）は、コンピュート・ノード・レベルでコンテナ８０８を管理する。ハイパーバイザ・ベースのコンテナ・ランタイム８０５（例えばｒｕｎＶ）は、本願明細書において「スタンバイ・コンテナ・ランタイム」とも呼ばれる。

コンテナ・オーケストレーション・マネージャ（ＣＯＭ）８１１は、分散型システム（Ｋｕｂｅｒｎｅｔｅｓクラスタ）レベルで各コンテナ・ランタイム８０４（例えばｒｕｎＣ）および各ハイパーバイザ・ベースのコンテナ・ランタイム８０５（例えばｒｕｎＶ）を管理する（すなわち１つ以上のコンテナ・ランタイム８０４（例えばｒｕｎＣ）および１つ以上のハイパーバイザ・ベースのコンテナ・ランタイム（例えばｒｕｎＶ）を管理する）。

チェックポイント・コマンドは、コンテナが現在実行されているホスト上でのコンテナの現在の状態をチェックポイント（すなわちＣＲＩＵの「Ｃ」）する。そのデフォルト設定で、ｒｕｎＣは、チェックポイント・データをチェックポイントと呼ばれるディレクトリに書き込む。チェックポイントは、コンテナ内のすべてのプロセスを、チェックポイント中に当該プロセスがあった状態と同じ状態にリストアするために必要な情報をすべて含む。このチェックポイント・データは、オープン・ファイル、メモリ・コンテンツ、およびファイル・システムを含む。このチェックポイント・データはさらに、ｃｇｒｏｕｐおよび名前空間を含む。１つ以上の実施形態によれば、ｒｕｎＣによってすべてのチェックポイント・データがチェックポイント・ディレクトリに書き込まれると、ｒｕｎＶによって起動されたＶＭ上でコンテナをリストアできる。リストア・コマンドは、チェックポイント・ディレクトリからチェックポイント・データを読み取り、コンテナ内のすべてのプロセスを、チェックポイント中に当該プロセスがあった状態と同じ状態にリストアする（すなわちＣＲＩＵの「Ｒ」）。

１つ以上の実施形態によれば、コンテナのランタイム状態をチェックポイントすることは、実行中コンテナを一時的に休止し、コンテナのインメモリ・データおよびファイル・システムの状態の両方を捕捉して、ローカル・ディスクに記憶することを含んでもよい。例示的な実装において、ＣＲＩＵは、コンテナのインメモリ・データを休止してイメージ・ファイルのセットの形式でダンプし、コンテナのファイル・システムをスナップショットして、コンテナのオンディスク状態を捕捉するために使用されてもよい。

図８を参照する。コンテナ８０６がインスタンス化され、ホスト８０２上で実行される。コンテナ８０６は、コンテナ・メモリ・データおよびコンテナ・ファイル・システムを含む。チェックポイントすると、コンテナ８０６からのデータはローカル・ディスク（例えば図５のディスク５１０）に記憶されてもよい。このデータは、コンテナ・メモリ・データおよびコンテナ・ファイル・システムを含む。例示的な一実施形態において、メモリ・データは、／ｖａｒ／ｌｉｂ／ｃｏｎｔａｉｎｅｒ／ＣＯＮＴＡＩＮＥＲ－ＩＤ／ｓｔａｔｅｓＳＴＡＴＥ－ＩＤ／ＭＥＭ－ＩＤに記憶でき、ファイル・システムは、／ｖａｒ／ｌｉｂ／ｃｏｎｔａｉｎｅｒ／ＣＯＮＴＡＩＮＥＲ－ＩＤ／ｓｔａｔｅｓＳＴＡＴＥ－ＩＤ／ＦＳ－ＩＤに記憶できる。

コンテナ・オーケストレーション・システム８００は、クラスタとも呼ばれることがある（例えば、コンテナ・オーケストレーション・システム８００はＫｕｂｅｒｎｅｔｅｓクラスタに相当し得る）。コンピュート・ノード８０２は、コンテナ・オーケストレーション・マネージャ（ＣＯＭ）８１１によって管理されてもよい。例として、Ｋｕｂｅｒｎｅｔｅｓでは、各コンピュート・ノード８０２は１つ以上のポッド８０７、８０９を実行するのに必要なサービス（すなわちノード・コンポーネント）を含み、Ｋｕｂｅｒｎｅｔｅｓマスタ・コンポーネントによって管理される。各コンピュート・ノード８０２上のサービスは、コンテナ・ランタイム８０４（例えばｒｕｎＣ）、ハイパーバイザ・ベースのコンテナ・ランタイム８０５（例えばｒｕｎＶ）、当該のコンピュート・ノード上で実行されるコンテナ・ライフサイクル動作に関するコンテナ・オーケストレーション・マネージャ（ＣＯＭ）８１１からの命令をリッスンするエージェント８１２（例えばｋｕｂｅｌｅｔ）、およびネットワーク・プロキシ（例えばｋｕｂｅ－ｐｒｏｘｙ）を含んでもよい。コンテナ・オーケストレーション・マネージャ（ＣＯＭ）８１１は、Ｋｕｂｅｒｎｅｔｅｓマスタ・コンポーネントのうちの１つ以上の、少なくとも一部を含んでもよい。

図８に示されている実施形態では、複数の実行中コンテナ８０６は、コンテナ・ランタイム８０４（例えばｒｕｎＣ）によって起動されるｃｇｒｏｕｐベースのコンテナである。当然のことながら、コンテナ８０６は、コンテナ・ランタイム８０４（例えばｒｕｎＣ）を使用して、コンピュート・ノードのホスト・カーネルの、ｃｇｒｏｕｐおよび名前空間などのリソース制限能力を用いてコンピュート・ノード８０２上に生成される。ｒｕｎＣは、オープン・コンテナ・イニシアチブ（ＯＣＩ）仕様に従ってコンテナを生成し、実行するコマンド・ライン・ツールである。ｒｕｎＣは、ライトウェイト・ユニバーサル・コンテナ・ランタイムであり、Ｌｉｎｕｘ（Ｒ）ｃｇｒｏｕｐおよび名前空間を使用して分離を提供する。

ｒｕｎＣは、ＯＣＩ互換コンテナ・ランタイムの一例である。当業者であれば当然のことながら、ｒｕｎＣの代わりに、またはｒｕｎＣに加えて、他のコンテナ・ランタイムが使用されてもよい。例としてｒｕｎＣは、ｒｕｎＣを呼び出すＣＲＩ－ＯなどのＣＲＩランタイム（ＣＲＩシム）とともに使用されてもよい。

ｒｕｎＶは、ＯＣＩランタイムのための、Ｈｙｐｅｒ（Ｔｈｅ Ｈｙｐｅｒ．ｓｈ Ｔｅａｍ）からのハイパーバイザ・ベースのＤｏｃｋｅｒランタイム（すなわちＯＣＩ互換ランタイム）であり、ｒｕｎＣと同様に機能する。ただし、ｒｕｎＣとは異なり、ｒｕｎＶはｃｇｒｏｕｐおよび名前空間を使用せず、ハイパーバイザを使用して（Ｄｏｃｋｅｒ）イメージを実行する。ｒｕｎＶは、ハイパーバイザ・ベースのＤｏｃｋｅｒランタイムであるが、ハイパーバイザに依存しない。例としてｒｕｎＶは、ＫＶＭ、Ｘｅｎ、およびＥＳＸｉなどの既存のハイパーバイザを使用することができる。当業者には当然のことながら、ＯＣＩランタイム仕様の他のハイパーバイザ・ベースのランタイム実装が、ｒｕｎＶの代わりに、またはｒｕｎＶに加えて使用されてもよい。このほか、ＯＣＩランタイム仕様のハイパーバイザ・ベースのランタイム実装の例として、ＩｎｔｅｌのＣｌｅａｒ Ｃｏｎｔａｉｎｅｒｓ（「ｃｃ－ｒｕｎｔｉｍｅ」としても周知である）およびＶＭＷａｒｅのＶＳｐｈｅｒｅ Ｉｎｔｅｇｒａｔｅｄ Ｃｏｎｔａｉｎｅｒｓ（ＶＩＣ）が挙げられるが、これらに限定はされない。さらに、ｒｕｎＶおよびその他ＯＣＩランタイム仕様のハイパーバイザ・ベースのランタイム実装は、ＣＲＩ－Ｏなど、ハイパーバイザ・ベースのランタイムを呼び出すＣＲＩランタイム（ＣＲＩシム）とともに使用されてもよい。

図８に示されている実施形態において、コンテナ・オーケストレーション・システム８００は、イングレス・トラフィック・コントローラ８１４を含む。イングレス・トラフィック・コントローラ８１４は、管理者８１６によって設定されてもよい。例として、図８に示されている実施形態において管理者８１６は、サービス・アップタイムに影響を与えることなく（通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムにもともと向かっていた）イングレス・トラフィックをＶＭベースのコンテナ・ランタイムに再ルーティングするように、イングレス・トラフィック・コントローラ８１４を設定してもよい。

図８では、イングレス・トラフィック・コントローラ８１４がコンテナ・オーケストレーション・マネージャ（ＣＯＭ）８１１と別個に示されているが、コンテナ・オーケストレーション・マネージャ（ＣＯＭ）８１１およびイングレス・トラフィック・コントローラ８１４は同じマシン上で実行されてもよい。一部の実施形態において、コンテナ・オーケストレーション・マネージャ（ＣＯＭ）８１１およびイングレス・トラフィック・コントローラ８１４は、同じ管理者によって設定されてもよい。

Ｋｕｂｅｒｎｅｔｅｓにおいて、イングレスは、Ｋｕｂｅｒｎｅｔｅｓクラスタ内のサービスに対するＫｕｂｅｒｎｅｔｅｓクラスタ外部からのアクセスを管理するＡＰＩオブジェクトである。アクセスは、どのインバウンド接続がクラスタ内のどのＫｕｂｅｒｎｅｔｅｓサービスに到達するかを定義するルール（「ルーティング・ルール」と呼ばれる）の集合を作成することによって設定できる。トラフィック・ルーティングは、イングレス・リソース上に定義されたルーティング・ルールによって制御される。ルーティング・ルールは、典型的には、一箇所（「イングレス・リソース」と呼ばれる）に統合される。イングレスは、例として、ロード・バランシング、ＳＳＬターミネーション、および名前ベースのルーティングなどを提供することができる。イングレスは、クラスタ外部からクラスタ内のサービスへのＨＴＴＰおよびＨＴＴＰＳルートを公開する。

図８に示されているイングレス・トラフィック・コントローラ８１４などのイングレス・コントローラは、イングレスを実行することを担当する。例として、Ｇｏｏｇｌｅコンピュート・エンジン（ＧＣＥ）／Ｇｏｏｇｌｅ Ｋｕｂｅｒｎｅｔｅｓエンジン（ＧＫＥ）は、マスタ上にイングレス・コントローラを展開する。ＧＣＥ／ＧＫＥ以外の環境では、いくつかのイングレス・コントローラのいずれか（例えばＮｇｉｎｘイングレス・コントローラ）が展開に利用可能である。

図９は、１つ以上の実施形態による、ＣＲＩＵを使用して複数の実行中コンテナのｃｇｒｏｕｐおよび名前空間をホストから複数の仮想マシンにライブ・マイグレーションすることにより、コンテナ化されたワークロードの分離をトリガ要因の検出に応答して動的に変更する、説明のための方法９００のフロー図である。方法９００は、各ブロックの好適な順序を規定する。しかし、当然のことながら、様々なブロックが互いに対して相対的に任意の時点で発生してよい。

方法９００は、デフォルト・コンテナ・ランタイム（例えばｒｕｎＣ）を使用してワークロードをコンテナ化することにより開始する（ブロック９０２）。例として、デフォルト・コンテナ・ランタイムは、コンピュート・ノードのホスト・カーネルの、ｃｇｒｏｕｐおよび名前空間を含むリソース制限能力を使用して、ｃｇｒｏｕｐベースの１つ以上のコンテナをコンピュート・ノード上に生成してもよい。デフォルト・コンテナ・ランタイムは、ｒｕｎＣまたはその他任意の適切なデフォルト・コンテナ・ランタイムとされてもよい。適切なデフォルト・コンテナ・ランタイムには、Ｌｉｎｕｘ（Ｒ）ｃｇｒｏｕｐおよび名前空間を使用して分離を提供するＯＣＩ互換コンテナ・ランタイムが含まれるが、これに限定はされない。一部の実施形態において、コンピュート・ノード上のｒｕｎＣ（またはその他任意の適切なデフォルト・コンテナ・ランタイム）は、当該コンピュート・ノード上で実行されるコンテナ・ライフサイクル動作に関するコンテナ・オーケストレーション・マネージャ（ＣＯＭ）からの命令をリッスンする当該コンピュート・ノード上のエージェントからのリクエストに応答して、当該コンピュート・ノード上にｃｇｒｏｕｐベースの１つ以上のコンテナを生成してもよい（すなわち、エージェントは、当該コンピュート・ノード上にコンテナが作成されることの命令をコンテナ・オーケストレーション・マネージャ（ＣＯＭ）から受信するのに応答して、デフォルト・コンテナ・ランタイムにリクエストを送信した）。他の実施形態において、デフォルト・コンテナ・ランタイムは、エージェントとデフォルト・コンテナ・ランタイムとの間に置かれているＣＲＩ－ＯなどのＣＲＩランタイム（ＣＲＩシム）を通して間接的にエージェントからリクエストを受信してもよい。

方法９００は、トリガ要因の検出に進む（ブロック９０４）。トリガ要因の説明のための例としては、脅威の認識（例えばホスト・カーネルの脆弱性）、コンプライアンス要件の変更（例えば実行中のサービスのコンプライアンス要件が変更される必要がある）、およびその組み合わせが挙げられるが、これらに限定はされない。例として、コンテナ・オーケストレーション・マネージャ（ＣＯＭ）の管理者が、モニタリング・サービスを通してホスト・カーネルの脆弱性を知ることが考えられる。認識されたカーネルの脆弱性に応じて、ＣＯＭの管理者は、コンテナ化されたワークロードの少なくとも一部の分離を変更するのが賢明であると決定するかもしれない。例として、ＣＯＭの管理者は、１つ以上の仮想マシンを起動するスタンバイ・コンテナ・ランタイムを始動させてもよく、次にこの仮想マシンに、コンテナ化されたワークロードの少なくとも一部が移行される。一部の実施形態において、ＣＯＭの管理者は、脆弱性に応じて、完全なワークロードをＶＭベースのコンテナ・ランタイムに移行することを選択してもよく、またはロード・バランシングを活用することによって通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムおよびＶＭベースのコンテナ・ランタイムにわたりコンテナを水平にスケーリングすることを選択してもよい（後述される任意選択のブロック９０６）。

任意選択で、方法９００は、完全マイグレーション・モードまたは部分マイグレーション・モードの選択に進む（ブロック９０６）。ブロック９０６は、任意選択性を表すために破線を使用して図９に示されている。例として、トリガ要因に関連する１つ以上の特性（例えばブロック９０４において検出されたホスト・カーネルの脆弱性の深刻度）に基づいて、ＣＯＭの管理者は、完全マイグレーション・モード（すなわちコンテナ化されたワークロードのすべてがＶＭベースのコンテナ・ランタイムへと移行される）または部分マイグレーション・モード（すなわち、コンテナ化されたワークロードが、ロード・バランシングを活用することによって通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムおよびＶＭベースのコンテナ・ランタイムにわたり水平にスケーリングされる）のいずれかを選択してもよい。

次に方法９００は、デフォルト・コンテナ・ランタイムによって生成されたｃｇｒｏｕｐベースの１つ以上のコンテナにおいて実行されているコンテナ化されたワークロードの少なくとも一部を、スタンバイ・コンテナ・ランタイム（例えばｒｕｎＶ）によって起動された１つ以上の仮想マシンに、ブロック９０４におけるトリガ要因の検出（および任意選択でブロック９０６におけるマイグレーション・モードの選択）に応答してマイグレーションすることにより継続する（ブロック９０８）。一部の実施形態において、ＣＯＭは、トリガ要因の検出に応答して、「分離変更コンテナ・マイグレーション」がコンピュート・ノード上で実行されることの命令を自動的に送信してもよい。

他の実施形態において、ＣＯＭの管理者は、コンテナ化されたワークロードの少なくとも一部の分離をトリガ要因の検出に応答して変更することが賢明であるか否かを決定してもよい。ＣＯＭの管理者は、コンテナ化されたワークロードの少なくとも一部の分離を変更することが賢明であると決定した場合、「分離変更コンテナ・マイグレーション」がコンピュート・ノード上で実行されることの命令をＣＯＭが送信することを生じさせてもよい。

「分離変更コンテナ・マイグレーション」命令は、自動的に送信されたかＣＯＭの管理者の指示で送信されたかを問わず、コンピュート・ノード上の１つ以上の仮想マシンを起動するｒｕｎＶなどのスタンバイ・コンテナ・ランタイムを始動させ、次に、コンピュート・ノード上で実行されているｃｇｒｏｕｐベースの１つ以上のコンテナのうちの少なくとも１つの各コンテナのｃｇｒｏｕｐおよび名前空間の、１つ以上の仮想マシン上の１つ以上のＶＭランタイムに対するライブ・マイグレーションを始動させる。ｃｇｒｏｕｐおよび名前空間は、例として、ユーザ空間でのチェックポイント／リストア（ＣＲＩＵ）を使用してライブ・マイグレーションされてもよい。１つ以上の実施形態によれば、「分離変更コンテナ・マイグレーション」命令は、任意選択のブロック９０６において完全マイグレーション・モードが選択されたか、または部分マイグレーション・モードが選択されたかを表すフラグを含んでもよい。

スタンバイ・コンテナ・ランタイムは、ｒｕｎＶまたはその他任意の適切なスタンバイ・コンテナ・ランタイムとされてもよい。適切なスタンバイ・コンテナ・ランタイムには、ＯＣＩランタイム仕様の他のハイパーバイザ・ベースのランタイム実装が含まれるが、これに限定はされない。一部の実施形態において、コンピュート・ノード上のｒｕｎＶ（またはその他任意の適切なスタンバイ・コンテナ・ランタイム）は、当該コンピュート・ノード上で実行されるコンテナ・ライフサイクル動作に関するコンテナ・オーケストレーション・マネージャ（ＣＯＭ）からの命令をリッスンする当該コンピュート・ノード上のエージェントからのリクエストに応答して、当該コンピュート・ノード上に１つ以上の仮想マシンを生成してもよい（すなわち、エージェントは、当該コンピュート・ノード上で「分離変更コンテナ・マイグレーション」が実行されるようコンテナ・オーケストレーション・マネージャ（ＣＯＭ）から命令を受信するのに応答して、スタンバイ・コンテナ・ランタイムにリクエストを送信した）。他の実施形態において、デフォルト・コンテナ・ランタイムは、エージェントとデフォルト・コンテナ・ランタイムとの間に置かれているＣＲＩ－ＯなどのＣＲＩランタイム（ＣＲＩシム）を通して間接的にエージェントからリクエストを受信してもよい。

上述のように、１つ以上の実施形態によれば、「分離変更コンテナ・マイグレーション」命令は、任意選択のブロック９０６において完全マイグレーション・モードが選択されたか、または部分マイグレーション・モードが選択されたかを表すフラグを含んでもよい。言い換えれば、通常のｃｇｒｏｕｐランタイムからＶＭベースのコンテナ・ランタイムへのワークロードのマイグレーションは、完全（すなわちワークロードの１００％がマイグレーションされる）であってもよく、または部分的（すなわちワークロードの＜１００％がマイグレーションされる）であってもよい。１つ以上の実施形態によれば、このような、認識された脅威（またはコンプライアンス要件の変更）に基づくコンテナ・ランタイムの動的な切り替えは、サービスの中断なしに発生する。

一方では、任意選択のブロック９０６において完全マイグレーション・モードが選択されたことを命令のフラグの値が表す場合、「分離変更コンテナ・マイグレーション」命令は、コンピュート・ノード上の１つ以上の仮想マシンを起動するスタンバイ・コンテナ・ランタイムを始動させ、次に、コンピュート・ノード上で実行されているｃｇｒｏｕｐベースの１つ以上のコンテナの各コンテナのｃｇｒｏｕｐおよび名前空間の、１つ以上の仮想マシン上の１つ以上のＶＭランタイムに対するライブ・マイグレーションを始動させる。

他方、任意選択のブロック９０６において部分マイグレーション・モードが選択されたことを命令のフラグの値が表す場合、「分離変更コンテナ・マイグレーション」命令は、コンピュート・ノード上の１つ以上の仮想マシンを起動するスタンバイ・コンテナ・ランタイムを始動させ、次に、コンピュート・ノード上で実行されているｃｇｒｏｕｐベースの１つ以上のコンテナのサブセットの各コンテナのｃｇｒｏｕｐおよび名前空間の、１つ以上の仮想マシン上の１つ以上のＶＭランタイムに対するライブ・マイグレーションを始動させる。部分マイグレーションは、例として、通常のｃｇｒｏｕｐランタイムおよびＶＭランタイムにわたりコンテナを水平にスケーリングすることにより促進されてもよい。

次に方法９００は、マイグレーションされたコンテナ化されたワークロードのイングレス・トラフィックを１つ以上のＶＭランタイムに再ルーティングすることにより継続する（ブロック９１０）。例としてイングレス・トラフィック・コントローラは、サービス・アップタイムに影響を与えることなく、（マイグレーションされた通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムにもともと向かっていた）イングレス・トラフィックをＶＭベースのコンテナ・ランタイムに再ルーティングするように設定されてもよい。通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムからＶＭベースのコンテナ・ランタイムへのワークロードのマイグレーションが完全であった（すなわちワークロードの１００％がマイグレーションされた）１つ以上の実施形態において、イングレス・トラフィック・コントローラは、すべてのイングレス・トラフィックをＶＭベースのコンテナ・ランタイムに再ルーティングしてもよい。通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムからＶＭベースのコンテナ・ランタイムへのワークロードのマイグレーションが部分的であった（すなわちワークロードの＜１００％がマイグレーションされた）１つ以上の実施形態において、イングレス・トラフィック・コントローラは、マイグレーションされた通常のｃｇｒｏｕｐランタイムにもともと向かっていたイングレス・トラフィックのみをＶＭベースのコンテナ・ランタイムに再ルーティングしてもよい。

さらに、１つ以上の実施形態によれば、ブロック９１０の、マイグレーションされたコンテナ化されたワークロードに対するイングレス・トラフィックの再ルーティングは、サービス・メッシュを介したトラフィック・シェーピングを使用してもよい。サービス・メッシュを介したトラフィック・シェーピングを用いるコンテナ・オーケストレーション・システムの一例が、後述の図１０に示されている。

図１０は、１つ以上の実施形態による、図８のコンテナ・オーケストレーション・システム８００に相当するがサービス・メッシュを介したトラフィック・シェーピングをさらに用いる、コンテナ・オーケストレーション・システム１０００を示す。コンテナがランタイムを切り替える（すなわちコンテナが通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムからＶＭベースのコンテナ・ランタイムに切り替わる）と、コンテナ・ランタイムに関連する決定を確実に下せるようにするために、１つ以上のサービス・メッシュ・サイドカー１００９（「サイドカー・コンテナ」とも呼ばれる）から、コンテナに関するランタイム・メタデータ（すなわちランタイム変更イベントを含むがこれに限定されない）が「中央コントローラ」（例えばサービス・メッシュ・コントローラ１００２）に送信される。図１０に示されている実施形態において、各ポッド８０７（通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムを備える）は、サイドカー・コンテナ１００７を含み、各ポッド８０９（ＶＭベースのコンテナ・ランタイムを備える）は、サイドカー・コンテナ１００９を含む（図１０では、サイドカー・コンテナをポッド内の他のコンテナから区別するために、各ポッド内のサイドカー・コンテナに陰影が付されている）。１つ以上の実施形態によれば、サービス・メッシュ・コントローラ１００２は、サービス・メッシュ・サイドカー１００９からサービス・メッシュ・コントローラ１００２が受信するランタイム・メタデータに基づいて、ルーティング・ルールの更新をイングレス・トラフィック・コントローラ８１４に送信してもよい。

サービス・メッシュの作成には、２つの論理コンポーネントが必要である。サービス・メッシュの作成に必要な第１の論理コンポーネントは、ポッドである。ポッドは、多数のコンテナを有するように設計される。サービス・メッシュの作成に必要な第２の論理コンポーネントは、「サイドカー」と呼ばれるコンテナである（例えばコンテナ・サイドカー１００９）。サービス・メッシュでは、各ポッドは１つ以上のサイドカー・コンテナを含む。サイドカーは、ポッド内のプライマリ・コンテナを拡張し、強化する。例としてサイドカー・コンテナは、プライマリ・コンテナ上のものをモニタリングし、モニタリング動作から生じるデータに対して１つ以上のタスクを実行し、それによってプライマリ・コンテナの当該の責任を軽減してもよい。サービス・メッシュでは、サイドカーはサービス・プロキシまたはデータ・プレーンであってもよい。

Ｋｕｂｅｒｎｅｔｅｓ上のサービス・メッシュは、Ｉｓｔｉｏおよび（Ｂｕｏｙａｎｔにより作成された）Ｌｉｎｋｅｒｄなどのサービス・メッシュ・ソリューションを使用して作成されてもよい。そのようなサービス・メッシュ・ソリューションでは、サービス・メッシュにおける「中央コントローラ」（例えばサービス・メッシュ・コントローラ１００２）が、各サイドカー・コンテナがどのように作動するかを定義する（サイドカー・プロキシを除く）。

１つ以上の実施形態によれば、種々のランタイムの優先順位レベルを設定することによって、様々なトラフィック・シェーピング・ポリシーがサービス・メッシュに追加されてもよい。例として、１つ以上の実施形態においてサービス・メッシュ・コントローラ１００２は、通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイム（例えばｒｕｎＣ）またはＶＭベースのコンテナ・ランタイム（例えばｒｕｎＶ）からランタイム・メタデータが受信されているかどうかに基づいて、サービス・メッシュ・ルーティング・ポリシーの変更を引き起こしてもよい。

１つ以上の実施形態によれば、サービス・メッシュにおける「中央コントローラ」（例えばサービス・メッシュ・コントローラ１００２）は、新たなコンテナ・ランタイムから現在フェッチされている新たなメトリクス（すなわちランタイム・メタデータ）に基づいて、トラフィックをシェーピングする。これは、コンテナ・ランタイム・エンジンに応じてサービス・メッシュのメトリクス・プロバイダがランタイムで切り替えられるのと同じように、動的に起こってもよい。例として、図１０に示されている実施形態において、サービス・メッシュのメトリクス・プロバイダは、サイドカー・コンテナ１００７（通常のｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムを備える）からサイドカー・コンテナ１００９（ＶＭベースのコンテナ・ランタイムを備える）にランタイムで切り替えられる。したがって、サービス・メッシュにおける「中央コントローラ」（例えばサービス・メッシュ・コントローラ１００２）は、この変更を透過的に処理するメトリクス・アダプタ１０１０を備えてもよい。

１つ以上の実施形態によれば、ＶＭベースのコンテナ・ランタイムが過負荷になりつつあることを示す新たなメトリクス（すなわちランタイム・メタデータ）に応答して、サービス・メッシュ・コントローラ１００２は、イングレス・トラフィックの一定の割合が別のノードに再ルーティングされる（すなわちＶＭベースのコンテナ・ランタイムに再ルーティングされない）サービス・メッシュ・ルーティング・ポリシーを生成してもよい。

図１０において、１つ以上の実施形態によれば、ＣＲＩＵ８２０は、ブロックのサブセットに対して任意選択（すなわちＣＲＩＵ８２０として図１０に示されているブロックのうち少なくとも１つであるがすべてではない）とされることができる。ＣＲＩＵを用いない場合、コンテナ・ランタイムの切り替えは、スタンバイ・コンテナ・ランタイムによって生成されたＶＭ（例えばＶＭ８１０）においてワークロードを開始して、イングレス・トラフィック・コントローラ（例えばイングレス・トラフィック・コントローラ８１４）のルールに適切な修正を加えてすべてのトラフィックをＶＭにルーティングすることによって実現できる（図１０ではｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムに０％のトラフィック、ＶＭベースのコンテナ・ランタイムに１００％のトラフィックとして示されている）。

本発明は、システム、方法、もしくはコンピュータ・プログラム製品、またはそのいずれかの組み合わせとされ得る。コンピュータ・プログラム製品は、プロセッサに本発明の各側面を実行させるコンピュータ可読プログラム命令を有する１つまたは複数のコンピュータ可読ストレージ媒体を含んでもよい。

コンピュータ可読ストレージ媒体は、命令実行デバイスにより使用される命令を保持および記憶することができる有形のデバイスとすることができる。コンピュータ可読ストレージ媒体は、例として、電子ストレージ・デバイス、磁気ストレージ・デバイス、光学ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、または前述のものの任意の適切な組み合わせとされ得るが、これらに限定されない。コンピュータ可読ストレージ媒体のより具体的な例の網羅的でないリストは、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）またはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：ｓｔａｔｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、メモリ・スティック、フレキシブル・ディスク、パンチ・カードまたは命令が記録された溝の中の隆起構造などの機械的にエンコードされたデバイス、および前述のものの任意の適切な組み合わせを含む。本願明細書で使用されるとき、コンピュータ可読ストレージ媒体は、電波もしくはその他自由に伝搬する電磁波、導波路もしくはその他伝送媒体を伝搬する電磁波（例えば光ファイバ・ケーブルを通過する光パルス）、またはワイヤを通して伝送される電気信号など、本質的に一時的信号であるとは解釈されないものとする。

本願明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体から個々のコンピューティング／処理デバイスに、または例としてインターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、もしくはワイヤレス・ネットワーク、またはそのいずれかの組み合わせなどのネットワークを介して外部コンピュータもしくは外部ストレージ・デバイスに、ダウンロード可能である。ネットワークは、銅製伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、もしくはエッジ・サーバ、またはそのいずれかの組み合わせを含んでもよい。各コンピューティング／処理デバイスのネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令を個々のコンピューティング／処理デバイス内のコンピュータ可読ストレージ媒体での記憶のために転送する。

本発明の動作を実行するコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：ｉｎｓｔｒｕｃｔｉｏｎ－ｓｅｔ－ａｒｃｈｉｔｅｃｔｕｒｅ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、または、Ｓｍａｌｌｔａｌｋ（Ｒ）、Ｃ＋＋、もしくは同様のものなどのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語もしくは同様のプログラミング言語などの従来の手続き型プログラミング言語を含む、１つ以上のプログラミング言語の任意の組み合わせで書かれたソース・コードもしくはオブジェクト・コードのいずれかであってもよい。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で実行されても、部分的にユーザのコンピュータ上で実行されても、スタンドアロン・ソフトウェア・パッケージとして実行されても、部分的にユーザのコンピュータ上で且つ部分的にリモート・コンピュータ上で実行されても、または完全にリモート・コンピュータもしくはサーバ上で実行されてもよい。後者のシナリオでは、ローカル・エリア・ネットワーク（ＬＡＮ）もしくはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを通してリモート・コンピュータがユーザのコンピュータに接続されてもよく、または（例としてインターネット・サービス・プロバイダを使用しインターネットを通して）外部コンピュータに接続されてもよい。１つ以上の実施形態において、本発明の各側面を実行するために、例としてプログラマブル論理回路構成、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、またはプログラマブル論理アレイ（ＰＬＡ：ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ａｒｒａｙ）を含む電子回路構成が、電子回路構成をパーソナライズするためコンピュータ可読プログラム命令の状態情報を利用することによりコンピュータ可読プログラム命令を実行してもよい。

本発明の各側面は、１つ以上の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照して本願明細書に記載されている。当然のことながら、フローチャート図もしくはブロック図またはその両方の各ブロック、およびフローチャート図もしくはブロック図またはその両方の複数ブロックの組み合わせは、コンピュータ可読プログラム命令により実装可能である。

マシンをもたらすよう、こうしたコンピュータ可読プログラム命令が、汎用コンピュータ、専用コンピュータ、またはその他プログラマブル・データ処理装置のプロセッサに提供されて、この命令が、コンピュータまたはその他プログラマブル・データ処理装置のプロセッサにより実行されて、フローチャートもしくはブロック図またはその両方の１つもしくは複数のブロックにおいて指定された機能／動作を実装する手段を作り出すようにすることもできる。特定の形で機能するようコンピュータ、プログラマブル・データ処理装置、もしくはその他デバイス、またはそのいずれかの組み合わせに指示することができる当該コンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体に記憶されて、命令を記憶されたコンピュータ可読ストレージ媒体が、フローチャートもしくはブロック図またはその両方の１つもしくは複数のブロックにおいて指定された機能／動作の各側面を実装する命令を含む製品を含むようにすることもできる。

コンピュータ可読プログラム命令はさらに、コンピュータ、その他プログラマブル・データ処理装置、またはその他デバイスにロードされて、コンピュータ、その他プログラマブル装置、またはその他デバイス上で一連の動作ステップが実行されるようにしてコンピュータで実装されるプロセスをもたらし、コンピュータ、その他プログラマブル装置、またはその他デバイス上で実行される命令が、フローチャートもしくはブロック図またはその両方の１つもしくは複数のブロックにおいて指定された機能／動作を実装するようにすることもできる。

各図面のフローチャートおよびブロック図は、様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の考えられる実装のアーキテクチャ、機能性、および動作を示す。この関連で、フローチャートまたはブロック図の中の各ブロックは、指定の論理機能（単数または複数）を実装する１つ以上の実行可能命令を含むモジュール、セグメント、または命令の一部を表現し得る。一部の代わりの実装では、ブロックに示されている機能が、図面に示されているのとは異なる順序で発生してもよい。例として、関連する機能性次第で、連続して示されている２つのブロックが実際には事実上同時に実行されてもよく、または各ブロックが逆順で実行されることがあってもよい。さらに、ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方の複数ブロックの組み合わせは、指定の機能もしくは動作を実行する、または専用ハードウェアおよびコンピュータ命令の組み合わせを実行する、専用ハードウェア・ベースのシステムにより実装できるということに留意されたい。

当業者には当然のことながら、本発明の範囲内で多数の変形物が考えられる。例として、本願明細書に記載された特定のハードウェアおよびソフトウェア実装の詳細（つまりＬｉｎｕｘ（Ｒ）カーネルを使用する）は、単に説明を目的としており、記載された主題の範囲を限定することは意図していない。よって、本発明について、その好適な実施形態を参照して詳しく示し記載したが、当業者には当然のことながら、それに対して、形態および細部における変更が、本発明の範囲から逸脱することなく加えられ得る。

Claims (19)

1. ホスト・カーネルをそれぞれ有する１つ以上のコンピュート・ノードを有するシステムにおいて、コンテナ化されたワークロードの分離を変更する方法であって、
   デフォルト・コンテナ・ランタイムを使用してワークロードをコンテナ化するステップであって、前記デフォルト・コンテナ・ランタイムは、コンピュート・ノードのホスト・カーネルの、ｃｇｒｏｕｐおよび名前空間を含むリソース制限能力を使用して、ｃｇｒｏｕｐベースの１つ以上のコンテナを前記コンピュート・ノード上に生成する、前記コンテナ化するステップと、
   前記デフォルト・コンテナ・ランタイムにより生成された前記ｃｇｒｏｕｐベースの１つ以上のコンテナにおいて実行されている前記コンテナ化されたワークロードの少なくとも一部を、スタンバイ・コンテナ・ランタイムにより起動された１つ以上の仮想マシン（ＶＭ）に、トリガ要因の検出に応答してマイグレーションするステップであって、前記トリガ要因は、認識された脅威、コンプライアンス要件の変更、およびその組み合わせからなるグループから選択される、前記マイグレーションするステップと、
   を含み、
   前記コンテナ化されたワークロードの少なくとも一部をマイグレーションするステップは、
   前記スタンバイ・コンテナ・ランタイムを始動させるステップと、
   前記コンピュート・ノード上で実行されている前記ｃｇｒｏｕｐベースの１つ以上のコンテナのうちの少なくとも１つの各コンテナの前記ｃｇｒｏｕｐおよび前記名前空間を前記１つ以上のＶＭ上の１つ以上のＶＭランタイムにライブ・マイグレーションするステップと、
   を含む、方法。
2. 前記コンテナ化されたワークロードの少なくとも一部をマイグレーションするステップは、サービスの中断なしに実行される、請求項１に記載の方法。
3. 前記デフォルト・コンテナ・ランタイムは、ｃｇｒｏｕｐおよび名前空間ベースのコンテナ・ランタイムである、請求項１または２に記載の方法。
4. 前記スタンバイ・コンテナ・ランタイムは、ＶＭベースのコンテナ・ランタイムである、請求項１から３のいずれかに記載の方法。
5. 前記コンピュート・ノード上で実行されている前記ｃｇｒｏｕｐベースの１つ以上のコンテナのうちの少なくとも１つの各コンテナの前記ｃｇｒｏｕｐおよび前記名前空間を前記１つ以上のＶＭ上の１つ以上のＶＭランタイムにライブ・マイグレーションするステップは、ユーザ空間でのチェックポイント／リストア（ＣＲＩＵ）を呼び出すステップを含み、前記方法は、
   マイグレーションされた前記コンテナ化されたワークロードの前記少なくとも一部に対するイングレス・トラフィックを前記１つ以上のＶＭランタイムに再ルーティングするステップ
   をさらに含む、請求項１から４のいずれかに記載の方法。
6. 前記デフォルト・コンテナ・ランタイムにより生成された前記ｃｇｒｏｕｐベースの１つ以上のコンテナにおいて実行されている前記コンテナ化されたワークロードのサブセットのコンテナ・ランタイムを、スタンバイ・コンテナ・ランタイムによって生成された１つ以上の仮想マシン（ＶＭ）において前記ワークロードを開始することにより切り替えるステップであって、切り替えは、ＣＲＩＵを呼び出すことを含まない、前記切り替えるステップと、
   切り替えられた前記コンテナ化されたワークロードの前記サブセットに対するイングレス・トラフィックを、前記１つ以上のＶＭランタイムにおいて開始された前記ワークロードに再ルーティングするステップと、
   をさらに含む、請求項５に記載の方法。
7. 前記トリガ要因を検出するステップと、
   前記トリガ要因に関連する１つ以上の特性に基づいて、完全マイグレーション・モードまたは部分マイグレーション・モードのいずれかを選択するステップと、
   をさらに含む、請求項１から６のいずれかに記載の方法。
8. 前記コンテナ化されたワークロードの少なくとも一部をマイグレーションするステップは、
   前記スタンバイ・コンテナ・ランタイムを始動させるステップと、
   前記コンピュート・ノード上で実行されている前記ｃｇｒｏｕｐベースの１つ以上のコンテナの各コンテナの前記ｃｇｒｏｕｐおよび前記名前空間を、前記完全マイグレーション・モードを選択することに応答して、前記１つ以上のＶＭ上の１つ以上のＶＭランタイムにライブ・マイグレーションするステップと、
   を含む、請求項７に記載の方法。
9. 前記コンテナ化されたワークロードの少なくとも一部をマイグレーションするステップは、
   前記スタンバイ・コンテナ・ランタイムを始動させるステップと、
   前記コンピュート・ノード上で実行されている前記ｃｇｒｏｕｐベースの１つ以上のコンテナのサブセットの各コンテナの前記ｃｇｒｏｕｐおよび前記名前空間を、前記部分マイグレーション・モードを選択することに応答して、前記１つ以上のＶＭ上の１つ以上のＶＭランタイムにライブ・マイグレーションするステップと、
   を含む、請求項７に記載の方法。
10. 前記コンピュート・ノード上で実行されている前記ｃｇｒｏｕｐベースの１つ以上のコンテナのサブセットの各コンテナの前記ｃｇｒｏｕｐおよび前記名前空間を、前記部分マイグレーション・モードを選択することに応答して、前記１つ以上のＶＭ上の１つ以上のＶＭランタイムにライブ・マイグレーションするステップは、ロード・バランシングを活用することによって、通常のｃｇｒｏｕｐランタイムおよびＶＭランタイムにわたりコンテナを水平にスケーリングするステップを含む、請求項９に記載の方法。
11. 前記１つ以上のＶＭ上の前記１つ以上のＶＭランタイムに関連する１つ以上のサービス・メッシュ・サイドカーから送信されたランタイム・メタデータを、サービス・メッシュ・コントローラにて受信するステップと、
    前記ランタイム・メタデータに基づいて前記サービス・メッシュ・コントローラにてルーティング・ルールを更新して、更新されたルーティング・ルールをイングレス・トラフィック・コントローラに送信するステップと、
    前記更新されたルーティング・ルールに基づいて前記イングレス・トラフィック・コントローラにてイングレス・トラフィックをルーティングするステップと、
    をさらに含む、請求項１から１０のいずれかに記載の方法。
12. ホスト・カーネルをそれぞれ有する１つ以上のコンピュート・ノードを有するシステムにおいて、コンテナ化されたワークロードの分離を変更する方法であって、
    デフォルト・コンテナ・ランタイムを使用してワークロードをコンテナ化するステップであって、前記デフォルト・コンテナ・ランタイムは、コンピュート・ノードのホスト・カーネルの、ｃｇｒｏｕｐおよび名前空間を含むリソース制限能力を使用して、ｃｇｒｏｕｐベースの１つ以上のコンテナを前記コンピュート・ノード上に生成する、前記コンテナ化するステップと、
    前記デフォルト・コンテナ・ランタイムにより生成された前記ｃｇｒｏｕｐベースの１つ以上のコンテナにおいて実行されている前記コンテナ化されたワークロードの少なくとも一部を、スタンバイ・コンテナ・ランタイムにより起動された１つ以上の仮想マシン（ＶＭ）に、トリガ要因の検出に応答してマイグレーションするステップであって、前記トリガ要因は、認識された脅威、コンプライアンス要件の変更、およびその組み合わせからなるグループから選択される、前記マイグレーションするステップと、
    を含み、
    前記コンテナ化されたワークロードの少なくとも一部をマイグレーションするステップはさらに、
    検出された前記トリガ要因に関連する１つ以上の特性に基づいて、完全マイグレーション・モードまたは部分マイグレーション・モードのいずれかを選択するステップと、
    前記スタンバイ・コンテナ・ランタイムを始動させるステップと、
    前記部分マイグレーション・モードを選択することに応答して、前記コンピュート・ノード上で実行されている前記ｃｇｒｏｕｐベースの１つ以上のコンテナのサブセットの各コンテナの前記ｃｇｒｏｕｐおよび前記名前空間を、前記１つ以上のＶＭ上の１つ以上のＶＭランタイムにライブ・マイグレーションするステップと、
    を含む、方法。
13. 前記コンピュート・ノード上で実行されている前記ｃｇｒｏｕｐベースの１つ以上のコンテナのサブセットの各コンテナの前記ｃｇｒｏｕｐおよび前記名前空間を、前記部分マイグレーション・モードを選択することに応答して、前記１つ以上のＶＭ上の１つ以上のＶＭランタイムにライブ・マイグレーションするステップは、ロード・バランシングを活用することによって、通常のｃｇｒｏｕｐランタイムおよびＶＭランタイムにわたりコンテナを水平にスケーリングするステップを含む、請求項１２に記載の方法。
14. 前記１つ以上のＶＭ上の前記１つ以上のＶＭランタイムに関連する１つ以上のサービス・メッシュ・サイドカーから送信されたランタイム・メタデータを、サービス・メッシュ・コントローラにて受信するステップと、
    前記ランタイム・メタデータに基づいて前記サービス・メッシュ・コントローラにてルーティング・ルールを更新して、更新されたルーティング・ルールをイングレス・トラフィック・コントローラに送信するステップと、
    前記更新されたルーティング・ルールに基づいて前記イングレス・トラフィック・コントローラにてイングレス・トラフィックをルーティングするステップと、
    をさらに含む、請求項１２または１３に記載の方法。
15. コンテナ化されたワークロードの分離を変更するコンピュータ・システムであって、前記コンピュータ・システムは、
    １つ以上のプロセッサ、１つ以上のコンピュータ可読ストレージ・デバイス、および前記１つ以上のプロセッサのうちの少なくとも１つによる実行のために前記１つ以上のコンピュータ可読ストレージ・デバイスのうちの少なくとも１つに記憶されたプログラム命令
    を含み、前記プログラム命令は、
    デフォルト・コンテナ・ランタイムを使用してワークロードをコンテナ化することであって、前記デフォルト・コンテナ・ランタイムは、コンピュート・ノードのホスト・カーネルの、ｃｇｒｏｕｐおよび名前空間を含むリソース制限能力を使用して、ｃｇｒｏｕｐベースの１つ以上のコンテナを前記コンピュート・ノード上に生成する、前記コンテナ化すること、
    前記デフォルト・コンテナ・ランタイムにより生成された前記ｃｇｒｏｕｐベースの１つ以上のコンテナにおいて実行されている前記コンテナ化されたワークロードの少なくとも一部を、スタンバイ・コンテナ・ランタイムにより起動された１つ以上の仮想マシン（ＶＭ）に、トリガ要因の検出に応答してマイグレーションすることであって、前記トリガ要因は、認識された脅威、コンプライアンス要件の変更、およびその組み合わせからなるグループから選択される、前記マイグレーションすること、
    のために実行可能であり、
    前記コンテナ化されたワークロードの少なくとも一部をマイグレーションすることのために実行可能な前記プログラム命令は、前記スタンバイ・コンテナ・ランタイムを始動させて、前記コンピュート・ノード上で実行されている前記ｃｇｒｏｕｐベースの１つ以上のコンテナのうちの少なくとも１つの各コンテナの前記ｃｇｒｏｕｐおよび前記名前空間を前記１つ以上のＶＭ上の１つ以上のＶＭランタイムにライブ・マイグレーションするために実行可能なプログラム命令を含む、コンピュータ・システム。
16. マイグレーションされた前記コンテナ化されたワークロードの前記少なくとも一部に対するイングレス・トラフィックを前記１つ以上のＶＭランタイムに再ルーティングするために実行可能な前記プログラム命令をさらに含む、請求項１５に記載のコンピュータ・システム。
17. 前記１つ以上のＶＭ上の前記１つ以上のＶＭランタイムに関連する１つ以上のサービス・メッシュ・サイドカーから送信されたランタイム・メタデータを、サービス・メッシュ・コントローラにて受信すること、
    前記ランタイム・メタデータに基づいて前記サービス・メッシュ・コントローラにてルーティング・ルールを更新して、更新されたルーティング・ルールをイングレス・トラフィック・コントローラに送信すること、
    前記更新されたルーティング・ルールに基づいて前記イングレス・トラフィック・コントローラにてイングレス・トラフィックをルーティングすること、
    のために実行可能な前記プログラム命令をさらに含む、請求項１６に記載のコンピュータ・システム。
18. コンテナ化されたワークロードの分離を変更するコンピュータ・プログラムであって、１つ以上のプロセッサに、請求項１から１４のいずれかに記載の方法を実行させる、コンピュータ・プログラム。
19. 請求項１８に記載のコンピュータ・プログラムを記憶したコンピュータ可読媒体。
    

Images