Kubernetes 永続ストレージ管理に関する簡単な説明

1. はじめに

バージョン 1.0 以降、Kubernetes では、ストレージ プロビジョニングの独立した管理を実現するために、PersistentVolume と PersistentVolumeClaim という 2 つの新しい API リソースが導入されました。永続ボリューム (PV) は、クラスター内のストレージ リソースを抽象化したものです。永続ボリューム要求 (PVC) は、ユーザーによるストレージ リソースの要求です。 PV と PVC はユーザーのストレージ リソース要求の管理を実現していますが、管理者はユーザーへのストレージ提供を実装するために、さまざまなタイプの PV を手動で作成する必要があります。ストレージ リソースの動的なプロビジョニングを実現するために、Kubernetes ではバージョン 1.4 以降で StorageClass リソースが導入されています。バージョン 1.9 以降、Kubernetes では Container Storage Interface (CSI) が導入されました。これは、ストレージ ドライバー コードを Kubernetes のコア ライブラリから分離し、Kubernetes と外部ストレージの間に一連の標準ストレージ管理インターフェイスを導入することで、外部ストレージがインターフェイスをインスタンス化することでコンテナーにストレージ リソースを動的に提供できるようにします。この記事では、上記のリソース オブジェクトから始めて、Kubernetes のストレージ管理について簡単に説明し、コンテナ ストレージ管理における G の実践について簡単に説明します。

2. PVとPVC

1. PV

PV (PersistentVolume) はクラスター内のストレージ リソースであり、通常は管理者によって作成されるか、StorageClass によって自動的に作成されます。これらは通常のボリュームとは異なり、そのライフサイクルは Pod から独立しています。 PV には主に、ストレージ容量、アクセス モード、ストレージ タイプ、リサイクル ポリシー、バックエンド ストレージ タイプなどの重要な情報の説明が含まれます。次にPVを作成します。 YAML は次のとおりです。

この例では、PV の主な属性について簡単に説明しましょう。

• 容量: 指定されたストレージ デバイスのストレージ容量を示します。現在はストレージサイズの設定のみサポートされています。将来的にはIOPSやスループットなどもサポートされる可能性があります。
• VolumeMode: Kubernetes は、Filesystem (ファイル システム) と Block (ブロック デバイス) の 2 つのストレージ ボリューム モードをサポートしています。デフォルト値は Filesytem です。 VolumeMode が Filesystem として指定されている場合、Kubernetes はファイル システムを最初にマウントするときに初期化します。 VolumeMode が Block に指定されている場合、Pod に生のブロック デバイスとしてマウントされ、Pod とボリュームの間にファイル システム レイヤーは存在しません。
• AccessModes: ストレージ リソースに対するユーザーのアクセス権を記述します。 PV は、同時に 1 つのアクセス モードでのみマウントできることに注意してください。オプションのアクセス モードは次のとおりです。a. ReadWriteOnce (RWO): ボリュームは 1 つのノードによって読み取り/書き込みモードでマウントされ、同じノード上の複数のポッドからアクセスできます。 b. ReadOnlyMany (ROX): ボリュームは読み取り専用モードで複数のノードによってマウントできます。紀元前ReadWriteMany (RWX): ボリュームは複数のノードによって読み取り/書き込みモードでマウントできます。 d. ReadWriteOncePod (RWOP): ボリュームは、読み取り/書き込みモードで単一の Pod によってマウントできます。このモードには、CSI サポートと Kubernetes バージョン 1.22 以降が必要です。
• StorageClassName: 指定されたストレージ クラス (StorageClass)。同じ StorageClassName を持つ PV と PVC のみをバインドできます。 StorageClassName が設定されていない場合は、クラスターのデフォルトの StorageClass に設定されます。

2. PVC

PVC は、ストレージ リソースに対するユーザーのアプリケーションであり、主にストレージ スペース要求、アクセス モード、選択条件、ストレージ カテゴリなどの情報の説明が含まれます。クラスターは、PVC の説明に基づいて、バインドに一致する PV を選択します。次に、PVC を作成します。 YAML は次のとおりです。

この例では、PVC の主な特性について簡単に説明します。

• リソース: ストレージ サイズなどのストレージ リソースの要求を記述します (requests.storage)。
• VolumeMode: ストレージ ボリューム モード。設定は PV 設定と同じです。
• AccessModes: アクセス モード。設定は PV 設定と同じです。
• StorageClassName: ストレージ クラス名。システムが StorageClass を設定すると、システムは PVC に対応する PV を自動的に作成し、バインドします。
• セレクター: セレクター。 PVC はセレクタの内容に応じて条件を満たす PV をフィルタリングし、KV に一致する PV を選択してバインドします。

PVC は、上記の属性の説明に基づいて、バインドに一致する PV を選択します。 PVC は同じ名前空間内の PV のみを選択することに注意してください。同様に、Pod は同じ名前空間内の PVC のみをマウントできます。 PVC が適切な PV を選択した場合のみ、Pod によって正常にマウントできます。例は次のとおりです。

3. PVとPVCのライフサイクル

PV ライフサイクルのさまざまな段階:

• 利用可能: まだどの PVC にもバインドされていません。
• バインド済み: すでに PVC にバインドされています。
• 解放済み: バインドされた PVC は削除されましたが、リソースはクラスターによって再利用されていません。
• 失敗: ボリュームの自動リサイクル操作が失敗しました。

PV と PVC の関係は、以下の図 1 のライフサイクルに示されています。

図1

Kubernetes は、次の 2 つのストレージ リソース プロビジョニング モードを提供します。

静的モード: クラスター管理者はストレージ管理者に連絡して新しいストレージ ボリュームを手動で作成し、Kubernetes クラスター内にこれらのボリュームを表す PersistentVolume オブジェクトを作成し、最後にユーザーがバインド用の PVC を作成する必要があります。

動的モード: クラスター管理者は PV ボリュームを手動で作成する必要がありません。代わりに、StorageClass を構成してストレージ クラスを管理し、リソースを動的にプロビジョニングすることができます。ユーザーが PVC を申請するときに StorageClassName を指定すると、対応する StorageClass によって、対応するストレージ クラスのストレージ ボリュームと PV が Kubernetes クラスターに自動的に作成されます。 StorageClassName が "" として宣言されている場合、この PVC では動的モードが禁止されていることを意味します。

3. StorageClass と CSI

1. ストレージクラス

動的プロビジョニング モードは、主に StorageClass オブジェクトに基づいて実装されます。クラスター管理者は、異なるストレージ タイプごとに異なる StorageClasses を作成し、基盤となるストレージの詳細をユーザーから隠すことができます。 StorageClass に基づく動的ストレージ プロビジョニングは、徐々にクラウド プラットフォームの標準ストレージ構成モードになってきました。 StorageClass には主に、ストレージ プロバイダーと関連するストレージ パラメーターの構成が含まれます。 StorageClass は一度作成されると変更することはできず、削除して再作成することしかできません。次に例を示します。

この例では、Kubernetes.io/aws-ebs によって提供される standard というストレージ クラスを宣言します。

2. CSI

StorageClass は動的なストレージプロビジョニングの機能を提供しますが、呼び出すにはさまざまなバックエンド ストレージ プラグインのコードを Kubernetes のメイン コードに配置する必要があります。この緊密に結合された開発モデルは、膨大な保守コストと多くの問題を引き起こします。したがって、上記の考慮事項に基づいて、Kubernetes は Container Storage Interface 標準 (CSI) を立ち上げました。各ストレージ プロバイダーは独自のストレージ プラグイン コードを維持します。 CSI 標準に準拠していれば、Kubernetes はそれを Kubernetes のメインコードに結合せずに呼び出すことができます。 CSI ストレージ プラグインの標準実装は、次の 2 つの主要コンポーネントで構成されます。

コントローラー プラグイン: コントローラーは主にストレージ リソースとストレージ クラスを管理します。通常は単一のインスタンスとしてデプロイされ、任意のノードにデプロイできます。

Node プラグイン: 主に、ボリュームのマウントとアンマウントを含む、Node 上のストレージ ボリュームの管理と操作を実装します。通常は Daemonset としてデプロイされ、各ノードは Pod を実行します。

4. Gラインコンテナ保管管理実務

1. 背景

Bank G は、Cloud Platform 3.0 より前に集中型 NAS ストレージを導入しました。ユーザーが PV ボリュームを申請する必要がある場合は、まずストレージ管理者に申請する必要があります。次に、ストレージ管理者は、ユーザーのニーズに応じてストレージ側にストレージ ボリュームを作成します。次に、システム管理者はクラスター内に PV ボリュームを手動で作成し、リソースの配信を完了します。最後に、ユーザーはシステム内に PVC を作成し、リソース アプリケーションを完了します。このプロセスを以下の図 2 に示します。

図2

上記のプロセスの説明から、プロセス全体には多くの人間の介入が必要であり、自動化が欠けていることがわかります。 Kubernetes 自体は、リソースの動的な作成をサポートするために StorageClass を提供します。そこで、G 銀行は、既存の基盤に CSI ストレージ プラグインを導入し、ストレージ配信の自動化を実現することを検討しました。これらをベースに、高性能なローカルストレージや分散SANストレージが導入され、ストレージリソースの種類が拡大しました。

2. CSIの展開と実践

図3

CSI の展開プロセスを上の図 3 に示します。プロセスは比較的複雑です。 Kubernetes クラスターが作成されるたびに CSI プラグインを手動でデプロイする必要がある場合、システムの運用と保守のコストが間違いなく増加します。これを基に、G 銀行は標準化された APP 配信フレームワークを導入し、Kubernetes クラスターの作成操作と CSI プラグインの展開を統合し、Kubernetes クラスターのワンクリック作成と標準化された配信を実現しました。クラスターが作成されると、対応する CSI プラグインと StorageClass が自動的にデプロイされ、直接使用できるようになります。

ユーザーが必要とする StorageClass がクラスターにデプロイされました。ストレージ リソースを申請するには、PVC を直接作成するだけです。例は次のとおりです。

新しく作成された PVC のステータスは保留中です。

CSI コントローラーは kube-apiserver を監視し、独自の StorageClass プロビジョナーの PVC の変更を検出します。 PVC の作成を感知すると、自動的にストレージ側に移動し、ストレージ ボリュームを作成します。ストレージ ボリュームが作成されると、コントローラーはクラスター内に PV を自動的に作成します。

図4

プロセス全体が完了すると、クラスターで PV が正常に作成され、PVC のステータスが「バインド済み」に変わったことを確認できます。

図 4 の上記のプロセスからわかるように、ユーザーがストレージ リソースを申請するプロセス全体を通じて、ストレージ管理者とクラスタ管理者による手動介入なしに、ストレージ リソースが自動的に配信されます。

3. CSIを使用して動的拡張をサポートする

Cloud Platform 3.0 では、Bank G は高性能なローカル ストレージと分散 SAN ストレージを導入しました。これら 2 種類のストレージは、ストレージ層での KVM 動的拡張テクノロジに基づいて、バックエンド ストレージ ボリュームの動的な拡張を実現できます。コンテナプラットフォームでは、G銀行は対応するCSIコントローラをアップグレードおよび最適化し、EXPAND_VOLUME機能を実装して、ユーザーの容量拡張ニーズに応えました。 CSI コントローラは、対応する変更を監視すると、ストレージ バックエンド インターフェイスを呼び出して対応するストレージ ボリュームと PV ボリュームを拡張し、対応する設定に従ってファイル システムを調整します。

まず、ストレージ プラグインをデプロイするときに、動的拡張を有効にするために StorageClass の allowVolumeExpansion フィールドを True に設定する必要があります。 StorageClass の構成例は次のとおりです。

稼働中のビジネスで、ユーザーに容量拡張の要件がある場合、ユーザーが使用している PV ボリュームをアンインストールする必要はありません。ユーザーは PVC の要求サイズを直接変更できます。 CSI コントローラは、対応するストレージ ボリュームと PV ボリュームを拡張するために、すぐにストレージ バックエンド インターフェイスを呼び出そうとします。容量拡張要求を受信すると、バックエンドストレージは virsh blockresize コマンドを呼び出してストレージボリュームのサイズを調整し、処理結果を CSI コントローラーに返します。 CSI コントローラは、ストレージ ボリュームが拡張されたことを確認した後、現在のストレージ ボリュームがマウントされているノードを見つけ、対応するノード上の CSI デーモンセットに拡張ボリュームのサイズを変更し、拡張された容量をファイル システムに拡張するように要求します。この時点で、ユーザーの動的な拡張のニーズは満たされています。拡張プロセス全体を通じて、ユーザーは業務を中断する必要がなく、ビジネスの継続性と安定性が保証されます。

4. 複数の CSI を並列に実行する

Bank Gは、Cloud Platform 3.0において、集中型NASストレージ、高性能ローカルストレージ、分散型SANストレージをサポートしており、これら3種類のストレージのパフォーマンステストを実施しました。テスト結果に基づいて、対応するユーザーの使用シナリオを整理しました。テストデータの一部は次のとおりです（テストデータは参考用です）。

集中型 NAS ストレージ: ファイル ストレージであるため、読み取りおよび書き込みのパフォーマンスはブロック ストレージよりも低くなります。ファイルシステムのマルチノード読み取りと書き込みをネイティブにサポートしており、ファイル共有を必要とするユーザーに適しています。

分散 SAN ストレージ: 優れた読み取りおよび書き込みパフォーマンスを備えた分散ブロック ストレージ。ストレージ モードがファイル システムの場合、マルチノードの読み取りと書き込みはサポートされません。ストレージ パフォーマンスに対する要件が高く、共有ストレージを必要としないユーザーに適しています。

高性能ローカル ストレージ: 優れた読み取りおよび書き込みパフォーマンスを備えたローカル ブロック ストレージ。また、ファイルシステム ストレージ モードでは、マルチノードの読み取りと書き込みもサポートされません。単一のストレージボリューム容量が 300G 未満で、共有ストレージが不要で、ストレージパフォーマンスに対する要件が高いユーザーに適しています。

V. 結論

Kubernetes は、PV、PVC、StorageClass、CSI 標準を通じて完全なストレージ管理メカニズムを構築しました。 G銀行はKubernetesリソースオブジェクトを最大限に活用し、銀行の現状に基づいて複数のストレージタイプと対応するCSIストレージプラグインを導入し、複数のCSIの並列化とコンテナストレージの自動管理を実現しました。ストレージ管理者とシステム管理者は、ストレージ ボリュームと PV ボリュームを手動で作成する必要がなくなりました。プロジェクト作成の開始時に、異なるストレージ クラスのプロジェクトにストレージ クォータを割り当てるだけで済みます。必要に応じて、ユーザーは直接 PVC を作成できます。 CSI コントローラは、ユーザーの PVC パラメータに基づいてストレージ インターフェイスを呼び出して、ストレージ ボリュームと PV ボリュームを自動的に作成し、ユーザーがすぐに適用して使用できるようにします。ユーザーが容量拡張のニーズを抱えている場合、既存の CSI コントローラは、管理者による手動調整を必要とせずに PV ボリュームの動的な拡張もサポートできます。静的な配信管理モデルと比較すると、クラスター管理者はストレージを事前に構成する必要がないため、人件費が削減されるだけでなく、配信効率とビジネス継続性も向上します。同時に、複数のストレージ クラスの導入により、さまざまな使用シナリオにおけるユーザーのニーズも満たされます。