Kubernetes の永続ストレージと CSI__HTMLTAG_66___
コンテナは一時的です。コンテナが再起動されるか、ポッドが別のノードで再スケジュールされると、内部のデータはすべて失われます。これは、データベース、メッセージ キュー、ファイル ストレージなどのステートフル ワークロードに関する深刻な問題です。 Kubernetes は、豊富なストレージ システムを使用してこの問題を解決します。Kubernetes 1.30 ～ 1.31 からは、ツリー内ストレージ プラグインが完全に削除され、__HTMLTAG_68___Container Storage Interface (CSI) 標準ドライバーに置き換えられました。
ストレージのライフサイクル: 一時的なものから永続的なものへ__HTMLTAG_72___
emptyDir: 一時ストレージ
emptyDir は、ポッドの作成時に空のディレクトリを作成し、ポッドの存続期間中保持されます。ポッドを削除すると、データは完全に失われます。キャッシュ、一時ファイル、同じポッド内のコンテナ間でのデータ共有に適しています。
コードブロック_0
hostPath: ノードローカルストレージ
hostPath は、ホスト ノード上のパスをコンテナにマウントします。データはコンテナの再起動時には存在しますが、Pod が別のノードにスケジュールされると失われます。 特別な理由 (システム デーモン、監視エージェント) がない限り、運用環境では使用しないでください。
コードブロック_1
Persistent Volume と Persistent VolumeClaim
コアコンセプト
Kubernetes は、
という 2 つの抽象化を通じて、__HTMLTAG_92___ストレージの提供 (管理者) と__HTMLTAG_94___ストレージの使用 (開発者) を分離します。- Persistent Volume (PV): 管理者によって作成された、または動的にプロビジョニングされたクラスターレベルのストレージ リソース。実際のストレージ (NFS 共有、クラウド ディスクなど) を表します
- Persistent VolumeClaim (PVC): ストレージに対するユーザーのリクエスト。開発者は、ストレージの場所を知らなくても、「ReadWriteOnce で 10Gi のストレージが必要です」と宣言するだけで済みます。
永続ボリューム定義
コードブロック_2
PersistentVolumeClaim
コードブロック_3
コードブロック_4
ポッドでの PVC の使用
コードブロック_5
アクセス モード_
Kubernetes は 4 つのアクセス モードを定義し、ボリュームをマウントする方法を示します:
- _ReadWriteOnce (RWO): 読み取り/書き込みをマウントできるノード。ブロック ストレージ (EBS、GCE PD) で最も一般的です。 K8s 1.22 以降、RWO は同じ読み取り/書き込みノード上で複数の Pod を許可します。
- ReadOnlyMany (ROX): 複数のノードが同時に読み取り専用でマウントできます。共有設定/データと一致します。
- _ReadWriteMany (RWX): 多くのノードが読み取り/書き込みをマウントします。 NFS、CephFS、Azure Files などのネットワーク ファイル システムが必要です。重要: ブロック ストレージ (EBS、GCE PD) は RWX をサポートしません。
- ReadWriteOncePod (RWOP): クラスター全体で 1 つのポッドのみをマウントできます。 RWO よりも強力 — ノード レベルだけでなく、ポッド レベルでの排他的アクセスを保証します。 CSI ドライバーのサポートが必要です。
ストレージクラス: 動的プロビジョニング
_StorageClass を使用する理由_
管理者が手動で PV を作成する代わりに、StorageClass を使用すると 動的プロビジョニング — PVC リクエストがあると Kubernetes が自動的に PV を作成します。管理者は、ストレージの「クラス」を定義するだけで済みます (例: ssd-fast、hdd-cheap、nfs-shared)。
コードブロック_6
回収ポリシー
- 削除: PVC が削除されると、PV と基盤となるストレージも削除されます。デフォルトでは動的プロビジョニングが使用されます。一時的なワークロードに適しています。
- _Retain: PVC が削除されると、PV は保持されます (解放状態)。管理者は手動で再利用する必要があります。データ保護が必要な運用データベースに適しています。
- リサイクル: 非推奨のため、推奨されません。
CSI: コンテナ ストレージ インターフェイス
ツリー内プラグインはなぜ削除されたのですか?
_以前、Kubernetes には、コア Kubernetes バイナリ (aws-ebs、gce-pd、azure-disk、cephfs、nfs など) に直接コンパイルされた多くのツリー内ストレージ プラグインがありました。これにより多くの問題が発生します:
- ストレージ プラグインのバグにより、kube-apiserver/kubelet 全体がクラッシュする可能性があります
- Kubernetes リリースに関連するストレージ ドライバーのリリース サイクル
- プラグインの数が増えるとメンテナンスが困難
- ストレージ ベンダーは個別に修正を出荷できません
CSI (コンテナ ストレージ インターフェイス) は、Kubernetes とストレージ プロバイダー間のインターフェイスを標準化することで、これらの問題をすべて解決します。ドライバーは個別のポッドとして実行され、個別に更新できます。
タイムラインのツリー内プラグインの削除__HTMLTAG_180___
- K8s 1.26-1.28: 多くのツリー内プラグインが非推奨になりました
- _K8s 1.29: ツリー内 NFS と多くのプラグインは非推奨に変換され、CSI が必要
- _K8s 1.30: ツリー内 NFS プラグインが削除されました
- K8s 1.31: ツリー内 CephFS、Ceph RBD プラグインが完全に削除__HTMLTAG_197___
- _K8s 1.32+: 残りのツリー内プラグインの削除を続行
人気の CSI ドライバー
クラウド プロバイダー
コードブロック_7
Longhorn: オープンソースの分散ストレージ__HTMLTAG_208___
コードブロック_8
コードブロック_9
Rook/Ceph: エンタープライズ ストレージ
コードブロック_10
ボリューム スナップショット
コンセプト__HTMLTAG_214___
ボリューム スナップショットは、PVC のポイントインタイム スナップショットを作成できる K8s 1.20 の GA 機能です。スナップショット機能をサポートする CSI ドライバーとスナップショット コントローラーがインストールされている必要があります。
スナップショット コントローラーをインストール
コードブロック_11
ボリュームスナップショットクラス
コードブロック_12
ボリュームスナップショットの作成
コードブロック_13
コードブロック_14
スナップショットから復元
コードブロック_15
コードブロック_16
VolumeAttributesClass (K8s 1.29+)
古いアプローチの問題
以前は、ボリュームの IOPS またはスループットを変更する場合 (たとえば、gp3 3000 IOPS から 10000 IOPS に)、PVC を削除し、新しい StorageClass を作成し、新しい PVC を作成する必要がありました。これは複雑でダウンタイムを引き起こすプロセスです。
VolumeAttributesClass (VAC) は、PVC を削除せずに IOPS やスループットなどの変更可能なボリューム属性を変更できる新しい API (Beta K8s 1.31) です。
コードブロック_17
コードブロック_18
コードブロック_19
概要
_Kubernetes のストレージは大幅に成熟し、K8s 1.30 ～ 1.31 以降、CSI が必須のプラットフォームになりました。注意すべき点:
- emptyDir (ポッド内の一時的な共有ストレージの場合)、__HTMLTAG_243___PVC/PV (永続データの場合)__HTMLTAG_245___
- CSI が必要: K8s 1.30 以降からはツリー内プラグインではなくなりました。CSI ドライバーに移行する必要があります
- StorageClass と動的プロビジョニングが標準的な方法です。管理者がクラスを定義し、開発者は を要求するだけです。
- Longhorn は、分散複製ストレージを備えたオンプレミス クラスターに適しています
- _ボリューム スナップショット はポイントインタイムのバックアップ/復元を可能にし、CSI ドライバーとスナップショット コントローラーが必要
- VolumeAttributesClass (K8s 1.29+ ベータ版) では、PVC をクリアせずに IOPS/スループットを変更できます。
- クロス AZ アタッチメントの問題を避けるために、クラウド ボリュームでは__HTMLTAG_267___WaitForFirstConsumer バインディング モードを常に使用してください