KubernetesにおけるPVとPVCを使用した永続ストレージの管理

コンテナ化されたアプリケーションがますます人気を集めるにつれて、これらの一時的な環境での永続ストレージの管理は重要な課題となっています。Kubernetesは、永続ボリューム（PV）と永続ボリュームクレーム（PVC）という2つのキー抽象化を使用して、この課題に取り組んでいます。これらの抽象化により、プロビジョニング、ライフサイクル管理、容量などのストレージの問題をアプリケーションのロジックから分離することができ、開発者はスケーラブルで耐障害性のあるアプリケーションの構築に集中することができます。

永続ボリューム（PV）の理解

KubernetesのPVは、管理者によってまたはストレージプラグインを介して動的にプロビジョニングされたストレージの一部を表すものです。これはクラスタレベルのリソースであり、特定の名前空間に結び付けられておらず、異なる名前空間を持つPVCによってクレームされることができます。PVは、オンプレミスソリューションまたはクラウドストレージサービスによって提供されるブロックストレージ、ファイルシステム、オブジェクトストレージなど、さまざまなストレージバックエンドをサポートしています。

PVは次の特性を具備しています：

• 容量：PVのストレージサイズで、作成時に定義されます。
• アクセスモード：PVをポッドにマウントする方法（ReadWriteOnce（RWO）、ReadOnlyMany（ROX）、ReadWriteMany（RWX）など）です。
• 再利用ポリシー：関連するPVCが削除された後にPVのデータがどのように処理されるかを指示するポリシーです。一般的なポリシーには、Retain、Delete、Recycleなどがあります。
• ストレージクラス: PVを特定のストレージクラスにリンクするオプションの属性で、プロビジョニングポリシーやその他のストレージパラメータを定義します。

永続ボリュームのライフサイクル

PVのライフサイクルは、作成およびプロビジョニングから始まります。作成されると、PVは以下の状態のいずれかになります：

• 利用可能: PVはまだどのPVCにもバインドされておらず、請求可能です。
• バインド済み: PVはPVCによって請求され、新しい請求には利用できません。
• 解放済み: PVに関連付けられたPVCが削除されましたが、基盤となるストレージリソースはまだ回収されていません。
• 失敗: PVは自動回収中にエラーが発生しました。

永続ボリューム請求（PVC）の理解

PVCはユーザー（通常は開発者またはアプリケーション）によるストレージのリクエストです。サイズやアクセスモードなど、他のストレージ属性を指定します。PVCは名前空間リソースであり、特定の名前空間に属し、同じ名前空間内のポッドのみがアクセスできます。

PVCが作成されると、Kubernetesコントロールプレーンは請求の要件を満たす利用可能なPVを探します。適切なPVが見つかった場合、PVCはそれにバインドされ、PVとPVCの間に1対1のマッピングが作成されます。適切なPVが存在せず、動的プロビジョニングが設定されている場合は、請求を満たすために新しいPVが動的にプロビジョニングされます。

PVとPVCの相互作用

PVsとPVCsの関係は、Kubernetesでステートフルなワークロードを管理する上で基本的なものです。この相互作用により、

• デカップリング: アプリケーションは基盤となるストレージインフラから切り離され、開発と展開が簡素化されます。
• ポータビリティ: 抽象化されたストレージリソースの使用により、異なる環境やクラウドプロバイダー間でのワークロードのポータビリティが実現されます。
• スケーラビリティ: ストレージリソースの動的プロビジョニングにより、アプリケーションは管理者の手動介入なしにシームレスにスケールできます。

GlusterFSのブリック上に永続ボリューム（PV）を作成するには、GlusterFSクラスタとブリックのセットアップを含むいくつかのステップが必要です。GlusterFSにおけるブリックは、ストレージネットワーク内のサーバー上のディレクトリに対応する基本的なストレージ単位です。GlusterFSクラスタが準備できたら、GlusterFSボリューム（1つ以上のブリックで構成）を参照してPVを作成できます。

GlusterFSのブリック上にPVを作成するための一般的なステップは以下の通りです：

GlusterFSクラスタのセットアップ

少なくとも1つのボリュームが作成され、起動しているGlusterFSクラスタを持っていることを確認してください。GlusterFSボリュームはブリックで構成されており、各ブリックはストレージネットワーク内のサーバー上のディレクトリです。

GlusterFSボリューム情報の取得

GlusterFSボリュームに関する以下の情報が必要です：

• ボリューム名
• エンドポイント（GlusterFSサーバーのIPアドレスまたはホスト名のリスト）

KubernetesでGlusterFSエンドポイントとサービスを作成

エンドポイントリソースを作成して、GlusterFSサーバーのIPアドレスをリストし、その後エンドポイントを指すサービスを作成します。

エンドポイントYAML（glusterfs-endpoints.yaml）：

apiVersion: v1

kind: Endpoints

metadata:

  name: glusterfs-cluster

subsets:

  - addresses:

      - ip: <glusterfs-server-1-ip>

      - ip: <glusterfs-server-2-ip>

      - ip: <glusterfs-server-n-ip>

    ports:

      - port: 1

サービスYAML（glusterfs-service.yaml）：

apiVersion: v1

kind: Service

metadata:

  name: glusterfs-cluster

ports:

  - port: 1

次のコマンドを使用して構成を適用します：

• kubectl:kubectl apply -f glusterfs-endpoints.yaml
• kubectl apply -f glusterfs-service.yaml

永続ボリュームを作成する

エンドポイントが整ったら、GlusterFSボリュームを参照するPVを作成できます。

PV YAML（glusterfs-pv.yaml）：

apiVersion: v1

kind: PersistentVolume

metadata:

  name: glusterfs-pv

spec:

  capacity:

    storage: 5Gi

  accessModes:

    - ReadWriteMany

  glusterfs:

    endpoints: glusterfs-cluster

    path: <glusterfs-volume-name>

    readOnly: false

   persistentVolumeReclaimPolicy: Retain

<glusterfs-server-1-ip>、<glusterfs-server-2-ip>、<glusterfs-server-n-ip>、および<glusterfs-volume-name>を実際のGlusterFSサーバーのIPとボリューム名に置き換えます。その後、PVを作成します：

• kubectl apply -f glusterfs-pv.yaml

永続ボリュームを確認する

PVを作成した後、Kubernetesクラスターで利用可能かどうかを確認します：

• kubectl get pv

これは一般的なガイドであり、GlusterFSボリュームがすでに設定されており、KubernetesクラスターがGlusterFSサーバーと通信できることを前提としています。特定の環境とバージョンに合わせた詳細な指示については、公式のGlusterFSおよびKubernetesのドキュメントを参照してください。

Kubernetesでファイルシステム上に永続ボリューム（PV）を作成するには、ホストされているストレージの詳細を指定するPVリソースを定義する必要があります。ここでは、ノードのローカルファイルシステムからディレクトリを使用してPVを作成する方法を示します。これはマウントされたディスクやノードにアクセス可能な任意のディレクトリである可能性があります。

重要: ローカルストレージを使用すると、PVが特定のノードに結びつき、それを使用するポッドの移植性が制限されます。さらに、ローカルストレージのデータは複製されないため、高可用性を必要とする本番環境のワークロードには適していません。

ローカルファイルシステムのディレクトリを使用してPVを作成する方法の例を以下に示します。

ノード上にストレージを準備する

PVとして公開したいノード上のディレクトリを選択します。たとえば、/mnt/dataにあるディレクトリを使用することができます。このディレクトリが存在し、適切な権限が設定されていることを確認してください。

• sudo mkdir -p /mnt/data  
• sudo chown -R nobody:nogroup /mnt/data  
• sudo chmod 0777 /mnt/data

永続ボリュームを定義する

PVのためのYAMLファイルを作成します。たとえば、local-pv.yamlという名前のファイルを作成し、PVリソースを定義します。

apiVersion: v1

kind: PersistentVolume

metadata:

  name: local-pv

spec:

  capacity:

    storage: 5Gi

  accessModes:

    - ReadWriteOnce

   persistentVolumeReclaimPolicy: Retain

  storageClassName: local-storage

  local:

    path: /mnt/data

  nodeAffinity:

    required:

       nodeSelectorTerms:

        - matchExpressions:

            - key: kubernetes.io/hostname

               operator: In

              values:

                - <node-name>

上記のYAMLファイルでは、<node-name>をストレージがあるノードの名前に置き換えてください。これにより、PVはその特定のノードで実行されるポッドのみが利用できるようになります。

JSONまたはYAML出力を使用してノードを取得するためのkubectlの使用方法

情報をJSONまたはYAML形式で出力し、jqのようなツールを使用してJSON処理を行い、ノード名を抽出することもできます：

• kubectl get nodes -o json | jq '.items[].metadata.name'

このjqコマンドは、引用符付きのノード名のリストを提供します：

• “node1” “node2” “node3”

YAML出力の場合は、次のようにします：

• kubectl get nodes -o yaml

その後、YAML出力を手動で確認してノード名を探すか、yqのようなツールを使用してコマンドラインからYAMLを解析できます。

永続ボリュームを作成する

設定をクラスターに適用します：

kubectl apply -f local-pv.yaml

永続ボリュームを確認する

PVを作成した後、次のコマンドでそのステータスを確認できます：

kubectl get pv local-pv

永続ボリュームの使用

このPVを使用するには、ポッドが適切なサイズとアクセスモードのストレージを要求する永続ボリュームクレーム（PVC）を作成する必要があります。以下は、ローカルPVを主張するために使用できるPVCの例です：

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: local-pvc

spec:

  accessModes:

    - ReadWriteOnce

  storageClassName: local-storage

  resources:

    requests:

      storage: 5Gi

PVCのstorageClassNameは、ローカルPVで定義されたstorageClassNameと一致する必要があります。これがKubernetesスケジューラーがPVCを適切なPVにバインドするために使用するものです。

PVCを作成したら、ポッドの仕様のボリュームセクションでそれを参照してローカルストレージをマウントできます：

volumes:

  - name: local-storage

     persistentVolumeClaim:

      claimName: local-pvc

ローカルボリュームを使用する際は、ノードが失敗したりポッドが別のノードに再スケジュールされた場合、新しいノードからデータにアクセスできなくなることに注意してください。ローカルボリュームは通常、一時的なストレージや、アプリケーションがノード固有のストレージや潜在的なデータ損失を処理できる状況で使用されます。

Deploymentを通じてPVCを使用するポッドを作成するには、KubernetesでDeploymentリソースを定義する必要があります。Deploymentはポッド作成のテンプレートを指定し、PVCを参照するボリュームマウントを含みます。

以下は、その設定方法の例です：

PersistentVolumeClaim（PVC）を確保する

DeploymentでPVCを使用する前に、Kubernetesクラスター内に既存のPVCが必要です。以下はPVCのYAML定義の例です：

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: my-pvc

  namespace: default

spec:

  accessModes:

    - ReadWriteOnce

  resources:

    requests:

      storage: 1Gi

この定義をkubectlで適用します：

• kubectl apply -f my-pvc.yaml

PVCがPersistentVolume（PV）にバインドされ、使用可能な状態であることを確認してください。

PVCを使用するDeploymentを作成する

PVCのボリュームマウントを含むDeployment YAMLを定義します。以下はその例です：

apiVersion: apps/v1

kind: Deployment

metadata:

  name: my-deployment

  namespace: default

spec:

  replicas: 3

  selector:

    matchLabels:

      app: my-app

  template:

    metadata:

      labels:

        app: my-app

    spec:

      containers:

        - name: my-container

          image: nginx

          ports:

            - containerPort: 80

           volumeMounts:

            - mountPath: /usr/share/nginx/html

              name: my-volume

      volumes:

        - name: my-volume

           persistentVolumeClaim:

            claimName: my-pvc

この例では、DeploymentはNginxを実行するコンテナを持つポッドを作成し、PVCは/usr/share/nginx/html.にマウントされます。

Deploymentをkubectlで適用します：

• kubectl apply -f my-deployment.yaml

Deploymentとポッドを確認する

Deploymentとポッドの状態を確認し、正しく実行されていてPVCが正しくマウントされていることを確認します：

• kubectl get deployment my-deployment
• kubectl get pods --selector=app=my-app

あるポッドの詳細を表示することもできます:

• kubectl describe pod <pod-name>

<pod-name>を実際のポッド名に置き換えてください。

これらの手順に従うことで、永続ストレージにPVCを使用してポッドを作成するKubernetesデプロイメントを持つことができます。アプリケーションの特定のニーズに合わせて、イメージ、ボリュームマウントパス、およびその他の構成の詳細を調整することをお忘れなく。

PVをPVCに関連付ける方法

Kubernetesでは、永続ボリュームクレーム（PVC）は通常、PVCに指定されたストレージクラスと容量要件を使用して永続ボリューム（PV）にバインドされます。ただし、バインディングプロセスをより細かく制御する必要があるシナリオでは、PVCをPVに関連付ける他の方法があります。以下はいくつかの代替方法です:

手動静的プロビジョニング

PVを手動で事前にプロビジョニングすると、accessModesおよびresources.requests.storageの値を一致させることで、特定のPVCが特定のPVにバインドされることを確認できます。さらに、一致を明確にするためにラベルとセレクタを使用することもできます。

カスタムラベルを持つ例PV:

apiVersion: v1

kind: PersistentVolume

metadata:

  name: my-pv

  labels:

    type: local

spec:

  capacity:

    storage: 5Gi

  accessModes:

    - ReadWriteOnce

  storageClassName: manual

  local:

    path: /mnt/disks/ssd1

  nodeAffinity:

    required:

       nodeSelectorTerms:

        - matchExpressions:

            - key: kubernetes.io/hostname

               operator: In

              values:

                - your-node-name

ラベルに一致するセレクタを持つ例PVC:

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: my-pvc

spec:

  accessModes:

    - ReadWriteOnce

  storageClassName: manual

  resources:

    requests:

      storage: 5Gi

  selector:

    matchLabels:

      type: local

この例では、PVCはラベルtype: localを持つPVにのみバインドされます。

PVC内のVolumeNameフィールド

PVC がバインドされる PV の名前を明示的に指定するには、PVC 仕様の volumeName フィールドを設定します。

volumeName が設定された例の PVC：

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: my-pvc

spec:

  accessModes:

    - ReadWriteOnce

  resources:

    requests:

      storage: 5Gi

  volumeName: my-pv

この方法は、通常の動的プロビジョニングプロセスをバイパスして、PVC を指定された PV に直接関連付けます。

StorageClass と VolumeBindingMode

StorageClass の volumeBindingMode フィールドを WaitForFirstConsumer に設定することで、PVC を使用するポッドが作成されるまで、PV のバインドとプロビジョニングを遅延させることができます。これは、PV がポッドと同じノードにある必要があるローカルボリュームに便利です。

WaitForFirstConsumer を使用した例の StorageClass：

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

  name: local-wait

provisioner: kubernetes.io/no-provisioner

volumeBindingMode: WaitForFirstConsumer

この StorageClass を参照する PVC は、ポッドが PVC をリクエストするまでバインドを待機します。

PVC を PV に事前バインドする

PVC を作成する前に、PV 仕様で claimRef を指定して PVC を事前にバインドすることができます。この方法は、手動での介入と注意深い調整が必要なため、一般的には使用されません。

claimRefset が設定された例の PV：

apiVersion: v1

kind: PersistentVolume

metadata:

  name: my-pv

spec:

  capacity:

    storage: 5Gi

  accessModes:

    - ReadWriteOnce

   persistentVolumeReclaimPolicy: Retain

  claimRef:

    namespace: default

    name: my-pvc

  local:

    path: /mnt/disks/ssd1

  nodeAffinity:

    required:

       nodeSelectorTerms:

        - matchExpressions:

            - key: kubernetes.io/hostname

               operator: In

              values:

                - your-node-name

PVC my-pvc が作成されると、自動的に my-pv にバインドされます。

これらの各方法は、PV 間のバインディングプロセスに対する異なるレベルの制御を提供します。

要約

永続ボリュームと永続ボリュームクレームは、Kubernetesストレージモデルにおいて重要な要素であり、ステートフルアプリケーションの展開と管理を促進します。ストレージの詳細をアプリケーション層から抽象化することで、Kubernetesは永続ストレージに対してより柔軟で効率的、かつ開発者に優しいアプローチを実現します。Kubernetesエコシステムが進化し続ける中で、PVsとPVCsはステートフルワークロードオーケストレーションにおける戦略の中心にとどまり続けるでしょう。