Kubernetesのデータ永続化入門

2019.12.06

コンテナのデータ永続化

Kubernetesでは簡単にコンテナとしてワークロードを作成・削除できるのがメリットです。一方でステートフルなアプリケーションを利用する場合には、データの扱いについて配慮が必要です。Kubernetesによって作成されたPodはPod内に読み書き可能なディスク領域を持ちますが、Podを削除するとこのディスク領域も削除されます。データベースやログ収集などを行うようなPodはPodの削除と同時にディスクが削除されてしまうと都合が悪いため、データの永続化が必要となります。Podにおけるデータ永続化とは、Podを削除した後にもデータを保持し続ける仕組みのことです。

では、そもそも Pod におけるデータの永続化にはどのような手法があるのでしょうか? Kubernetes上のPodは以下の３つの方法でデータをディスクに書き込むことが可能です。これらの関係を図1に示します。

Pod内で一時的に利用可能なディスク領域を使用する方法です。Podを削除すると保存されていたデータも一緒に削除されるため、データの永続化はできません。
Podを動かしているKubernetes Nodeのディスク領域をPodにマウントする方法です。Podを削除してもデータはNodeに残るため、データの永続化が可能です。しかし、 Pod が別ノードで動作した場合にはデータの再利用ができないデメリットが存在します。
コンテナを動かしているKubernetes Nodeとは別にiSCSIやNFS、クラウドプロバイダーの外部ストレージを利用する方法です。Podを削除してもデータは外部ストレージに残るため、データの永続化が可能です。また、Pod が別ノードで動作したとしてもデータが外部に存在するためデータの再利用が可能です。

図1. KubernetesのPodとボリュームの関係

Kubernetes上のPodは以下の４種類のKubernetesリソースにより、外部ストレージの利用が可能です。これらの関係を図2に示します。

Volume
Persistent Volume (PV)
Persistent Volume Claim (PVC)
Storage Class (SC)

図2. PV, PVC, SCと外部ストレージの関係

まず、Volumeの機能として、あらかじめ用意したボリュームをPodから利用することが可能です。そのため、Developerは外部ストレージを指定することでPodに永続的なボリュームを接続することができます。しかし、ボリュームの作成/削除といった操作はAdministratorが行う必要があります。ここで述べるDeveloperとは、Podを作成・利用するアプリケーション開発者などを対象とし、AdministratorはKubernetesクラスター管理者、インフラ管理者を対象としています。具体的に利用可能なボリュームは、NFSやiSCSI、Cephなどが挙げられます[1]。Volumeを利用するにはPod作成時にストレージサービスのボリューム名などの情報を直接設定しなければなりません。そのため、Podとストレージが密結合となってしまい、コンテナならではの可搬性が損なわれ、環境依存となってしまうといった問題が生じます。

この問題に対して、Persistent Volume(PV)、Persistent Volume Claim(PVC)を用いることでPodとストレージの関連付けを抽象化して疎結合な運用が可能となります[2]。PVは外部のボリュームを抽象化するリソースです。あらかじめ作成しておいた外部ストレージのボリュームをKubernetes上にPVリソースとして登録することで、Podから利用することが可能になります。PVにはボリュームサイズやアクセスモードを指定することができます。PVCはコンテナが利用するボリューム要件を指定する仕組みです。ボリューム要件にはボリュームのサイズやアクセスモードを指定します。Podデプロイ時にPVCを指定することで、要件に合うPVをPodから利用することが可能になります。

PVとPVCを用いることで、DeveloperとAdministratorの役割を分離することが可能になりますが、PVは事前に用意する必要があるため、新たなワークロード作成時にはAdministratorが作成しなければなりません。

この問題に対して、PVを動的に管理する仕組みとしてDynamic Volume Provisioningを利用することができます。Dynamic Volume ProvisioningはStorage Class（SC）を介して、PVCで指定された要件に応じてバックエンドにあるストレージシステムからボリュームを自動的にプロビジョニングする仕組みです[3]。SCのprovisionerとして適切なドライバを指定することでAWS EBS、Azure Disk, vSphere VMDK等を対象にボリュームの動的作成・割り当てを行うことが可能です。

このように Kubernetes ではステートフルなアプリケーションもコンテナとして動作させるためにデータの永続化・抽象化が進められてきています。

Container Storage Interface

ここまで Kubernetesの標準ストレージ機能について説明しましたが、CNCFで注目されているContainer Storage Interface（CSI）について紹介します[4]。CSIは、Kubernetesに限らずコンテナオーケストレーションツールとストレージプロバイダ間をつなぐ標準インターフェースの仕様です。Kubernetesでは、v1.13でCSIがGeneral Availability（GA）とされており現在も開発が進められています[5]。

CSI登場以前は、コンテナオーケストレータとストレージ間のインターフェースが標準化されていなかったため、ストレージベンダーとKubernetesの開発者の双方で問題を抱えていました。ストレージベンダーは、「コンテナオーケストレータのアーキテクチャを理解し、自社プロダクトに対応させる必要がある」、Kubernetesの開発者は、「ストレージベンダーが提供するプラグインのテストとメンテナンスを担当しなければならない」といった問題が挙げられます。これは、プラグインのバグだけでなく、重要なKubernetesのコンポーネントまで問題を引き起こす可能性がありました。

そこで、このような問題に対応すべく、CSIが策定されました。ストレージベンダーは、この標準インターフェースの仕様に沿って開発することにより、CSIに対応したコンテナオーケストレータで自社のストレージを利用することが可能になります。また、Kubernetesの開発者は、テスト、メンテナンスの対応が減り結果としてシステムの安全性や信頼性が高まります。過去に紹介した、Cisco Container Platform (CCP)、Red Hat OpenShift Container Platform、VMware Enterprise PKSはCSIに対応しており、NetAppやDellEMC、PureStorageなどのオンプレミス向けストレージベンダーはCSI向けのDriverを提供しています。また、パブリッククラウドプロバイダーが提供するストレージサービスやオープンソースのストレージソフトウエアに対応するDriverも数多く提供されています。前述のStorage Classにおけるprovisionerの多くは現在CSIに対応したDriverにより実装され、さまざまなストレージ機能が利用可能です。