▶ タレス ディアイエス シーピーエル ユーエスエー インク．の特許一覧
特表2024-533321コンテナオーケストレーションシステムにおけるファイルシステムへの機能の拡張
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-12
(54)【発明の名称】コンテナオーケストレーションシステムにおけるファイルシステムへの機能の拡張
(51)【国際特許分類】
G06F 9/50 20060101AFI20240905BHJP
【ＦＩ】
G06F9/50 120Z
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024515092
(86)(22)【出願日】2022-08-29
(85)【翻訳文提出日】2024-04-12
(86)【国際出願番号】 US2022041789
(87)【国際公開番号】W WO2023038817
(87)【国際公開日】2023-03-16
(31)【優先権主張番号】63/241,623
(32)【優先日】2021-09-08
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】524075272
【氏名又は名称】タレス ディアイエス シーピーエル ユーエスエー インク．
(74)【代理人】
【識別番号】100086368
【弁理士】
【氏名又は名称】萩原 誠
(72)【発明者】
【氏名】ホセ アール，サントス
(72)【発明者】
【氏名】パーサ サラティ，ベサガラハリー ラクシュマイアー
(72)【発明者】
【氏名】スティーヴン プラット
(72)【発明者】
【氏名】マヘッシュ モハン
(57)【要約】
拡張ストレージクラスを機能拡張と関連付けることにより、コンテナオーケストレーションシステムにおけるファイルシステムの機能的能力を拡張し、拡張ストレージクラスに属するデータストレージボリュームへのアクセスを拡張ファイルシステムによって処理する。拡張ストレージクラスに属する拡張ボリュームの定義を含むアプリケーションポッド構成の展開に応答して、拡張ボリュームをマウントすることを要求し、元のデータストレージボリュームをマウントするためのステージングポッドを作成し、コンテナオーケストレーションシステムにステージングポッドを展開させる。アプリケーションポッド内のコンテナによる拡張ボリュームに格納されているデータへのアクセスは、拡張ファイルシステムによって処理される。
【選択図】 図４
【選択図】 図４
【特許請求の範囲】
【請求項1】
コンテナオーケストレーションシステムにおけるファイルシステムの能力を、前記コンテナオーケストレーションシステムの実行時環境に変更を加えることなく拡張する方法であって、ファイルシステム拡張が、それ以外の場合は前記コンテナオーケストレーションシステムの前記ファイルシステムにより提供されない機能を提供し、前記方法が、－拡張ストレージクラスを、前記拡張ストレージクラスに属するデータストレージボリュームへのアクセスを拡張ファイルシステムによって処理する拡張と関連付けること、
－元のボリュームを前記拡張ストレージクラス以外のストレージクラスと関連付けること、
－前記拡張ストレージクラスに属する拡張ボリュームの定義を含むように構成されたアプリケーションポッドの展開に応答して、
・前記拡張ボリュームをマウントすることを要求すること、
・前記拡張ファイルシステムによって、前記元のデータストレージボリュームをマウントするためのステージングポッドを作成し、前記コンテナオーケストレーションシステムに前記ステージングポッドを展開させること、
・前記ステージングポッドによって、前記元のデータストレージボリュームをマウントすること、
・前記元のデータストレージボリュームのマウントを特定するパスを決定すること、
・前記元のデータストレージボリュームの前記マウントを特定する前記パスを使用し、前記元のデータストレージボリュームをデータソースとして使用して前記拡張ストレージクラスに属する前記拡張ボリュームをマウントすること、
・前記拡張ボリュームのマウントを前記アプリケーションポッドのコンテナに公開すること、及び
・前記アプリケーションポッドを実行フェーズに入れ、前記アプリケーションポッド内の前記コンテナによる前記拡張ボリュームに格納されているデータへのアクセスを前記拡張ファイルシステムによって処理すること
を含む方法。
【請求項2】
拡張される前記能力がファイルシステム階層化である、請求項１のコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法。
【請求項3】
拡張される前記能力が、第１のボリュームを第２のボリュームに重ねて、前記第１のボリューム及び前記第２のボリュームを含む結合ボリュームを提供することである、請求項１又は２のコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法。
【請求項4】
前記コンテナオーケストレーションシステムがＫｕｂｅｒｎｅｔｅｓである、請求項１乃至３のいずれか一項のコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法。
【請求項5】
前記元のボリュームを永続ボリューム及び対応する永続ボリューム要求として作成するステップを含む、請求項１のコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法。
【請求項6】
前記拡張ボリュームを永続ボリューム及び対応する永続ボリューム要求として作成するステップを含む、請求項４又は５のコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法。
【請求項7】
前記元のボリュームを一時ボリューム及び対応する一時ボリューム要求として作成するステップを含む、請求項４乃至６のいずれか一項のコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法。
【請求項8】
前記拡張ボリュームを一時ボリューム及び対応する一時ボリューム要求として作成するステップを含む、請求項４乃至７のいずれか一項のコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法。
【請求項9】
－前記拡張ボリュームにアプリケーションコンテナによってアクセスすること、－前記拡張ボリュームへのアクセスを、前記拡張ストレージクラスと関連付けられたドライバを使用して前記アプリケーションコンテナによって整理すること
を更に含む、請求項１乃至８のいずれか一項のコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法。
【請求項10】
前記拡張ストレージクラスと関連付けられた前記ドライバが、前記拡張ボリュームに格納されているデータに対する暗号化サービスを提供する、請求項１のコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法。
【請求項11】
前記拡張ストレージクラスと関連付けられた前記ドライバが、前記拡張ボリュームに格納されているデータに対してアクセス制御ポリシーを実施する、請求項９又は１０のコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法。
【請求項12】
コンテナオーケストレーションシステムであって、前記コンテナオーケストレーションシステムの実行時環境に変更を加えることなく、前記コンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによって、ファイルシステムの能力を拡張する能力を備え、ファイルシステム拡張が、それ以外の場合は前記コンテナオーケストレーションシステムの前記ファイルシステムにより提供されない機能を提供し、－プロセッサ及びメモリを有する少なくとも１つのノードであって、前記メモリが前記プロセッサに
・拡張ストレージクラスと、前記拡張ストレージクラスに属するデータストレージボリュームへのアクセスが前記ファイルシステム拡張の階層化ファイルシステムドライバにより処理されるファイルシステム拡張との関連付けを受け入れること、
・前記拡張ストレージクラス以外のストレージクラスと元のボリュームとの関連付けを受け入れること
を行わせる命令を格納する少なくとも１つのノードを備え、
－前記メモリが更に、前記拡張ストレージクラスと関連付けられたエージェントであって、前記プロセッサに
・前記拡張ボリュームのマウント要求を受信すること、
・前記元のデータストレージボリュームをマウントするためのステージングポッドを作成し、前記コンテナオーケストレーションシステムに前記ステージングポッドを展開させること、
・前記元のデータストレージボリュームのマウントを特定するパスを決定すること、
・前記元のデータストレージボリュームの前記マウントを特定する前記パスを使用し、前記元のデータストレージボリュームをデータソースとして使用して前記拡張ストレージクラスに属する前記拡張ボリュームをマウントすること、
・前記拡張ボリュームのマウントを前記アプリケーションポッドのコンテナに公開すること
を行わせるエージェントを格納し、
－前記メモリが更に、前記ステージングポッドを含む命令であって、前記プロセッサに
・前記元のデータストレージボリュームをマウントすること
を行わせる命令を格納し、
－前記メモリが更に、前記プロセッサに、前記アプリケーションが前記拡張ボリュームの前記マウントの公開通知を受信したことに応答して、前記アプリケーションポッドを実行フェーズに入れさせる命令を格納し、前記アプリケーションポッド内の前記コンテナによる前記拡張ボリュームに格納されているデータへのアクセスを前記拡張ファイルシステムのドライバによって処理する
コンテナオーケストレーションシステム。
【請求項13】
前記機能拡張がファイルシステム階層化である、請求項１２のコンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによってファイルシステムの能力を拡張する能力を備えたコンテナオーケストレーションシステム。
【請求項14】
前記機能拡張が第１のボリュームを第２のボリュームに重ねて、前記第１のボリューム及び前記第２のボリュームを含む結合ボリュームを提供することである、請求項１２又は１３のコンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによってファイルシステムの能力を拡張する能力を備えたコンテナオーケストレーションシステム。
【請求項15】
前記コンテナオーケストレーションシステムがＫｕｂｅｒｎｅｔｅｓである、請求項１２乃至１４のいずれか一項のコンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによってファイルシステムの能力を拡張する能力を備えたコンテナオーケストレーションシステム。
【請求項16】
前記元のボリュームが永続ボリューム及び対応する永続ボリューム要求である、請求項１２のコンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによってファイルシステムの能力を拡張する能力を備えたコンテナオーケストレーションシステム。
【請求項17】
前記拡張ボリュームが永続ボリューム及び対応する永続ボリューム要求である、請求項１５又は１６のコンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによってファイルシステムの能力を拡張する能力を備えたコンテナオーケストレーションシステム。
【請求項18】
前記元のボリュームが一時ボリューム及び対応する一時ボリューム要求である、請求項１５乃至１７のいずれか一項のコンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによってファイルシステムの能力を拡張する能力を備えたコンテナオーケストレーションシステム。
【請求項19】
前記拡張ボリュームが一時ボリューム及び対応する一時ボリューム要求である、請求項１５乃至１８のいずれか一項のコンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによってファイルシステムの能力を拡張する能力を備えたコンテナオーケストレーションシステム。
【請求項20】
前記拡張ボリュームへのアプリケーションコンテナによるアクセスを、前記拡張ストレージクラスと関連付けられたドライバによって整理するように構成された、請求項１２乃至１９のいずれか一項のコンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによってファイルシステムの能力を拡張する能力を備えたコンテナオーケストレーションシステム。
【請求項21】
前記拡張ストレージクラスと関連付けられた前記ドライバが、前記拡張ボリュームに格納されているデータに対する暗号化サービスを提供する、請求項１２のコンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによってファイルシステムの能力を拡張する能力を備えたコンテナオーケストレーションシステム。
【請求項22】
前記拡張ストレージクラスと関連付けられた前記ドライバが、前記拡張ボリュームに格納されているデータに対する暗号化サービスを提供する、請求項２０又は２１のコンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによってファイルシステムの能力を拡張する能力を備えたコンテナオーケストレーションシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、概してコンテナオーケストレーションシステムに係り、より具体的には、コンテナオーケストレーション実行時環境の変更を必要とせずに、コンテナオーケストレーションシステムにおけるファイルシステムの機能を拡張することに関する。
【背景技術】
【0002】
コンテナオーケストレーションシステムは、コンテナ化されたワークロード及びサービスを管理することによって分散アプリケーションの展開、保守、及びスケーリングを自動化し、宣言的構成と自動化の両方を促進する。コンテナ化されたシステムでは、カーネルにより、例えば、よく知られているコンテナオーケストレーションシステムＫｕｂｅｒｎｅｔｅｓで使用される、コンテナと呼ばれることもある複数の分離されたユーザ空間インスタンスが可能になる。Ｋｕｂｅｒｎｅｔｅｓについては、参照により本明細書に組み込まれるｈｔｔｐｓ：／／ｋｕｂｅｒｎｅｔｅｓ．ｉｏで説明されている。また、多くの参考文献が存在し、例えば、Ｂ．Ｂｕｒｎｓ、Ｊ．Ｂｅｄａ、及びＫ．Ｈｉｇｈｔｏｗｅｒ、Ｋｕｂｅｒｎｅｔｅｓ Ｕｐ ＆ Ｒｕｎｎｉｎｇ、Ｏ’Ｒｅｉｌｌｙ（２０１９年）が参照により本明細書に組み込まれる。
【0003】
ただし、Ｋｕｂｅｒｎｅｔｅｓなどのコンテナオーケストレーションシステムは、アプリケーション展開の状態を混乱させる拡張が制限されている。例えば、Ｋｕｂｅｒｎｅｔｅｓはファイルシステム階層化をサポートしていないため、暗号化及びアクセス制御ポリシーなどのサードパーティファイルシステム保護を、コンテナオーケストレーションシステムを通じて展開されたアプリケーションに追加するメカニズムを提供しない。
【0004】
上記のことから、コンテナオーケストレーションシステムにおいてファイルシステム階層化を提供すること、それによって暗号化及びアクセス制御ポリシーなどのファイルシステム保護をコンテナオーケストレーションシステムを通じて展開されたアプリケーションに提供するためのメカニズムを提供することを含む、公開後の拡張をコンテナオーケストレーションシステムを通じて展開されたアプリケーションに提供する改善された方法が必要であることは明らかである。
【発明の概要】
【0005】
本発明は、請求項１に記載の、コンテナオーケストレーションシステムの実行時環境に変更を加えることなく、コンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法、及び請求項１２に記載のコンテナオーケストレーションシステムによる前述の問題の解決策を提供する。従属請求項では、本発明の好ましい実施形態が定義される。
【0006】
第１の発明の態様では、本発明は、コンテナオーケストレーションシステムの実行時環境に変更を加えることなく、コンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張する方法であって、ファイルシステム拡張が、それ以外の場合はコンテナオーケストレーションシステムのファイルシステムにより提供されない機能を提供し、方法が、
－拡張ストレージクラスを、拡張ストレージクラスに属するデータストレージボリュームへのアクセスを拡張ファイルシステムによって処理する拡張と関連付けること、
－元のボリュームを拡張ストレージクラス以外のストレージクラスと関連付けること、
－拡張ストレージクラスに属する拡張ボリュームの定義を含むように構成されたアプリケーションポッドの展開に応答して、
・拡張ボリュームをマウントすることを要求すること、
・拡張ファイルシステムによって、元のデータストレージボリュームをマウントするためのステージングポッドを作成し、コンテナオーケストレーションシステムにステージングポッドを展開させること、
・ステージングポッドによって、元のデータストレージボリュームをマウントすること、
・元のデータストレージボリュームのマウントを特定するパスを決定すること、
・元のデータストレージボリュームのマウントを特定するパスを使用し、元のデータストレージボリュームをデータソースとして使用して拡張ストレージクラスに属する拡張ボリュームをマウントすること、
・拡張ボリュームのマウントをアプリケーションポッドのコンテナに公開すること、及び
・アプリケーションポッドを実行フェーズに入れ、アプリケーションポッド内のコンテナによる拡張ボリュームに格納されているデータへのアクセスを、拡張ファイルシステムによって処理すること
を含む方法を提供する。
－拡張ストレージクラスを、拡張ストレージクラスに属するデータストレージボリュームへのアクセスを拡張ファイルシステムによって処理する拡張と関連付けること、
－元のボリュームを拡張ストレージクラス以外のストレージクラスと関連付けること、
－拡張ストレージクラスに属する拡張ボリュームの定義を含むように構成されたアプリケーションポッドの展開に応答して、
・拡張ボリュームをマウントすることを要求すること、
・拡張ファイルシステムによって、元のデータストレージボリュームをマウントするためのステージングポッドを作成し、コンテナオーケストレーションシステムにステージングポッドを展開させること、
・ステージングポッドによって、元のデータストレージボリュームをマウントすること、
・元のデータストレージボリュームのマウントを特定するパスを決定すること、
・元のデータストレージボリュームのマウントを特定するパスを使用し、元のデータストレージボリュームをデータソースとして使用して拡張ストレージクラスに属する拡張ボリュームをマウントすること、
・拡張ボリュームのマウントをアプリケーションポッドのコンテナに公開すること、及び
・アプリケーションポッドを実行フェーズに入れ、アプリケーションポッド内のコンテナによる拡張ボリュームに格納されているデータへのアクセスを、拡張ファイルシステムによって処理すること
を含む方法を提供する。
【0007】
コンテナオーケストレーションシステムにおけるファイルシステム機能を拡張することは、困難であることがわかっている。コンテナオーケストレーションシステム、例えばＫｕｂｅｒｎｅｔｅｓは状態マシンとして動作する。このパラダイムは、コンテナ化されたアプリケーションの公開後に追加され得る変更を制限する。その結果、依然としてコンテナオーケストレーションを状態マシンとして動作させるパラダイム内で動作しながら、コンテナオーケストレーションファイルシステムの機能拡張を実現し得るメカニズムを提供することが望ましい。
【0008】
本発明のある実施形態は、コンテナオーケストレーションシステムの実行時環境に変更を加えることなく、Ｋｕｂｅｒｎｅｔｅｓなどのコンテナオーケストレーションシステムにおけるファイルシステムの能力を拡張し、ファイルシステム拡張が、それ以外の場合はコンテナオーケストレーションシステムのファイルシステムにより提供されない機能を提供する。
【0009】
この機能拡張は、拡張ストレージクラスを、拡張ストレージクラスに属するデータストレージボリュームへのアクセスを拡張ファイルシステムによって処理する拡張と関連付けること、元のボリュームを拡張ストレージクラス以外のストレージクラスと関連付けること、拡張ストレージクラスに属する拡張ボリュームの定義を含むように構成されたアプリケーションポッドの展開に応答して、拡張ボリュームをマウントすることを要求すること、拡張ファイルシステムによって、元のデータストレージボリュームをマウントするためのステージングポッドを作成し、コンテナオーケストレーションシステムにステージングポッドを展開させること、ステージングポッドによって、元のデータストレージボリュームをマウントすること、
元のデータストレージボリュームのマウントを特定するパスを決定すること、元のデータストレージボリュームのマウントを特定するパスを使用し、元のデータストレージボリュームをデータソースとして使用して拡張ストレージクラスに属する拡張ボリュームをマウントすること、拡張ボリュームのマウントをアプリケーションポッドのコンテナに公開すること、及びアプリケーションポッドを実行フェーズに入れ、アプリケーションポッド内のコンテナによる拡張ボリュームに格納されているデータへのアクセスを拡張ファイルシステムによって処理することによって達成される。
元のデータストレージボリュームのマウントを特定するパスを決定すること、元のデータストレージボリュームのマウントを特定するパスを使用し、元のデータストレージボリュームをデータソースとして使用して拡張ストレージクラスに属する拡張ボリュームをマウントすること、拡張ボリュームのマウントをアプリケーションポッドのコンテナに公開すること、及びアプリケーションポッドを実行フェーズに入れ、アプリケーションポッド内のコンテナによる拡張ボリュームに格納されているデータへのアクセスを拡張ファイルシステムによって処理することによって達成される。
【0010】
ある実施形態において、コンテナオーケストレーションシステムにおけるファイルシステムの能力の拡張では、拡張能力がファイルシステム階層化であり、別の態様では、拡張能力は、第１のボリュームを第２のボリュームに重ねて、第１のボリューム及び第２のボリュームを含む結合ボリュームを提供することである。
【0011】
ある実施形態では、元のボリュームは、永続ボリューム及び対応する永続ボリューム要求として作成される。代替例では、元のボリュームは、一時ボリューム及び対応する一時ボリューム要求として作成される。
【0012】
ある実施形態では、拡張ボリュームは、永続ボリューム及び対応する永続ボリューム要求として作成される。代替例では、拡張ボリュームは、一時ボリューム及び対応する一時ボリューム要求である。
【0013】
ある実施形態では、拡張ボリュームはアプリケーションコンテナによってアクセスされ、そのアクセスは、拡張ストレージクラスと関連付けられたドライバによって整理され、拡張ストレージクラスと関連付けられたドライバは、例えば、拡張ボリュームに格納されているデータに対する暗号化サービスを提供したり、拡張ボリュームに格納されているデータに対してアクセス制御ポリシーを実施したりする。
【0014】
第２の発明の態様では、本発明は、コンテナオーケストレーションシステムであって、コンテナオーケストレーションシステムの実行時環境に変更を加えることなく、コンテナオーケストレーションシステムにより提供される元のデータストレージボリュームに機能拡張を提供することによって、ファイルシステムの能力を拡張する能力を備え、ファイルシステム拡張が、それ以外の場合はコンテナオーケストレーションシステムのファイルシステムにより提供されない機能を提供し、
－プロセッサ及びメモリを有する少なくとも１つのノードであって、メモリがプロセッサに
・拡張ストレージクラスと、拡張ストレージクラスに属するデータストレージボリュームへのアクセスがファイルシステム拡張の階層化ファイルシステムドライバにより処理されるファイルシステム拡張との関連付けを受け入れること、
・拡張ストレージクラス以外のストレージクラスと元のボリュームとの関連付けを受け入れること
を行わせる命令を格納する少なくとも１つのノードを備え、
－メモリが更に、拡張ストレージクラスと関連付けられたエージェントであって、プロセッサに
・拡張ボリュームのマウント要求を受信すること、
・元のデータストレージボリュームをマウントするためのステージングポッドを作成し、コンテナオーケストレーションシステムにステージングポッドを展開させること、
・元のデータストレージボリュームのマウントを特定するパスを決定すること、
・元のデータストレージボリュームのマウントを特定するパスを使用し、元のデータストレージボリュームをデータソースとして使用して拡張ストレージクラスに属する拡張ボリュームをマウントすること、
・拡張ボリュームのマウントをアプリケーションポッドのコンテナに公開すること
を行わせるエージェントを格納し、
－メモリが更に、ステージングポッドを含む命令であって、プロセッサに
・元のデータストレージボリュームをマウントすること
を行わせる命令を格納し、
－メモリが更に、プロセッサに、アプリケーションが拡張ボリュームのマウントの公開通知を受信したことに応答して、アプリケーションポッドを実行フェーズに入れさせる命令を格納し、アプリケーションポッド内のコンテナによる拡張ボリュームに格納されているデータへのアクセスが、拡張ファイルシステムのドライバによって処理される
コンテナオーケストレーションシステムを提供する。
－プロセッサ及びメモリを有する少なくとも１つのノードであって、メモリがプロセッサに
・拡張ストレージクラスと、拡張ストレージクラスに属するデータストレージボリュームへのアクセスがファイルシステム拡張の階層化ファイルシステムドライバにより処理されるファイルシステム拡張との関連付けを受け入れること、
・拡張ストレージクラス以外のストレージクラスと元のボリュームとの関連付けを受け入れること
を行わせる命令を格納する少なくとも１つのノードを備え、
－メモリが更に、拡張ストレージクラスと関連付けられたエージェントであって、プロセッサに
・拡張ボリュームのマウント要求を受信すること、
・元のデータストレージボリュームをマウントするためのステージングポッドを作成し、コンテナオーケストレーションシステムにステージングポッドを展開させること、
・元のデータストレージボリュームのマウントを特定するパスを決定すること、
・元のデータストレージボリュームのマウントを特定するパスを使用し、元のデータストレージボリュームをデータソースとして使用して拡張ストレージクラスに属する拡張ボリュームをマウントすること、
・拡張ボリュームのマウントをアプリケーションポッドのコンテナに公開すること
を行わせるエージェントを格納し、
－メモリが更に、ステージングポッドを含む命令であって、プロセッサに
・元のデータストレージボリュームをマウントすること
を行わせる命令を格納し、
－メモリが更に、プロセッサに、アプリケーションが拡張ボリュームのマウントの公開通知を受信したことに応答して、アプリケーションポッドを実行フェーズに入れさせる命令を格納し、アプリケーションポッド内のコンテナによる拡張ボリュームに格納されているデータへのアクセスが、拡張ファイルシステムのドライバによって処理される
コンテナオーケストレーションシステムを提供する。
【0015】
この明細書（特許請求の範囲、説明及び図面を含む）に記載される全ての特徴及び／又は記載される方法の全てのステップは、そのような相互に排他的な特徴及び／又はステップの組み合わせを除いて、任意の組み合わせで組み合わせることができる。
【図面の簡単な説明】
【0016】
本発明のこれら及び他の特徴及び利点は、図面を参照し、単なる例として示され、それに限定されるものではない本発明の好ましい実施形態から明らかとなる本発明の詳細な説明を考慮して明確に理解されることになる。
【0017】
【図1】コンテナオーケストレーションシステムを使用して管理されるクラスタのブロック図。
【図2】ストレージ、具体的には永続ストレージの作成及び消費に関するＫｕｂｅｒｎｅｔｅｓクラスタの典型的なフローを示すフロー図。
【図3】例示的な構成ファイルの実行から得られる例示的なクラスタを示す高レベルブロック図。
【図4】コンテナオーケストレーションシステムにおけるファイルシステム機能の拡張をサポートするある実施形態を示す高レベルアーキテクチャ図。
【図5】ａ、ｂ、及びｃは、コンテナオーケストレーションシステム内のアプリケーションポッドに拡張機能を提供するためのプロセスステップを示すタイミングシーケンス図。
【図5a】コンテナオーケストレーションシステム内のアプリケーションポッドに拡張機能を提供するためのプロセスステップを示すタイミングシーケンス図。
【図5b】コンテナオーケストレーションシステム内のアプリケーションポッドに拡張機能を提供するためのプロセスステップを示すタイミングシーケンス図。
【図5c】コンテナオーケストレーションシステム内のアプリケーションポッドに拡張機能を提供するためのプロセスステップを示すタイミングシーケンス図。
【発明を実施するための形態】
【0018】
当業者には理解されるように、本発明の態様は、身分証明書、電子デバイスベースのモジュール、又は電子デバイスの取り込まれた画像の品質を決定する方法として具現化されることがある。
【0019】
以下の詳細な説明では、本発明が実施され得る特定の実施形態を例示として示す添付図面を参照する。これらの実施形態は、当業者が本発明を実施できるように十分に詳細に説明されている。本発明の様々な実施形態が、異なっていても、必ずしも相互に排他的ではないことを理解されたい。例えば、一実施形態に関連して本明細書に記載される特定の特徴、構造、又は特性は、本発明の趣旨及び範囲から逸脱することなく、他の実施形態内で実装されることがある。また、開示された各実施形態内の個々の要素の位置又は配置が、本発明の趣旨及び範囲から逸脱することなく変更され得ることを理解されたい。したがって、以下の詳細な説明は限定的な意味に解釈されるべきではなく、本発明の範囲は、特許請求の範囲が権利を有する均等物の全範囲とともに、適切に解釈される添付の特許請求の範囲によってのみ定義される。図面において、同様の数字は、いくつかの図を通して同じ又は同様の機能を指す。
【0020】
以下の説明には、集積回路チップのプロセッサにより実行される様々な方法への言及が含まれる。当分野では一般的であるように、本明細書には、これらの方法又は方法ステップがソフトウェア命令又はソフトウェアモジュールによって実行されることを示す語句が存在する場合がある。当業者が知っているように、そのような説明は、プロセッサが実際に方法、ソフトウェア命令、及びソフトウェアモジュールを実行し、そのようなソフトウェア命令及びモジュールが命令メモリに格納されることを意味すると解釈されるべきである。
【0021】
本明細書で説明するテクノロジーは、コンテナオーケストレーションシステムにファイルシステム階層化を提供することを含む、コンテナオーケストレーションシステムを通じて展開されたアプリケーションに公開後の拡張を提供するためのメカニズムを提供し、それによって、アプリケーション自体の変更を必要とすることなく、コンテナオーケストレーションシステムを通じて展開されたアプリケーションへのファイルシステム暗号化及びアクセス制御ポリシーの追加を可能にする。これらのファイルシステム拡張は、コンテナオーケストレーションシステムにより提供される実行時環境の変更を必要とすることなく、コンテナ化されたアプリケーションに提供される。
【0022】
定義
クラスタとは、クラスタ管理者により集合的に管理される関連するマシンの集合である。例えば、クラスタ管理者は、Ｋｕｂｅｒｎｅｔｅｓの例では、ｋｕｂｅｃｔｌとして知られているコマンドラインツールを通じてクラスタを管理することがある。
クラスタとは、クラスタ管理者により集合的に管理される関連するマシンの集合である。例えば、クラスタ管理者は、Ｋｕｂｅｒｎｅｔｅｓの例では、ｋｕｂｅｃｔｌとして知られているコマンドラインツールを通じてクラスタを管理することがある。
【0023】
クラスタを構成するマシンはノードと呼ばれる。ノードは仮想マシン又は物理マシンのいずれかである場合がある。ただし、仮想マシンは最終的には１つ以上の物理マシン上で実行されるため、ノードのクラスタの機能が向上すると、物理マシンの機能が向上する。
【0024】
クラスタには２種類のノード、すなわち、少なくともワーカノード及びマスタノードが存在する。コンテナ化されたアプリケーションがワーカノードにある。Ｋｕｂｅｒｎｅｔｅｓサービスは通常、マスタノードでホストされる。
【0025】
コンテナ、すなわちコンテナ化されたアプリケーションが実行される環境は、与えられたコンテナ内で実行されるコンテナ化されたアプリケーションに利用できる定義されたリソースのセットを提供する。コンテナには、コンテナ化されたアプリケーションが実行する必要がある全ての定義、すなわちランタイム、ライブラリ、ストレージ定義が含まれている。したがって、コンテナ化されたアプリケーションの開発者が、コンテナ化アプリケーションがどのマシンに展開されるかに関係なくコンテナ定義が同じままであるため、どこで実行されても正しく実行されることを期待することができる。
【0026】
Ｋｕｂｅｒｎｅｔｅｓは、コンテナをポッド内に配置することによってアプリケーションを実行する。ポッドは、Ｋｕｂｅｒｎｅｔｅｓにおける展開可能な最小単位である。したがって、ポッドにコンテナが１つだけ含まれている場合でも、そのコンテナはポッド内にある、すなわち、ポッドはコンテナの周囲にシェルを提供する。ポッド定義、又はポッド構成（ポッド構成ファイル）は、ポッドのストレージ要件を宣言する。
【0027】
図１は、例として上記の概念のいくつかを示している。この場合、クラスタ１０１はワーカノード１０３及びマスタノード１０５から構成される。ワーカノード１０３は３つのポッド１０７ａ～１０７ｃを含む。そしてこれらには、コンテナ１０９ａから１０９ｇがそれぞれ含まれる。
【0028】
Ｋｕｂｅｒｎｅｔｅｓシステムの機能は、ワーカノード１０３及びマスタノード１０５にあるサービスを通じて提供される。したがって、ワーカノード１０３には、Ｋｕｂｅｒｎｅｔｅｓワーカノード（ＷＮ）システム１１０と呼ばれるポッドが含まれる。同様に、マスタノード１０５には、Ｋｕｂｅｒｎｅｔｅｓマスタノード（ＭＮ）システム１１２と呼ばれるポッドが含まれる。本開示に関連するこれらの詳細を以下に説明する。
【0029】
ワーカノード１０３で実行されるアプリケーションにサービスを提供するマスタノード１０５は、Ｋｕｂｅｒｎｅｔｅｓマスタノードシステム１１２にあるＫｕｂｅｒｎｅｔｅｓシステムサービスを含むいくつかのコンポーネントを含む。これらには、ワーカノード１０３内のアプリケーションがクラスタとの通信に使用するアプリケーションインターフェイスサーバ（ＡＰＩ）１１１が含まれる。更に、ＡＰＩサーバ１１１は、コマンドラインツールｋｕｂｅｃｔｌに入力されたコマンドをサービスする。
【0030】
マスタノード１０５は、例えばＫｕｂｅｒｎｅｔｅｓマスタノードシステム１１２内にコンテナストレージインターフェイス（ＣＳＩ）サーバ１１３も含む。ＣＳＩサーバ１１３の役割は、コンテナ化されたアプリケーションにより使用されるサードパーティストレージプラグインを管理することである。これらの機能については、以下で詳細に説明する。
【0031】
マスタノード１０５は、例えば、Ｋｕｂｅｒｎｅｔｅｓマスタノードシステム１１２内にスケジューラ１１５も含む。スケジューラ１１５は、クラスタ１０１上で実行される様々なポッドの要件、及びノードの、例えば与えられたノードで利用可能なストレージの観点の能力に応じて、クラスタ内の特定のノードにポッドを割り当てる。
【0032】
マスタノード１０５には追加のコンポーネントが含まれる。ただし、これらのコンポーネントはこの考察には必要がない。
【0033】
Ｋｕｂｅｒｎｅｔｅｓは、ポッドを所望の状態に移行させようとするという意味で状態マシンである。ポッドライフサイクルは、いくつかのフェーズ、すなわち保留、実行、成功、及び失敗で構成される。Ｋｕｂｅｒｎｅｔｅｓは、ポッドを保留から終了フェーズの１つ、成功又は失敗に移行させようとする。当然のことながら、多くのポッドにとって、実行は意図的にシャットダウンするか、何らかのエラー状態によって終了しない限り、ポッドが維持されることが期待されるフェーズである場合がある。一般に、Ｋｕｂｅｒｎｅｔｅｓはエラーにより終了したポッドを再起動しようとし、クラスタを所望の状態に向けて移行させる。
【0034】
保留フェーズでは、ポッドがＫｕｂｅｒｎｅｔｅｓクラスタに受け入れられている。ただし、少なくとも１つのコンテナには、例えばストレージの割り当てを含む、何らかの形式のセットアップが依然として必要である。
【0035】
実行フェーズでは、ポッドがノードに割り当てられており、ポッドの全てのコンテナが作成されている。少なくとも１つのコンテナが実行されているか又は起動されている。
【0036】
ポッド内の全てのコンテナがエラーなく正常に終了すると、ポッドは成功フェーズにある。成功フェーズにあるポッドは再起動されない。逆に、ポッドの全てのコンテナが終了し、少なくとも１つのポッドが異常終了した場合、ポッドは失敗フェーズにある。ポッド定義によって、失敗フェーズにある場合にポッドは自動的に再起動されることがある。
【0037】
ポッドが様々なフェーズの１つに存在する場合、コンテナはそれぞれ状態と関連付けられる。これらには、待機、実行、終了が含まれる。待機状態にあるコンテナが、起動を完了するのに必要な操作を実行している。実行コンテナとは、実行しているコンテナである。完了又は失敗したコンテナが終了状態にある。
【0038】
Ｋｕｂｅｒｎｅｔｅｓにおけるストレージは、一時的なものか永続的なものである可能性がある。一時ストレージは、ストレージを使用するポッドが実行されていないときに期限切れになる。ただし、永続ストレージは、それを使用するポッドが終了するときに期限切れにならない。
【0039】
図２は、ストレージ、具体的には永続ストレージの作成と消費に関するＫｕｂｅｒｎｅｔｅｓクラスタの典型的なフローを示している。ここで考察する例では永続ボリュームを使用するが、説明する技術が一時ボリュームにも同様に適用できることに留意されたい。
【0040】
第１のステップは、クラスタ管理者が、例えばコマンドラインツールｋｕｂｅｃｔｌを用いて永続ボリュームを作成することである（ステップ２０１）。表１は、永続ボリュームの作成用の例示的なＹＡＭＬファイルである（ＹＡＭＬは、ＹＡＭＬ Ａｉｎ’ｔ ａ Ｍａｒｋｕｐ Ｌａｎｇａｇｅの再帰的頭字語である）（ｎｆｓ－ｐｖ．ｙａｍｌ）。
【0041】
１ ａｐｉバージョン：ｖ１
２ 種類：永続ボリューム
３ メタデータ：
４ 名前：ｎｆｓ－ｆｒａｎｃｉｓｃｏ
５ スペック：
６ 容量：
７ ストレージ：５Ｇｉ
８ アクセスモード：
９ －複数のノードから読み書き可
１０ ストレージクラス名：ｎｆｓ
１１ マウントオプション：
１２ －ハード
１３ －ｎｆｓｖｅｒｓ＝３.０
１４ ｎｆｓ：
１５ パス：／ｈｏｍｅ／ｆｒａｎｃｉｓｃｏ
１６ サーバ：１０.１０.１０.１０
１７ 永続ボリューム再要求ポリシー：保持する
表１：ｎｆｓ－ｐｖ．ｙａｍｌ
２ 種類：永続ボリューム
３ メタデータ：
４ 名前：ｎｆｓ－ｆｒａｎｃｉｓｃｏ
５ スペック：
６ 容量：
７ ストレージ：５Ｇｉ
８ アクセスモード：
９ －複数のノードから読み書き可
１０ ストレージクラス名：ｎｆｓ
１１ マウントオプション：
１２ －ハード
１３ －ｎｆｓｖｅｒｓ＝３.０
１４ ｎｆｓ：
１５ パス：／ｈｏｍｅ／ｆｒａｎｃｉｓｃｏ
１６ サーバ：１０.１０.１０.１０
１７ 永続ボリューム再要求ポリシー：保持する
表１：ｎｆｓ－ｐｖ．ｙａｍｌ
【0042】
ファイルｎｆｓ－ｐｖ．ｙａｍｌは、ｎｆｓ－ｆｒａｎｃｉｓｃｏ（行４）という名前の新しい永続ボリューム（行２）を作成する。これは、ストレージ容量が５Ｇｉ（行７）のネットワークファイルストレージ（ｎｆｓ）ボリューム（ストレージクラス名（行１０）で定義される）である。永続ボリューム作成は、ボリュームの場所、この場合は１０.１０.１０.１０という名前のサーバ（行１６）上、及びその上のパス／ｈｏｍｅ／ｆｒａｎｃｉｓｃｏ（行１５）を指定する。
【0043】
永続ボリュームを使用するために、名前空間マネージャが、例えば、永続ボリューム又はその一部分を要求する（ステップ２０３）。これは、コマンドラインツールｋｕｂｅｃｔｌを使用して行われることがある。そのような要求は、永続ボリューム要求（ＰＶＣ）と呼ばれる。表２は、永続ボリューム要求（ＰＶＣ）を作成するための例示的なＹＡＭＬファイルである。
【0044】
１ ａｐｉバージョン：ｖ１
２ 種類：永続ボリューム要求
３ メタデータ：
４ 名前：ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ
５ スペック：
６ ストレージクラス名：ｎｆｓ
７ アクセスモード：
８ －複数のノードから読み書き可
９ リソース：
１０ リクエスト：
１１ ストレージ：１Ｇｉ
表２：ｎｆｓ－ｃｌａｉｍ.ｙａｍｌ
２ 種類：永続ボリューム要求
３ メタデータ：
４ 名前：ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ
５ スペック：
６ ストレージクラス名：ｎｆｓ
７ アクセスモード：
８ －複数のノードから読み書き可
９ リソース：
１０ リクエスト：
１１ ストレージ：１Ｇｉ
表２：ｎｆｓ－ｃｌａｉｍ.ｙａｍｌ
【0045】
ｎｆｓ－ｃｌａｉｍ.ｙａｍｌファイルは、１Ｇｉ（行１１）の永続（行２）ｎｆｓ（行６）ストレージを要求する。その永続ボリューム要求には、ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍという名前が付けられる（行４）。スケジューラ１１５は、その永続ボリューム要求を、要求されたストレージを満たし得る任意の永続ボリューム、例えばステップ２０１で作成された永続ボリューム、すなわち表１の例におけるｎｆｓ－ｆｒａｎｃｉｓｃｏに割り当てることがある。
【0046】
次に永続ボリューム要求（ＰＶＣ）がアプリケーションポッド構成、すなわちポッドを定義する構成ファイルに追加される（ステップ２０５）。ポッド構成ファイルは、そのポッド内のコンテナのディレクトリ構造を定義する。表３は、ＰＶＣ ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍを使用する例示的なポッド構成ＹＡＭＬファイルである。
【0047】
１ ａｐｉバージョン：ｖ１
２ 種類：ポッド
３ メタデータ：
４ 名前：ｎｆｓ－ｄｅｍｏ
５ スペック：
６ ボリューム：
７ －名前：ｔｅｓｔ－ｖｏｌ
８ 永続ボリューム要求：
９ 要求名：ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ
１０ コンテナ：
１１ －名前：ｕｂｕｎｔｕ
１２ イメージ：ｕｂｕｎｔｕ
１３ ボリュームマウント：
１４ －マウントパス：“／データ”
１５ 名前：ｔｅｓｔ－ｖｏｌ
１６ コマンド：
１７ －“スリープ”
１８ －“６０４８００”
１９ イメージプルポリシー：ＩｆＮｏｔＰｒｅｓｅｎｔ
２０ 再起動ポリシー：常時
表３：ｄｅｍｏ－ｐｏｄ．ｙａｍｌ
２ 種類：ポッド
３ メタデータ：
４ 名前：ｎｆｓ－ｄｅｍｏ
５ スペック：
６ ボリューム：
７ －名前：ｔｅｓｔ－ｖｏｌ
８ 永続ボリューム要求：
９ 要求名：ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ
１０ コンテナ：
１１ －名前：ｕｂｕｎｔｕ
１２ イメージ：ｕｂｕｎｔｕ
１３ ボリュームマウント：
１４ －マウントパス：“／データ”
１５ 名前：ｔｅｓｔ－ｖｏｌ
１６ コマンド：
１７ －“スリープ”
１８ －“６０４８００”
１９ イメージプルポリシー：ＩｆＮｏｔＰｒｅｓｅｎｔ
２０ 再起動ポリシー：常時
表３：ｄｅｍｏ－ｐｏｄ．ｙａｍｌ
【0048】
このファイルは、ｎｆｓ－ｄｅｍｏと呼ばれるポッドを構成する（図３ではＮｆｓ－ｄｅｍｏポッド３０５として示されている）。これには、ポッドの名前空間においてｔｅｓｔ－ｖｏｌ（行１５）と呼ばれる永続ボリューム要求ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ（行９）の使用が含まれる。また、ｕｂｕｎｔｕと呼ばれるコンテナの使用も宣言し（行１０～１９）、ボリュームｔｅｓｔ－ｖｏｌを／データ（行１４）と呼ばれるマウントパスにマウントする必要がある（行１３～１５）。
【0049】
したがって、クラスタ内のポッドは、クラスタ内に独自の名前空間を有する可能性があるため、アプリケーションの機能グループをクラスタ内で分割することができる。
【0050】
次にアプリケーションポッドがＫｕｂｅｒｎｅｔｅｓクラスタによって展開される（ステップ２０７）。アプリケーションポッドの展開の詳細はこの文献の範囲外である。
【0051】
ポッドを保留から実行に移行させるための起動動作中に、ポッドが必要とするリソースが設定される。そのプロセスにおいて、ポッドに１つ以上のボリューム要求が定義されていることをＫｕｂｅｒｎｅｔｅｓが検出した場合、Ｋｕｂｅｒｎｅｔｅｓはそれらのボリューム要求をマウントする（ステップ２０９）。ボリューム要求に対応する永続ボリュームをマウントするためのメカニズムは、そのボリュームをサポートするドライバによって定義される。例えば、永続ボリュームがホストパスの場合、ホスト内のディレクトリがマウントされるが、永続ボリュームがネットワークストレージの場合、永続ボリューム定義にはサーバアドレスや認証トークンなどの他の多くのパラメータが含まれることがある。言い換えれば、永続ボリュームがどのようにマウントされるかは、その永続ボリュームに固有の属性である。
【0052】
永続ボリュームがマウントされると、これらのマウントはポッド内の全てのコンテナに公開される（ステップ２１１）。Ｋｕｂｅｒｎｅｔｅｓは各ポッドの定義された状態を維持しようとする状態マシンであるため、ポッドにより定義された全ての永続ボリュームが公開されると、それ以上永続ボリューム要求がポッドに追加されることがない。
【0053】
最後に、ポッド構成により定義された全ての永続ボリュームがマウントされた状態で、ポッドは実行フェーズに移行する（ステップ２１３）。
【0054】
図３は、表１、２、及び３の例の構成ファイルを実行した結果であり得る、クラスタ３０１を示す高レベルブロック図である。
【0055】
クラスタ３０１は、クラスタ管理者によって、例えばコマンドラインツールｋｕｂｅｃｔｌを使用して作成され、表１、２、及び３の構成ファイルを通じて構成されている。
【0056】
そのクラスタ３０１には、ポッドｎｆｓ－ｄｅｍｏ３０５のインスタンスが作成されたワーカノード３０３が含まれる。ポッドｎｆｓ－ｄｅｍｏ３０５は、マウント３０９（／データ）を含むコンテナｕｂｕｎｔｕ３０７を含む。当然のことながら、クラスタ３０１は、より多くのノード及びより多くのポッドを含むことがあり、ポッド３０５は追加のコンテナを含むことがある。
【0057】
マウント３０９は、Ｋｕｂｅｒｎｅｔｅｓ内部パス表現３１１を指し、これにより、マウント３０９が永続ボリューム要求３１３ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ、ひいては永続ボリューム３１５ｎｆｓ－ｆｒａｎｓｉｓｃｏにリンクされ、最終的にネットワークファイルストレージ３１７にリンクされる。
【0058】
図４～図６に示される実施形態では、上記のメカニズムは、展開及び公開されたポッドにより要求されるファイルシステムにより提供される機能に対する追加の機能を可能にするために拡張される。例えば、追加される機能は、暗号化サービスやアクセス制御サービスなどの機能を提供するファイルシステム階層化である場合がある。ファイルシステムに格納されているデータを消費することを目的としたアプリケーションが、ファイルシステムの暗号化又はアクセス制御メカニズムを必要とするシナリオを考える。そうするために、本明細書で以下に説明する実施形態は、そのような暗号化サービス又はアクセス制御メカニズムを提供するファイルシステム層を追加する。
【0059】
図４は、ファイルシステム機能の拡張、例えば、Ｋｕｂｅｒｎｅｔｅｓにおけるファイルシステム階層化をサポートし、具体的にはＫｕｂｅｒｎｅｔｅｓクラスタに展開されるコンテナ化されたアプリケーションに暗号化サービスを含むファイルアクセス制御メカニズムを提供するための実施形態を示す高レベルアーキテクチャ図である。ファイルシステム階層化が図４に示され、図４と関連させて以下で説明されるが、この技術は、複数のファイルが１つとしてアクセスされ得る他のファイルシステム拡張、例えばファイルシステムオーバーレイをコンテナオーケストレーションシステムに提供するのに用いられることがある。
【0060】
図１のマスタノード１０５に対応するマスタノード４０５に位置するＡＰＩサーバ１１１、ＣＳＩサーバ１１３、及びスケジューラ１１５（まとめてＫｕｂｅｒｎｅｔｅｓマスタノード（ＭＮ）システム４１１）などの通常のＫｕｂｅｒｎｅｔｅｓサービスは変わらない。
【0061】
マスタノード４０５は更に、拡張ＣＳＩドライバ４１７を備える。以下で考察するように、拡張ＣＳＩドライバ４１７は、例えば暗号化サービス及びアクセス制御サービスを格納されているデータに提供するために階層化ファイルシステムが提供される永続ボリュームを提供する。
【0062】
図１のワーカノード１０３に対応する、クラスタ４０１のワーカノード４０３は、それぞれが１つ以上のコンテナ４０９を有するアプリケーションポッド４０７を含む。アプリケーションポッド４０７は１つだけ示されているが、ワーカノード４０３に含まれ得るポッドの数に理論的な制限がないことを理解されたい。
【0063】
ワーカノード４０３は更に、拡張ＣＳＩドライバ４１７に対応する拡張ＣＳＩエージェント４２３を含む。これらはまとめて拡張ＣＳＩシステムである。拡張ＣＳＩ（ＥＸＴ ＣＳＩ）エージェント４２３の役割は、拡張ＣＳＩドライバ４１７からのサービスを必要とするアプリケーションポッドを認識することである。更に、拡張ＣＳＩドライバ４１７は、ファイル暗号化、復号化、鍵管理、及びデジタル署名などの暗号化サービス４１９を提供することがある。更に、拡張ＣＳＩドライバ４１７は、アクセス制御ポリシーサービス４２１を提供することがある（又は代替的に提供することがある）。
【0064】
ワーカノード４０３は更に、Ｋｕｂｅｒｎｅｔｅｓワーカノード（ＷＮ）システムポッド４１０内にＫｕｂｅｒｎｅｔｅｓシステムのワーカノード部分を含む。
【0065】
図５は、拡張ＣＳＩ（ＥＸＴ ＣＳＩ）サービスをアプリケーションポッド４０７に提供するためのプロセスステップを示すタイミングシーケンス図である。ステップの多くは、図２のステップに直接対応する。これらのステップには一重引用符の付いた参照番号が付けられている。すなわち図５のステップ２０１'は、図２のステップ２０１に対応する。
【0066】
最初の２つのステップは、図２のステップに類似している。ステップ２０３'の結果は、ステップ２０３と同様に、与えられた名前の永続ボリューム要求であることに留意されたい。この永続ボリューム要求は後のステップで参照され、ファイルシステム層をその永続ボリューム要求にリンクさせる。ＰＶの作成（ステップ２０１’）及びＰＶＣの作成（ステップ２０３'）に応答して、Ｋｕｂｅｒｎｅｔｅｓマスタノードシステム４１１は、ＰＶ（ステップ５０１）及びＰＶＣ（ステップ５０３）をそれぞれ登録する。
【0067】
以下に、ステップ２０１'で作成された永続ボリューム要求の上にファイルシステム層を追加するためのメカニズムを説明する。その永続ボリューム要求は、元の永続ボリューム要求と呼ばれる。一実施形態では、元の永続ボリューム要求に追加されるファイルシステム層は、元の永続ボリュームを保護するために暗号化サービスを追加する。その意味で、元の永続ボリュームは、ファイルシステム層がその保護されていないボリュームを保護し、保護されたボリュームが生成されるまで、保護されていないボリュームとみなされることがある。
【0068】
通常、ステップ２０１'は、コマンドラインツールｋｕｂｅｃｔｌを使用してクラスタ管理者６０１によって実行される。代替的に、永続ボリュームが自動的に作成される。同様に、ステップ２０３'におけるＰＶＣの作成は、特定のアプリケーションポッド４０７を担当する名前空間管理者６０３によって、又は自動化されたステップで実行されることがある。
【0069】
予備的な事項として、拡張ＣＳＩに対応する永続ボリュームのストレージクラスが、名前空間管理者６０３によって定義される（ステップ５０５）。表４は、拡張ＣＳＩのストレージクラスを宣言するための例示的なＹＡＭＬコードを示す。
【0070】
１ ａｐｉバージョン：ｓｔｏｒａｇｅ．ｋ８ｓ．ｉｏ／ｖ１
２ 種類：ストレージクラス
３ メタデータ：
４ 名前：ｃｓｉ－ｔｅｓｔ－ｓｃ
５ プロビジョナ：ｅｘｔ.ｃｓｉ
６ 再要求ポリシー：保持する
７ ボリュームバインディングモード：即時
８ ボリューム拡張許可：真
９ パラメータ：
１０ ｃｍａｄｄｒ：１９２.１６８.７０.１
１１ テスト＿パラメータ：これはテストである
表４：ｅｘｔｅｎｄｅｄ－ｓｔｏｒａｇｅ．ｙａｍｌ
２ 種類：ストレージクラス
３ メタデータ：
４ 名前：ｃｓｉ－ｔｅｓｔ－ｓｃ
５ プロビジョナ：ｅｘｔ.ｃｓｉ
６ 再要求ポリシー：保持する
７ ボリュームバインディングモード：即時
８ ボリューム拡張許可：真
９ パラメータ：
１０ ｃｍａｄｄｒ：１９２.１６８.７０.１
１１ テスト＿パラメータ：これはテストである
表４：ｅｘｔｅｎｄｅｄ－ｓｔｏｒａｇｅ．ｙａｍｌ
【0071】
ｅｘｔｅｎｄｅｄ－ｓｔｏｒａｇｅ．ｙａｍｌファイルは、表４の例の場合、ストレージクラスの名前ｃｓｉ－ｔｅｓｔ－ｓｃ（行４）を含む拡張永続ボリューム要求の属性を提供する。拡張ＣＳＩドライバ４１７及び拡張ＣＳＩエージェント４２３は、それぞれが異なる特性を有する複数のタイプのストレージクラスをサポートすることがある。
【0072】
ｅｘｔｅｎｄｅｄ－ｓｔｏｒａｇｅ．ｙａｍｌファイルはまた、ストレージクラスのプロビジョナが拡張ＣＳＩドライバ４１７及び拡張ＣＳＩエージェント４２３へのリンクであるｅｘｔ．ｃｓｉ（行５）であることを指定する。言い換えると、拡張ＣＳＩドライバ４１７及び拡張ＣＳＩエージェント４２３に対応するプロビジョナを有する永続ストレージ要求へのデータアクセスは、拡張ＣＳＩドライバ４１７及び拡張ＣＳＩエージェント４２３、まとめて拡張ＣＳＩシステムに向けられる。
【0073】
ストレージクラスファイルはまた、ストレージクラスと関連付けられたパラメータの一部の属性を定義する（行９～１１）。ストレージクラスで提供されるこれらのパラメータは、ストレージクラスを使用してボリューム構成パラメータを提供するボリュームによって使用される。これらの構成パラメータは、鍵マネージャアドレス、セキュリティポリシー定義、暗号化鍵、認証トークンなどのいくつもの物である可能性がある。
【0074】
ＫｕｂｅｒｎｅｔｅｓＭＮシステム４１１が、プロビジョナが拡張ＣＳＩ（ＥＸＴ ＣＳＩ）のプロバイダであるストレージクラスの宣言を受信するとき、ＫｕｂｅｒｎｅｔｅｓＭＮシステム４１１は、ＥＸＴ ＣＳＩストレージクラスを登録する（ステップ５０７）。
【0075】
次に、名前空間管理者６０３は、以前に宣言された永続ボリューム要求に対して拡張永続ボリューム要求（Ｅ－ＰＶＣ）を作成する（ステップ５０９）。この要求は、コマンドラインツールｋｕｂｅｃｔｌでＹＡＭＬファイルを実行することによって作成されることもある。表５は、ｅｘｔ ｃｓｉシステムにより提供されるファイル階層化を、ステップ２０１'で定義された永続ボリュームに対してステップ２０３'で宣言された永続ボリューム要求のファイルシステム上に配置させる拡張永続ボリューム要求を作成するための例示的なＹＡＭＬファイルである。
【0076】
１ ａｐｉバージョン：ｖ１
２ 種類：永続ボリューム要求
３ メタデータ：
４ 名前：ｅｘｔＣＳＩ－ｃｌａｉｍ１
５ 注釈：
６ ｅｘｔポリシー：ポリシー＿１
７ スペック：
８ ストレージクラス名：ｃｓｉ－ｔｅｓｔ－ｓｃ
９ アクセスモード：
１０ －複数のノードから読み書き可
１１ リソース：
１２ リクエスト：
１３ ストレージ：１Ｇｉ
１４ データソース：
１５ 種類：永続ボリューム要求
１６ 名前：ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ
表５： ｅｘｔ－ｃｓｉ－ｃｌａｉｍ.ｙａｍｌ
２ 種類：永続ボリューム要求
３ メタデータ：
４ 名前：ｅｘｔＣＳＩ－ｃｌａｉｍ１
５ 注釈：
６ ｅｘｔポリシー：ポリシー＿１
７ スペック：
８ ストレージクラス名：ｃｓｉ－ｔｅｓｔ－ｓｃ
９ アクセスモード：
１０ －複数のノードから読み書き可
１１ リソース：
１２ リクエスト：
１３ ストレージ：１Ｇｉ
１４ データソース：
１５ 種類：永続ボリューム要求
１６ 名前：ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ
表５： ｅｘｔ－ｃｓｉ－ｃｌａｉｍ.ｙａｍｌ
【0077】
例えばアプリケーションポッド４０７の名前空間管理者６０３がコマンドラインツールｋｕｂｅｃｔｌを介して実行するこのｙａｍｌファイルは、ＥＸＴ ＣＳＩシステムのサービスを利用し、ステップ５０５でｅｘｔ－ｃｓｉストレージクラスとして設定されたストレージクラスｃｓｉ－ｔｅｓｔ－ｓｃ（行８）を使用して永続ボリューム要求を作成し、ひいてはｃｓｉ－ｔｅｓｔ－ｓｃストレージクラスのストレージ定義で与えられた規定を通じてＥＸＴ ＣＳＩシステムと関連付けられる。ストレージクラス名仕様は、（ストレージクラス宣言（ステップ５０１）で定義される）プロビジョナが永続ボリューム要求をＥＸＴ ＣＳＩシステムの範囲内に置くストレージクラスの名前に対応する名前を有する。
【0078】
作成された永続ボリューム要求は、名前（行４）、この例ではｅｘｔＣＳＩ－ｃｌａｉｍ１が与えられ、注釈（ｅｘｔポリシー）を使用して、作成された永続ボリューム要求と関連付けられることになるセキュリティポリシー、この例ではポリシー＿１を定義する（行６）。セキュリティポリシーには、暗号化、デジタル署名、アクセス制御、認証などが含まれることがある。セキュリティポリシーを指定するために注釈を使用することが、ある実施形態において、セキュリティポリシーを階層化ファイルシステムにどのように追加できるかの一例として提供されることに留意されたい。
【0079】
ＥＸＴ ＣＳＩ永続ボリューム要求を作成するｙａｍｌファイルはまた、ＥＸＴ ＣＳＩ永続ボリューム要求に対応するデータソースを定義する。ある意味で、既存の永続ボリューム要求に対してＥＸＴ ＣＳＩ永続ボリューム要求を作成する。本例では、これはデータソースフィールドを通じて定義され、この例では、データソースは、ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍという名前の永続ボリューム要求（行１６）である。注：これは、表２の永続ボリューム要求の名前である（ステップ２０３'）。したがって、ＥＸＴ ＣＳＩ永続ボリューム要求である新しい永続ボリューム要求は、以前に作成された永続ボリューム要求をそのデータソースとして使用する。
【0080】
ＥＸＴ ＣＳＩシステムに属するように定義されたストレージクラスの１つである（すなわち、ストレージクラスのプロビジョナはＥＸＴ ＣＳＩである（表４の行５））ストレージクラスを有する永続ボリューム要求を受信することに応答して、ＫｕｂｅｒｎｅｔｅｓＭＮシステム４１１は、ＥＸＴ ＣＳＩ永続ボリューム要求が作成されたこと及びその定義をＥＸＴ ＣＳＩドライバ４１７に通知する（ステップ５１１）。あらゆる永続ボリューム要求は永続ボリュームを必要とする。したがって、ＥＸＴ ＣＳＩドライバ４１７は、受信した永続ボリューム要求のストレージクラス（この例では、ｃｓｉ－ｔｅｓｔ－ｓｃ）を定義する構成ファイルと、ＥＸＴ ＣＳＩ永続ボリューム要求が最終的に戻って参照する基礎となる永続ボリューム、すなわち、この例ではｎｆｓ－ｆｒａｎｃｉｓｃｏという名前のステップ２０１’で定義された永続ボリュームとに基づいて、受信したＥＸＴ ＣＳＩ永続ボリューム要求に対応する新しい仮想永続ボリュームを提供する（ステップ５１３）。
【0081】
拡張永続ボリューム要求を使用するために、ＥＸＴ ＣＳＩシステムの拡張サービスを利用することになっているアプリケーションポッド４０７の名前空間管理者６０３は、ＥＸＴ ＣＳＩ永続ボリューム要求をアプリケーションポッド４０７の構成ファイルに追加する（ステップ５１５）。
【0082】
表６は、名前空間管理者６０３がどのようにしてＥＸＴ ＣＳＩ永続ボリューム要求をポッド構成に追加し得るかを示すＹＡＭＬファイルである。
【0083】
１ ａｐｉバージョン：ｖ１
２ 種類：ポッド
３ メタデータ：
４ 名前：ｅｘｔ－ｃｓｉ－ｄｅｍｏ
５ スペック：
６ ボリューム：
７ －名前：ｔｅｓｔ－ｖｏｌ
１０ 永続ボリューム要求：
１１ 要求名：ｅｘｔ－ｃｌａｉｍ１
１２ コンテナ：
１３ －名前：ｕｂｕｎｔｕ
１４ イメージ：ｕｂｕｎｔｕ
１５ ボリュームマウント：
１６ －マウントパス：“／データ”
１７ 名前：ｔｅｓｔ－ｖｏｌ
１８ コマンド：
１９ －“スリープ”
２０ －“６０４８００”
２１ イメージプルポリシー：ＩｆＮｏｔＰｒｅｓｅｎｔ
２２ 再起動ポリシー：常時
表６：ｅｘｔ－ｃｓｉ－ｄｅｍｏ－ｐｏｄ．ｙａｍｌ
２ 種類：ポッド
３ メタデータ：
４ 名前：ｅｘｔ－ｃｓｉ－ｄｅｍｏ
５ スペック：
６ ボリューム：
７ －名前：ｔｅｓｔ－ｖｏｌ
１０ 永続ボリューム要求：
１１ 要求名：ｅｘｔ－ｃｌａｉｍ１
１２ コンテナ：
１３ －名前：ｕｂｕｎｔｕ
１４ イメージ：ｕｂｕｎｔｕ
１５ ボリュームマウント：
１６ －マウントパス：“／データ”
１７ 名前：ｔｅｓｔ－ｖｏｌ
１８ コマンド：
１９ －“スリープ”
２０ －“６０４８００”
２１ イメージプルポリシー：ＩｆＮｏｔＰｒｅｓｅｎｔ
２２ 再起動ポリシー：常時
表６：ｅｘｔ－ｃｓｉ－ｄｅｍｏ－ｐｏｄ．ｙａｍｌ
【0084】
例えば、名前空間管理者６０３が作成するこのＹＡＭＬファイル（ｅｘｔ－ｃｓｉ－ｄｅｍｏ－ｐｏｄ．ｙａｍｌ）は、ＥＸＴ ＣＳＩシステムのサービスを利用することになるアプリケーションポッド４０７を構成する（ステップ５１５）。ポッド構成ファイル、例えばｅｘｔ－ｃｓｉ－ｄｅｍｏ－ｐｏｄ．ｙａｍｌでは、ポッドにはｅｘｔ－ｃｓｉ－ｄｅｍｏなどの名前が与えられる。
【0085】
構成ファイルは、要求名ｅｘｔ－ｃｌａｉｍ１（表６の行１１）を有する永続ボリューム要求として使用するボリュームを定義する。ｅｘｔ－ｃｌａｉｍ１永続ボリューム要求はステップ５０９で拡張ＣＳＩ永続ボリューム要求であると定義されているため、ポッドが展開されるとＥＸＴ ＣＳＩシステムが呼び出される。最終的に、これにより、ステップ５０１で定義された永続ボリュームの使用だけでなく、拡張ＣＳＩ永続ボリューム要求に対して定義されたセキュリティポリシー（ポリシー＿１（表５の行６））が適用される。
【0086】
したがって、要求名定義（行１１）は、ポッド４０７、ＥＸＴ ＣＳＩストレージ要求、元の永続ボリューム要求、及び元の永続ボリュームを結び付ける。
【0087】
拡張永続ボリューム要求を追加した後、名前空間管理者６０３は、コマンドラインツールｋｕｂｅｃｔｌを介して、アプリケーションポッド４０７を展開するように要求し（ステップ５１７）、ＫｕｂｅｒｎｅｔｅｓＭＮシステム４１１は、Ｋｕｂｅｒｎｅｔｅｓワーカノードシステム４１０にメッセージを送ることによってＫｕｂｅｒｎｅｔｅｓワーカノード４０３によるポッド展開をスケジュールする（ステップ５１８）。次いでＫｕｂｅｒｎｅｔｅｓＷＮシステム４１０は、アプリケーションを展開するのに必要なアクションを開始する（ステップ５１９）。
【0088】
ポッド構成ファイルは、マウントする必要があるボリュームを定義する（行１５～１７）。したがって、Ｋｕｂｅｒｎｅｔｅｓワーカノードシステム４１０は、ストレージクラスのオリジネータを決定し、そのストレージクラスと関連付けられたドライバにポッド構成内の任意のボリュームをマウントするように要求する（ステップ５２１）。ストレージクラスのドライバは図５に示されていない。
【0089】
ボリュームをマウントするメカニズムは、ボリュームのオリジネータの権限内にある。したがって、マウントが（表６の例のように）ＥＸＴ ＣＳＩボリュームのものである場合、ＫｕｂｅｒｎｅｔｅｓＷＮシステム４１０は、ＥＸＴ ＣＳＩエージェント４２３を呼び出してボリュームをマウントする。したがって、ＥＸＴ ＣＳＩエージェント４２３は、ＥＸＴ ＣＳＩシステムがファイルサービス、例えば、暗号化又はアクセス制御を提供するボリュームの１つへのマウント要求を受信する。
【0090】
表３のＹＡＭＬファイルｄｅｍｏ－ｐｏｄ．ｙａｍｌを表５のＹＡＭＬファイルｅｘｔ－ｃｓｉ－ｄｅｍｏ－ｐｏｄ.ｙａｍｌと対比する。前者では、ポッドはｎｆｓファイルストレージに直接アクセスする。後者では、ｎｆｓファイルストレージはＥＸＴ ＣＳＩシステム経由でアクセスされるため、ポッドは、ＥＸＴ ＣＳＩシステムがＥＸＴ永続ボリューム要求のポリシー宣言を通じてボリュームと関連付けるセキュリティポリシーを利用する。
【0091】
ＥＸＴ ＣＳＩシステムと関連付けられたストレージクラスの１つに属するボリュームへのマウント要求を受信することに応答して、ＥＸＴ ＣＳＩエージェント４２３はステージングポッドを作成する。すなわち、Ｋｕｂｅｒｎｅｔｅｓシステム内部構成ファイルをＫｕｂｅｒｎｅｔｅｓマスタノードシステム４１１に送信することによって、新しいポッドである拡張ＣＳＩ永続ボリューム要求に対応するステージングポッド６１３（ステージングポッド６１３は、ステップ５２３より前には存在しないため破線で示されている）のポッド定義を作成し（ステップ５２３）、次いでＫｕｂｅｒｎｅｔｅｓマスタノードシステム４１１は、ステージングポッド６１３の作成要求をＫｕｂｅｒｎｅｔｅｓワーカノードシステム４１０に通知する。Ｋｕｂｅｒｎｅｔｅｓワーカノードシステム４１０は、Ｅｘｔ ＣＳＩエージェント４２３により提供される構成に従ってステージングポッド６１３を展開する。
【0092】
ＥＸＴ ＣＳＩエージェント４２３は、ステージングポッド６１３が実行フェーズに入るのを待つ（ステップ５２４）。
【0093】
一方、システム内部構成ファイルであるステージングポッド６１３の構成ファイルは、ポッド構成ファイルと同様の構造を有し、検査のためにＹＡＭＬファイルにエクスポートされる可能性がある。表７は、ステージングポッド６１３の構成ファイルの内容を示すために提供されるエクスポートファイルの例である。
【0094】
１ 種類：ポッド
２ ａｐｉバージョン：ｖ１
３ メタデータ：
４ 名前：ｅｘｔ－ｓｔａｇｉｎｇ－ｐｏｄｈ６ｂｊ９
５ 名前生成：ｅｘｔ－ｓｔａｇｉｎｇ－ｐｏｄ
６ 名前空間：デフォルト
７ ｕｉｄ：８ａｂ１ｅｆ８ａ－ｄ８５ｆ－４ｆ０３－ｂ５４７
－４８ａｄｄ３７ｂ０４６ｃ
８ ラベル：
９ ｅｘｔ－ｃｓｉ：ｅｘｔ－ｓｔａｇｉｎｇ－ｐｏｄ
１０ ｅｘｔ－ｖｏｌｕｍｅ－１：ｂ１８０７２０９－ｃ９３２－１１ｅｂ
－ｂ４ａ１－７２ｆ２９５８３ｃ９７１
１１ セルフリンク：／ａｐｉ／ｖ１／ｎａｍｅｓｐａｃｅｓ／ｄｅｆａｕｌｔ／
ｐｏｄs／ｅｘｔ－ｓｔａｇｉｎｇ－ｐｏｄｈ６ｂｊ９
１２ スペック：
１３ ボリューム：
１４ －名前：ｅｘｔ－ｓｔａｇｉｎｇ－ｖｏｌｕｍｅ－１
１５ 永続ボリューム要求：
１６ 要求名：ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ
１７ －名前：ｄｅｆａｕｌｔ－ｔｏｋｅｎ－ｄｘｈ２ｄ
１８ シークレット：
１９ シークレット名：ｄｅｆａｕｌｔ－ｔｏｋｅｎ－ｄｘｈ２ｄ
２０ デフォルトモード：４２０
２１ コンテナ：
２２ －名前：ビジーボックス
２３ イメージ：ビジーボックス
２４ コマンド：
２５ －テール
２６ －‘－ｆ’
２７ －／ｄｅｖ／ｎｕｌｌ
２８ リソース：｛｝
２９ ボリュームマウント：
３０ －名前：ｅｘｔ－ｓｔａｇｉｎｇ－ｖｏｌｕｍｅ－１
３１ －マウントパス：／ｅｘｔ－ｓｔａｇｉｎｇ－ｖｏｌｕｍｅ－１
３２ －名前：ｄｅｆａｕｌｔ－ｔｏｋｅｎ－ｄｘｈ２ｄ
３３ 読み取り専用：真
３４ マウントパス：／ｖａｒ／ｒｕｎ／ｓｅｃｒｅｔｓ／
ｋｕｂｅｒｎｅｔｅｓ．ｉｏ／ｓｅｒｖｉｃｅａｃｃｏｕｎｔ
３５ イメージプルポリシー：ＩｆＮｏｔＰｒｅｓｅｎｔ
３６ 再起動ポリシー：常時
３７ 終了猶予時間（秒）：３０
３８ ノード名：ｕｂ２０－ｗｏｒｋ１
表７：ステージングポッド
２ ａｐｉバージョン：ｖ１
３ メタデータ：
４ 名前：ｅｘｔ－ｓｔａｇｉｎｇ－ｐｏｄｈ６ｂｊ９
５ 名前生成：ｅｘｔ－ｓｔａｇｉｎｇ－ｐｏｄ
６ 名前空間：デフォルト
７ ｕｉｄ：８ａｂ１ｅｆ８ａ－ｄ８５ｆ－４ｆ０３－ｂ５４７
－４８ａｄｄ３７ｂ０４６ｃ
８ ラベル：
９ ｅｘｔ－ｃｓｉ：ｅｘｔ－ｓｔａｇｉｎｇ－ｐｏｄ
１０ ｅｘｔ－ｖｏｌｕｍｅ－１：ｂ１８０７２０９－ｃ９３２－１１ｅｂ
－ｂ４ａ１－７２ｆ２９５８３ｃ９７１
１１ セルフリンク：／ａｐｉ／ｖ１／ｎａｍｅｓｐａｃｅｓ／ｄｅｆａｕｌｔ／
ｐｏｄs／ｅｘｔ－ｓｔａｇｉｎｇ－ｐｏｄｈ６ｂｊ９
１２ スペック：
１３ ボリューム：
１４ －名前：ｅｘｔ－ｓｔａｇｉｎｇ－ｖｏｌｕｍｅ－１
１５ 永続ボリューム要求：
１６ 要求名：ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ
１７ －名前：ｄｅｆａｕｌｔ－ｔｏｋｅｎ－ｄｘｈ２ｄ
１８ シークレット：
１９ シークレット名：ｄｅｆａｕｌｔ－ｔｏｋｅｎ－ｄｘｈ２ｄ
２０ デフォルトモード：４２０
２１ コンテナ：
２２ －名前：ビジーボックス
２３ イメージ：ビジーボックス
２４ コマンド：
２５ －テール
２６ －‘－ｆ’
２７ －／ｄｅｖ／ｎｕｌｌ
２８ リソース：｛｝
２９ ボリュームマウント：
３０ －名前：ｅｘｔ－ｓｔａｇｉｎｇ－ｖｏｌｕｍｅ－１
３１ －マウントパス：／ｅｘｔ－ｓｔａｇｉｎｇ－ｖｏｌｕｍｅ－１
３２ －名前：ｄｅｆａｕｌｔ－ｔｏｋｅｎ－ｄｘｈ２ｄ
３３ 読み取り専用：真
３４ マウントパス：／ｖａｒ／ｒｕｎ／ｓｅｃｒｅｔｓ／
ｋｕｂｅｒｎｅｔｅｓ．ｉｏ／ｓｅｒｖｉｃｅａｃｃｏｕｎｔ
３５ イメージプルポリシー：ＩｆＮｏｔＰｒｅｓｅｎｔ
３６ 再起動ポリシー：常時
３７ 終了猶予時間（秒）：３０
３８ ノード名：ｕｂ２０－ｗｏｒｋ１
表７：ステージングポッド
【0095】
図６は、図５のフローの結果を示す、図３に対応するブロック図である。ｅｘｔ－ｃｓｉ－ｄｅｍｏポッドの展開要求は、ポッド４０７のインスタンス化を引き起こしている。ポッド４０７は、マウント７０９（／データ）を含むコンテナ７０７を有する。Ｋｕｂｅｒｎｅｔｅｓシステムは、マウントが拡張ＣＳＩ永続ストレージのものであると認識したため、ＥＸＴ ＣＳＩエージェント４２３にメッセージを送って、ストレージクラスが関連付けられたボリュームのマウントを後者に警告した。Ｅｘｔ ＣＳＩエージェント４２３は、新しいポッドであるステージングポッド６１３を作成させた。
【0096】
ステージングポッドの永続ボリューム要求は、拡張永続ボリューム要求がリンクされている元の永続ボリューム要求（この例では、ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ）を指す（行１６）。
【0097】
全てのポッドと同様に、ステージングポッド６１３にはコンテナ、ここではステップ２０３'からの元の永続ボリューム要求を指すマウントパス（／ｅｘｔ－ｓｔａｇｉｎｇ－ｖｏｌｕｍｅ－１）有するステージングコンテナ７１３が含まれる。
【0098】
図６に示すような実施形態では、クラスタが多くのノードを有する可能性があるが、ステージングポッド６１３は、ＥＸＴ ＣＳＩエージェント４２３によってアプリケーションポッド４０７と同じワーカノード３０３に割り当てられる。
【0099】
ステージングポッドには、元の永続ボリューム要求に対するボリューム定義が含まれている。この例では、行１４～１６で、ボリューム名ｅｘｔ－ｓｔａｇｉｎｇ－ｖｏｌｕｍｅ－１が永続ボリューム要求ｎｆｓ－ｔｅｓｔ－ｃｌａｉｍ、すなわちＥＸＴ ＣＳＩシステムによって保護されることが求められる元の永続ボリューム要求上のボリュームであると定義される。
【0100】
ステージングポッドには、ボリュームｅｘｔ－ｓｔａｇｉｎｇ－ｖｏｌｕｍｅ－１上にボリュームマウントを有するコンテナ（この例では、ビジーボックス（行２２）と呼ばれる）も含まれている。したがって、ステージングポッドは、そのボリュームのドライバ、すなわち、この例ではｎｆｓドライバに、元のボリュームをマウントするように要求する（ステップ５２５）。
【0101】
ステージングポッド６１３が必要とする永続ボリュームがマウントされると、ステージングポッド６１３は実行フェーズに入り（ステップ５３５）、実行フェーズに入ったことをＫｕｂｅｒｎｅｔｅｓシステム４１１及び４１０に通知する。
【0102】
ステージングポッド６１３が実行されると、Ｋｕｂｅｒｎｅｔｅｓシステム（４１１及び４１０）は、ステージングポッドが実行されていることをＥｘｔ ＣＳＩエージェント４２３に通知する（ステップ５２６）。
【0103】
ＥＸＴ ＣＳＩエージェント４２３は、元の永続ボリューム要求のマウントを求めてノードを検索する（ステップ５２７）。ステージングポッド６１３が作成されると、ＥＸＴ ＣＳＩエージェント４２３は、クラスタ内に元のデータがホスト上のどこにあるかを示すパスを構築するのに十分なメタデータを有する。
【0104】
その取り組みにおいて、ＥＸＴ ＣＳＩエージェント４２３は、自由に利用できるいくつかの既知の静的情報を有している。
・Ｋｕｂｅｒｎｅｔｅｓノードポッドステージングディレクトリ（／ｖａｒ／ｌｉｂ／ｋｕｂｅｌｅｔ／ｐｏｄs／）
・クラスタから取得したメ
タデータフィールド：
・ポッドノード（例：ｕｂ２０－ｗｏｒｋ１）
・ポッドＵＩＤ（例：８ａｂ１ｅｆ８ａ－ｄ８５ｆ－４ｆ０３－ｂ５４７－４８ａｄｄ３７ｂ０４６ｃ）
・永続ボリューム名（例：ｎｆｓ－ｆｒａｎｃｉｓｃｏ）
・Ｋｕｂｅｒｎｅｔｅｓノードポッドステージングディレクトリ（／ｖａｒ／ｌｉｂ／ｋｕｂｅｌｅｔ／ｐｏｄs／）
・クラスタから取得したメ
タデータフィールド：
・ポッドノード（例：ｕｂ２０－ｗｏｒｋ１）
・ポッドＵＩＤ（例：８ａｂ１ｅｆ８ａ－ｄ８５ｆ－４ｆ０３－ｂ５４７－４８ａｄｄ３７ｂ０４６ｃ）
・永続ボリューム名（例：ｎｆｓ－ｆｒａｎｃｉｓｃｏ）
【0105】
まず、ＥＸＴ ＣＳＩエージェント４２３は初期検索パス、すなわち
・（Ｋｕｂｅｒｎｅｔｅｓノードポッドステージング）＋“／”＋（ポッドＵＩＤ）“／ｖｏｌｕｍｅs”
・例：／ｖａｒ／ｌｉｂ／ｋｕｂｅｌｅｔ／ｐｏｄs／８ａｂ１ｅｆ８ａ－ｄ８５ｆ－４ｆ０３－ｂ５４７－４８ａｄｄ３７ｂ０４６ｃ／ｖｏｌｕｍｅs
を生成する。
・（Ｋｕｂｅｒｎｅｔｅｓノードポッドステージング）＋“／”＋（ポッドＵＩＤ）“／ｖｏｌｕｍｅs”
・例：／ｖａｒ／ｌｉｂ／ｋｕｂｅｌｅｔ／ｐｏｄs／８ａｂ１ｅｆ８ａ－ｄ８５ｆ－４ｆ０３－ｂ５４７－４８ａｄｄ３７ｂ０４６ｃ／ｖｏｌｕｍｅs
を生成する。
【0106】
ステージングポッド６１３が作成されるノード上で、ＥＸＴ ＣＳＩエージェント４２３は検索パス上で永続ボリューム名（ｎｆｓ－ｆｒａｎｃｉｓｃｏ）を検索する。この例では、検索結果は
／ｖａｒ／ｌｉｂ／ｋｕｂｅｌｅｔ／ｐｏｄs／８ａｂ１ｅｆ８ａ－ｄ８５ｆ－４ｆ０３－ｂ５４７－４８ａｄｄ３７ｂ０４６ｃ／ｖｏｌｕｍｅs／ｋｕｂｅｒｎｅｔｅｓ．ｉｏ～ｎｆｓ／ｎｆｓ－ｆｒａｎｃｉｓｃｏ
となる。
／ｖａｒ／ｌｉｂ／ｋｕｂｅｌｅｔ／ｐｏｄs／８ａｂ１ｅｆ８ａ－ｄ８５ｆ－４ｆ０３－ｂ５４７－４８ａｄｄ３７ｂ０４６ｃ／ｖｏｌｕｍｅs／ｋｕｂｅｒｎｅｔｅｓ．ｉｏ～ｎｆｓ／ｎｆｓ－ｆｒａｎｃｉｓｃｏ
となる。
【0107】
このパスには、元の永続ボリューム要求に対応し、ＥＸＴ ＣＳＩシステムのファイルシステム階層化が適用されるマウントされたボリュームが含まれている。ＥＸＴ ＣＳＩエージェント４２３が実行する検索の結果、元の永続ボリューム要求のボリュームパスが得られ、ＥＸＴ ＣＳＩエージェント４２３は、そのパスを、ＥＸＴ ＣＳＩシステムのサービスがその上に階層化されるデータソースとして保存する。
【0108】
元のデータへのパスを用いて、ＥＸＴ ＣＳＩエージェント４２３は、元のＰＶＣマウントをデータソースとして使用して階層化ファイルシステムをマウントする（ステップ５２９）。層が、ファイルシステムに何らかの追加機能、例えば暗号化サービスを追加する。
【0109】
ステップ５２７で決定され、ステップ５２９でマウントされた拡張永続ボリューム要求と関連付けられたマウントは、ＥＸＴ ＣＳＩエージェント４２３によってアプリケーションポッドのコンテナに公開される（ステップ５３１）。
【0110】
図５のフローのこの時点で、ステージングポッド６１３とアプリケーションポッド４０７は両方とも実行中である（ステップ５３３）。
【0111】
上記の説明から、ファイルシステム能力の透過的な拡張、例えば、ファイルシステム階層化を、コンテナオーケストレーションシステム、例えば、Ｋｕｂｅｒｎｅｔｅｓと連携して提供するための効率的かつ安全なメカニズムが提供されることが明らかとなる。
【0112】
Ｋｕｂｅｒｎｅｔｅｓへの言及は一例である。本明細書で説明する技術は、変更すべきところは変更して、他のコンテナオーケストレーションシステムに適用可能である。
【0113】
本発明の特定の実施形態について説明及び図示したが、本発明は、そのように説明及び図示された部品の特定の形態又は配置に限定されるものではない。本発明は特許請求の範囲によってのみ限定される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図5a】
【図5b】
【図5c】
【図6】
【国際調査報告】