Kubernetesに初めて実装された「Container Storage Interface」は、Kubernetes、Mesos、Docker、Cloud Foundryが共同策定したコンテナ用ストレージAPI

2018年1月19日


先月リリースされたKubernetes 1.9には、Kubernetesからコンテナ用ストレージを制御するためのAPI「Container Storage Interface」(以下CSI)がアルファ版として初めて実装されました。

Container Storage Interfaceで実現すること

CSIは、Kubernetes、Mesos、Docker、Cloud Foundryなど、複数のコンテナ関連ツールのメンバーが協力して仕様を策定しているストレージAPIです。

つまりKubernetesだけでなく、こうしたコンテナ関連ツールはどれも同様のコンテナストレージAPIを備える必要に迫られているといえます。

仕様のドキュメントでは、CSIの目的はストレージベンダのプラグインをKubernetesやMesos、Cloud Foundryなどで使い回せることとされています。

To define an industry standard “Container Storage Interface” (CSI) that will enable storage vendors (SP) to develop a plugin once and have it work across a number of container orchestration (CO) systems.

業界標準の“Container Storage Interface”(CSI)の設定は、ストレージベンダーがプラグインを開発すれば、さまざまなコンテナオーケストレーションシステムで利用できることを実現するためである。

そしてCSIのAPI経由でできることは下記とされています。

これからのアプリケーション実行環境においてコンテナの重要性が高まってくる中で、その実行環境の重要な基盤である「コンテナオーケストレーションシステム」と呼ばれるKubernetesやMesos、Cloud Foundryなどで共通のストレージアクセスの枠組みを作る、というのがCSIの大きな役割だというわけです。

なぜオーケストレーションシステムでストレージAPIを持つのか?

しかしながら、例えばKubernetesが管理するコンテナのひとつひとつにはLinuxなどのOSが稼働しており、OSにはストレージへアクセスするAPIや成熟したドライバ群が備わっています。

なぜこうしたOSに備わっているストレージAPIではなく、KubernetesのようなコンテナオーケストレーションシステムがストレージにアクセスするAPIを持ち、それに対応した新たなドライバをストレージベンダは作ろうとしているのでしょうか?

それは、コンテナ対応のアプリケーションのライフサイクルが、コンテナ個々のライフサイクルと異なっているためと考えられます。

コンテナ対応のアプリケーションは、複数のコンテナから構成されるクラスタを実行環境とすることがほとんどでしょう。そうすると、その中のコンテナのいずれかが終了したとしても、それがアプリケーションの終了を意味しないため、コンテナ個々ではなくクラスタ単位でストレージの管理をするほうがアプリケーションとそれに対応したストレージの管理が容易になります。

ここに、アプリケーションのライフサイクルを管理しているKubernetes側でストレージの管理を行うべき理由がでてくるのです。

Kubernetes側でストレージを管理することにより、例えばクラスタを構成するコンテナ間でストレージを通じて情報を共有する、といったことも管理可能になります。

あるいは、あるコンテナが何らかの理由で停止し、それが再起動されて再びストレージと接続するときには、いったんKubernetes側で接続をクリーンな状態に戻してからコンテナにストレージボリュームを接続する、といったことができます。

そうした機能を実現するために、Kubernetesでストレージに対するAPIを持つことになったと考えられますし、そうしたニーズはKuberneteだけでなくMesosやCloud Foundryといったほかのオーケストレーションシステムでも同様であるために、協力して共通の仕様を策定していこう、ということになったのだと考えられます。

とはいえ、システム全体を俯瞰してみるとハイパーバイザもなんらかのストレージ管理機能を持っていますし、OSも当然持っていますし、そしてコンテナオーケストレーションシステムもストレージ管理機能を持つという状態になるわけです。

それぞれのレイヤにて適切な役割と機能があることは分かりますが、だんだんレイヤが増えて複雑さが増していくことからも、いずれレイヤ間をまたがって、なんらかの整理や統合が行われていくのかなあ、といったことを想像したくなります。

このエントリーをはてなブックマークに追加
follow us in feedly

カテゴリ Docker / コンテナ / 仮想化
タグ  Kubernetes


次の記事
マイクロソフト、Mac版Microsoft OfficeのソースコードをWindows版のソースコードと一本化実現

前の記事
AngularやReact、Vue.js対応の業務アプリ用UI「InputManJS」リリース。わずか600KBで昭和や平成、未発表の新元号対応。IME制御、ふりがな取得なども


カテゴリ



Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



新着記事 10本


PR - Books


fig

fig

fig