Kubernetesによるコンテナストレージの管理：Kubernetesストレージの基礎【前編】

コンテナのストレージもKubernetesで管理することが一般化してきた。まずはKubernetesにおけるコンテナストレージの仕組みを基礎から解説する。

[Antony Adshead，Computer Weekly]

　コンテナアプリケーションは、「Kubernetes」などのコンテナオーケストレーションツールと併用するのが大きなトレンドになっている。

　コンテナアプリケーションはアプリケーション仮想化の一形態だ。コンテナは「従来の」仮想マシン（VM）と考え方は同じだが、コンテナの内部で独自の簡易版OSを稼働させる代わりにサーバOSを利用する。最も一般的なコンテナは「Docker」だが、他のコンテナも存在する。

関連記事

• GoogleのDocker管理ツール「Kubernetes」基礎の基礎
• DockerとKubernetesのさらに先へ拡大するコンテナエコシステム
• Kubernetes向けオープンソース管理ツールスイートSaaS登場
• 「Kubernetes as a Service」とは何か
• Kubernetesベースのディープラーニング環境「Nauta」

　コンテナにはアプリケーションの実行に必要なものが全て含まれる。そのため作成、稼働、複製、拡張を非常に迅速に行うことが可能で、その廃棄も簡単だ。こうしたことから、コンテナはニーズが突然増加するワークロードに適している。特にWebのワークロードがこれに当てはまる。こうしたワークロードに迅速に対応することを主な目的にするのが、Kubernetesの自動化機能だ。

会員登録（無料）が必要です

続きを読む

　コンテナは、本質的にステートレスだ。本稿ではコンテナのストレージの仕組みを解説する。ただし、本稿の大半で取り上げるのはKubernetesの永続ストレージについてだ。それは、Kubernetesがコンテナオーケストレーションのデフォルトプラットフォームになっているためだ。

　Kubernetesが扱うのは作成、管理、自動化、負荷分散、コンテナのハードウェア（ストレージなど）との関係といった機能だ。こうしたコンテナはKubernetesで言うところのポッド（Pod）に整理される。本稿では、1つ以上のコンテナの集合体をポッドと呼ぶ。

本質的に一時的、必要に応じて永続的

　Kubernetesのストレージは、原則として一時的（非永続的）なものだ。ストレージはコンテナに書き込まれ、ホストマシンの一時スクラッチ領域から作成される。ストレージはKubernetesポッドの有効期間内のみ存在する。ストレージはKubernetesの「emptyDir」コマンドで作成される。移植可能だが、永続的なものではない。

　Kubernetesは、永続ストレージもサポートする。オンプレミスやクラウドの広範な形式の永続ストレージに対応可能だ。ブロック、ファイル、オブジェクトストレージや、クラウドプロバイダーが提供するさまざまなクラスのストレージにも対応する。ストレージをデータベースなどのデータサービスにすることも可能だ。いずれにせよ、最終的にはどこかに存在する物理ストレージを利用することになる。

　ポッドの内部からストレージを直接参照することもできる。ただし、コンテナやポッドの移植性に違反するためこの参照方式は推奨されていない。代わりに、ストレージとアプリケーションの要件を定義するためにPV（PersistentVolume）とPVC（PersistentVolumeClaim）を使用する。

　PVとPVCは、ストレージの機能を実装から切り離し、ブロック、ファイル、オブジェクトストレージをポッドから移植可能な方法で使えるようにする。また、ユーザー／アプリケーションニーズとストレージ構成を切り離すのにも役立つ。

　PVは、管理者がストレージとそのパフォーマンスや容量といったパラメーターを定義する場所になる。つまり、管理者はPVを使って永続ストレージボリュームを定義する。パフォーマンス／コストのクラス、容量、使用するボリュームプラグイン、パス、IPアドレス、ユーザー名とパスワード、ボリューム使用後の処理など、PVにはそのストレージに関する詳細が含まれる。PVはKubernetesのクラスタ間では移植できない。

　一方、PVCはユーザーや開発者が自身のアプリケーションで必要なストレージを記述するために使われる。PVCは移植可能で、アプリケーションと共に移動する。Kubernetesは定義済みのPVから利用可能なストレージを見つけ出し、そのPVをPVCにバインドする。

　PVCはポッドのYAMLで定義されるため、その指定はポッドと共に移動する。PVCは、例えば容量とストレージの層を指定するだけのごくシンプルなものでも構わない。

　Kubernetesには、1つのPVCを共有するポッドの複数のクローンを作成してプロビジョニングするデプロイメントという方法がある。だが、これはクラッシュなどの問題を引き起こす恐れがある。その代替手段となるのが、ポッド間でPVCを複製するステートフルセットだ。

PVをグループ化するストレージクラス

　PVのコレクションは1つのストレージクラスにグループ化できる。ストレージクラスはKubernetesのAPIで、ストレージのパラメーターを設定する。これは動的なプロビジョニング手法で、新しいボリュームのオンデマンド作成を可能にする。

　ストレージクラスは、使用するボリュームプラグイン、（クラウドなどの）外部プロバイダー、CSI（Container Storage Interface）ドライバの名前を指定する。CSIは、コンテナからクラウドやストレージサプライヤーの製品の操作を可能にするドライバだ。

　よく使われるのが、1つのストレージクラスを「デフォルト」としてマークする方法だ。これにより、PVCを使ってPVを呼び出す必要がなくなる。つまり、ユーザーがPVCでストレージクラスを指定しなくてもそのPVが呼び出される。

　ストレージクラスは、コンテナアプリケーションがアクセスする必要が生じるかもしれない古いデータについても作成できる。

Kubernetesでストレージを扱うその他の方法

　Kubernetesでストレージを作成する方法は他にもある。だが、そうした方法は移植性の欠如などの問題を伴う。

　例えば、ホストパスがある。ホストパスはホストマシンのディレクトリを公開する。この方法は明らかに移植性がない。ポッドやコンテナが移動するとそのパスにはアクセスできなくなる。大半のポッドデプロイメントでは望まれないだろう。

　ブロック、ファイル、オブジェクトのいずれかのストレージを使ってローカル永続ストレージを作成することもできる。例えばこの手法を使ってKubernetesの上位に分散ストレージシステムを構築することは可能だ。実際、Rookはこの手法を用いて仮想コンテナストレージプールを作成する。

後編（Computer Weekly日本語版　5月7日号掲載予定）では、Rookに着目してそのメリット／デメリットなどを解説する。