2019.10.16

Kubernetesで初めてのアプリを作ろう」パート5: ストレージのプロビジョニング #docker #kubernetes #k8s

この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。

Kubernetesについてのこのブログ記事シリーズで、これまでにご紹介したことは:

本シリーズの締めくくりとなる今回は、Kubernetesアプリケーションにストレージをプロビジョニングする方法をご紹介します。

ステップ4: ストレージのプロビジョニング

Kubernetes向けのアプリケーションを構築する際に私たちが考慮したいコンポーネントの最後は、ストレージです。コンテナのファイルシステムは一時的なものだということを思い出してください。つまりそこに保存されているデータは、そのコンテナが終了または再スケジュールされると、コンテナとともに削除されるリスクを伴っています。コンテナの短いライフサイクルを越えてデータの存続を確実にするためには、外部ストレージにデータを書き出さなければなりません。

価値あるデータを生成または収集するコンテナはすべて、安定した外部のストレージにデータをプッシュするべきです。私たちのウェブアプリの例では、データベース層はディスク上のコンテンツを外部ストレージにプッシュしています。これによりデータベースPodの壊滅的な障害の際にもデータは存続できます。

同様に大量のデータのプロビジョニングが必要なすべてのコンテナは、外部ストレージからそのデータを取得しましょう。外部ストレージを活用して、ステートフルな情報をコンテナ外にプッシュするすることも可能です。これによりコンテナ自体はステートレスになり、スケジューリングやルーティングが容易になります。

判断ポイントその5: あなたのアプリケーションが収集または使用するデータのうち、Podのライフサイクルを越えて存続すべきデータはどれか？

Kubernetesのストレージモデルは、多くの部品によって成り立っています:

Container Storage Interface (CSI)プラグイン

これは外部ストレージへのドライバとして考えることができます。

StorageClass

このオブジェクトはCSIドライバを使い、メタデータを追加します。一般的に、ストレージがバックエンドでどのように扱われるかを設定します。

PersistentVolume (PV)

このオブジェクトは、StorageClassによってパラメータ化された実際のストレージバケットを表現します。

PersistentVolumeClaim (PVC)

このオブジェクトは、PodがPersistentVolumeを自身にプロビジョニングするよう要求できるようにします。

Volume

最後に、このシリーズですでに触れたVolumeが登場します。ストレージの場合では、PVが取り扱い、PVCによって要求される外部ストレージの内容によって、Volumeを形成できます。そしてVolumeをPodにプロビジョニングし、最後にPod内のコンテナにそのコンテンツをマウントできます。

開発中にこれらすべてのコンポーネントを管理することは大変です。しかし設定について見てきた通り、KubernetesのVolumeは、外部ストレージをコンテナ内のどこにどのようにマウントするかを定義する、便利な抽象レイヤーを提供しています。これらは、私がKubernetesにおける「ストレージフロントエンド」として考えたいもののとっかかりとなります。これらはあなたのPodに最も密接に統合されているコンポーネントであり、環境によって変更されないものです。

CSIドライバからPVCに至るまでの他のすべてのコンポーネントは「ストレージバックエンド」として考えたいと思います。これらは、環境間を移動する際にコードやコンテナ、またはそれらをデプロイするController定義に影響を及ぼさずに、切り取ったり置き換えたりすることが可能なコンポーネントです。

単一ノードのクラスタ（例えば、あなたの開発用マシン上にDocker Desktopで作成したクラスタ）上で、ホストパスのバックエンドでPVを作成することができることに注目しましょう。これはCSIプラグインや特別なStorageClassを設定せずに、ローカルディスクから永続ストレージをプロビジョニングします。これが、前述の図のような泥沼に陥らずにアプリケーション開発を始められる簡単な方法です。つまり、あなたの開発用マシンからより大きなクラスタへアプリケーションを移行する準備が整うまで、CSIプラグインとStorageClassに関する判断と設定を効果的に先延ばしすることができます。

高度なトピックス

前述したシンプルなホストパスPVは、初期開発やPoCに適しています。しかし本番環境に移行する前に、より強力なストレージソリューションに置き換える必要があります。これには、Kubernetesのストレージソリューションの「バックエンド」、すなわちStorageClassとCSIプラグインを調べましょう:

今後の抱負

本シリーズでは、多岐にわたるアプリケーションのコンテナ化に際して必要となる基本のKubernetesの機能を紹介しました。また次の段階として、より高度な情報を得るために参照すべき場所もご紹介しました。実際にワークロードのコンテナ化、それらのネットワーキング、設定のモジュール化、ストレージでのプロビジョニングを行って、今回紹介した項目に習熟してください。

Kubernetesは、これら4分野すべてに対するパワフルなソリューションを提供しています。そしてよく構築されたアプリはこの4分野すべてをうまく活用しているはずです。これらをどのように運用可能とするかのガイダンスや技術的な詳細が必要な場合は、Docker
Trainingチームが提供するワークショップ（訳注:日本語版トレーニングはこちらを参照ください）を見てみてください。新しいトレーニングコンテンツを定期的に公開しています。

Kubernetesアプリケーション構築の基本をマスターしたら、 「このアプリケーションは基本的な可搬性・拡張性・共有性の価値をどれだけ満たしているか？」 と自問自答してください。コンテナはクラスタ間やユーザ間を簡単に行き来できるものとして開発された技術ですが、あなたが構築したアプリケーション全体も同様でしょうか？アプリケーションの一貫性を保ちつつ、実行予定のいかなるユニットテストも統合テストも無効化せずに、アプリケーションをさまざまに移動するには、どうすればよいでしょうか？

Docker Appは、1つのイメージを移動させるのと同じくらい簡単に移動できる、統合バンドル内にアプリケーションをパッケージングすることで、この課題を解決する取り組みに乗り出しました。Kubernetesアプリケーションをシームレスに共有できる、この新たな形式についての詳細は、今後ブログ記事とDockerトレーニングで紹介して参ります。

Kubernetesストレージと、Kubernetes全般についてもっと学ぶには: