Persistent Volumesについて

### Persistent Volumesについて

#### 1. はじめに

Kubernetes (K8s) は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するオープンソースのコンテナオーケストレーションプラットフォームです。この記事では、K8sの中核となるストレージ概念であるPersistent Volumes (PV)とPersistent Volume Claims (PVC)の詳細について説明します。

#### 2. Persistent Volume (PV)とは？

- **PVの概念**:  
  PVはクラスタ内のストレージの一部を表すリソースです。このストレージは、外部のクラウドプロバイダからのストレージやローカルの物理的なディスクなど、さまざまなソースを持つことができます。

**PV設定例**:
```yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /path/to/my/data
    server: nfs-server.example.com
```

#### 3. Persistent Volume Claim (PVC)とは？

- **PVCの役割と動作**:  
  PVCはユーザーによってリクエストされるストレージの量やアクセスモードを表すリソースです。PVCはその要求を満たすための適切なPVを探してバインドします。

**PVC設定例**:
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
```

#### 4. ストレージの種類とPVの背後の技術

**ホストベースのボリューム: hostPath**:
```yaml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myfrontend
    image: nginx
    volumeMounts:
    - mountPath: "/var/www/html"
      name: mypd
  volumes:
  - name: mypd
    hostPath:
      path: /data/on/host
```

#### 5. プロビジョニング方法

**動的プロビジョニングの設定例 (StorageClass)**:
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
```

#### 6. StorageClassとその利用

**StorageClass設定例**:
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
```

#### 7. Container Storage Interface (CSI)の概要

CSIは、K8sとさまざまなストレージプロバイダーとの間の標準的なインターフェースを提供します。これにより、多様なストレージソリューションをK8sと統合することができます。

#### 8. PVコントローラーとPV/PVCのライフサイクル

#### PVコントローラーとは

PVコントローラーはKubernetesのコントロールプレーンの一部であり、PVとPVCのライフサイクルを監視・管理する役割を持っています。コントローラーは、特定のPVCが要求するリソースを満たすPVを自動的にバインドしたり、再クレームポリシーに従ってPVのリソースを再利用する等、多くの自動化タスクを担当します。

#### PVとPVCのライフサイクル

1. **プロビジョニング**:  
   ユーザーはPVCを作成することでストレージの要求を表明します。動的プロビジョニングの場合、PVCの要求に合ったPVがないと、新しいPVが自動的にプロビジョンされます。

2. **バインディング**:  
   PVCの要求がPVとマッチすると、PVコントローラーによってバインディングが行われます。これにより、PVCは特定のPVに紐づけられ、そのストレージ領域が専有されます。

3. **使用**:  
   PodはPVCを使用してそのストレージにアクセスし、データを読み書きします。この時、PodからはPVCの名前を指定するだけで、実際のストレージの詳細を気にすることなくデータを利用できます。

4. **解放**:  
   PVCオブジェクトが削除されると、そのPVCとバインドされていたPVは解放されます。この時、PVの再クレームポリシーに従って、その後のPVの扱いが決定されます（例：Retain, Delete, Recycle）。

5. **再クレーム**:  
   PVが再利用される場合、その再クレームポリシーに従って、PVのデータが保持されるか、削除されるか、または再利用のための初期化が行われるかが決定されます。

#### 9. まとめ

KubernetesのPVとPVCは、コンテナ化されたアプリケーションでの永続的なストレージニーズを満たすための強力な機能を提供しています。正しいストレージソリューションと管理アプローチを選択することで、アプリケーションは効率的にスケールし、データの永続性と可用性を保証することができます。

Container Storage Interface（CSI）は、コンテナオーケストレーションシステム（例：Kubernetes、Mesosなど）とストレージバックエンドとの間の標準化されたインターフェースを提供するためのイニシアティブです。これにより、ストレージプロバイダーは、異なるコンテナオーケストレーションシステムに対して単一のプラグインを書くことができます。

#### 10. おまけ
CSIの主な特徴と目的:

1. **プラットフォームの中立性**: CSIは、Kubernetesのようなコンテナオーケストレーションプラットフォームに依存せず、様々なシステムで動作するように設計されています。

2. **エンドツーエンドのボリュームライフサイクル**: CSIは、ボリュームのプロビジョニング、アタッチメント、マウント、そしてアンマウントなど、ストレージの完全なライフサイクルをサポートします。

3. **外部化**: CSIプラグインはコンテナオーケストレーションシステムの外部に存在し、それによってコアのオーケストレーションロジックからストレージのロジックを分離します。これにより、ストレージプロバイダはプラグインを更新することなく新しい機能を追加したり、バグを修正することができます。

4. **標準化**: CSIが目指すのは、ストレージのインターフェースの一貫性と標準化です。これにより、ストレージベンダーは異なるコンテナオーケストレーションプラットフォームに対応するための複数のプラグインを書く必要がなくなります。

CSIの主な操作:

1. **Identity Service**: プラグインの機能やバージョン情報を公開します。
2. **Controller Service**: ボリュームのプロビジョニングやアタッチメント、スナップショットの作成など、コントローラー固有の操作をサポートします。
3. **Node Service**: ボリュームのマウントやアンマウントなど、ノード固有の操作をサポートします。

CSIはこれまでのKubernetes内のエントリーストレージプラグインのアーキテクチャに変革をもたらしました。エントリープラグインはKubernetesのコードベースに直接組み込まれていたため、その更新やメンテナンスは複雑でした。CSIのアドプションにより、ストレージプロバイダは独立して、より迅速に、そしてより安全にプラグインを開発、リリース、および更新することができるようになりました。