ウェブサイト検索

Kubernetes ポッドに永続ストレージを追加する方法


Kubernetes Pod ファイルシステムは、デフォルトでは一時的です。これは、コンテナーのステートレスな性質と一致しています。永続データは、コンテナのファイルシステム内にあるように見える場合でも、コンテナの外部に保存する必要があります。 Kubernetes で永続ストレージをプロビジョニングする方法は次のとおりです。

Kubernetes 永続ストレージの基本単位は永続ボリュームです。これは、より基本的なボリュームを抽象化したものです。

永続ボリュームは、特定のポッドとは独立して存在します。プレーンな Docker ボリュームと同様に、Kubernetes の永続ボリュームは、それを使用しているポッドがない場合でもクラスター内に残すことができます。

ポッドには永続ボリュームの要求を行うことで永続ボリュームへのアクセスが許可されます。これは、永続ストレージを使用するポッドのリクエストを表す別のリソース タイプです。このクレームは、リクエストを満たす永続ボリュームのプロビジョニングを処理します。

基本的な例

Persistent Volume と Persistent Volume Claim を手動で設定して永続ストレージ システムを作成する方法を見てみましょう。各リソースは独自のマニフェスト ファイルに入ります。 kubectl apply を使用して、これらのファイルをクラスターに適用できます。

永続ボリュームの作成

まずボリュームを作成します。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-volume
  namespace: pvc-demo
spec:
  storageClassName: manual
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data

この定義により、my-volume というボリュームが作成されます。容量は 2Gi で、ホスト ノードの /mnt/data に保存されます。このボリュームは手動で作成しているため、storageClassNamemanual に設定されています。ストレージ クラスを使用すると、ボリュームが同じクラスを要求するボリューム クレームにのみバインドされるように指定できます。

Persistent Volume Claim の作成

これで、Persistent Volume Claim を構成できるようになりました。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-volume-claim
  namespace: pvc-demo
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

このクレームは、manual クラスを使用して、ボリュームから 1Gi のストレージを要求します。先ほど作成したボリュームはこれらの条件を満たすことができます。クレームが作成されると、Kubernetes はこれを認識し、クレームをボリュームにバインドする必要があります。

ボリュームとクレームの詳細を調べると、両方とも Bound のステータスを示していることがわかります。

kubectl get pv my-volume
kubectl get pvc my-volume-claim

ポッドを追加する

最後の段階では、ボリューム要求を使用して永続ストレージをポッドに追加します。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: pvc-demo
spec:
  containers:
    - name: my-container
      image: my-image:latest
      volumeMounts:
        - mountPath: /path/in/container
          name: my-pod-volume
  volumes:
    - name: my-pod-volume
      persistentVolumeClaim:
        claimName: my-volume-claim

volumes セクション内で、Persistent Volume Claim への参照が構成されます。ボリュームに関するその他の情報を指定する必要はありません。ポッドはクレームを使用して、バインドされているボリュームを提供します。

このクレームは volumeMounts で参照されます。 volumesvolumeMounts では必ず同じ名前を使用してください。ボリュームは、mountPath で指定された場所にある Pod にマウントされます。

これで、Pod には永続ストレージが利用可能になりました。 /path/in/container に書き込まれたものはすべて永続ボリュームに保存されます。 Persistent Volume Claim は、それを参照する新しい Pod によって再利用され、データは個々の Pod よりも長く存続することができます。

ストレージクラス

manual ストレージ クラスは、独自のボリュームおよびボリューム クレーム マニフェストを作成するときに使用されます。さまざまなボリューム プラグイン ドライバーが独自のストレージ クラスを提供します。使用するボリュームの種類を表すストレージ クラスを参照します。

マネージド Kubernetes サービスは通常、プラットフォームのブロック ストレージ実装にマップする独自のストレージ クラスを提供します。例には、Google Kubernetes Engine の gcePersistentDisk や、DigitalOcean Managed Kubernetes の do-block-storage が含まれます。

これらのシナリオでは、PersistentVolume マニフェストを手動で作成する必要はありません。正しい storageClassName を使用して PersistentVolumeClaim を作成し、resources.requests.storage フィールド (上に表示) を使用して必要な容量を指定します。ストレージ ドライバーは、クレームを互換性のあるボリューム インスタンスに自動的にバインドします。

アクセスモード

accessModes フィールドには 3 つの値がサポートされています。

  • ReadWriteOnce – ボリュームは単一の Kubernetes ノードにのみマウントできます。そのノードはボリュームへの完全な読み取り/書き込みアクセス権を持ちます。
  • ReadOnlyMany – ボリュームは複数のノードで同時に使用できます。各ノードには読み取り専用アクセス権があります (ボリュームには何も書き込めません)。
  • ReadWriteMany – ボリュームは複数のノードに同時にマウントできます。各ノードはボリュームの読み取りと書き込みが可能です。

特定のボリュームで使用できるアクセス モードは常に 1 つだけです。つまり、両方のクレームが同じアクセス モードを宣言している場合、2 つのボリューム クレームは同じボリュームにのみバインドされます。

ボリュームのアクセス モードは、ポッドのレプリカを複数のノードにまたがる Kubernetes スケジューラの機能に影響します。 Pod が永続ストレージを共有し、複数のノードにレプリケートされる必要がある場合は、ReadOnlyMany/ReadWriteMany モードを使用する必要があります。

すべてのストレージ ドライバーがすべてのアクセス モードをサポートしているわけではないことに注意してください。プラグインのプロバイダーに確認する必要があります。ボリューム プラグインと互換性のあるアクセス モードの完全なリストは、Kubernetes ドキュメントに記載されています。

結論

Kubernetes の永続ストレージは、一見したほど難しくありません。ストレージにアクセスする必要があるポッドに、Persistent Volume Claim にバインドされたボリュームがあることを確認してください。

Persistent Volume Claims が使用されると、Kubernetes は個々のポッドよりも存続する永続ボリュームを作成します。ポッドが交換されると、要求されたボリュームは新しいポッドに自動的にマウントされます。申し立てが削除されるまでデータは破棄されません。

関連記事:


全著作権所有。 © Linux-Console.net • 2019-2025