Azure Kubernetes Service (AKS) でのアプリケーションのストレージオプション

[アーティクル]
04/26/2023

Azure Kubernetes Service (AKS) で実行されるアプリケーションで、データの格納や取得が必要になることがあります。不要で空になったノード上のローカルで高速なストレージを使用できるアプリケーションワークロードもあれば、Azure プラットフォーム内の通常のデータボリューム上に保持されるストレージを必要とするものもあります。

複数のポッドに以下が必要になる場合があります。

同じデータボリュームを共有する。
ポッドが別のノードで再スケジュールされた場合、データボリュームを再アタッチする。

最後に、必要に応じて、機密データまたはアプリケーション構成情報を収集し、ポッドに格納します。

この記事では、AKS 内でアプリケーションにストレージを提供する主要な概念について説明します。

Volumes
永続ボリューム
ストレージクラス
永続ボリューム要求

Azure Kubernetes Service (AKS) クラスターでのアプリケーションのストレージオプション

ボリューム

通常、Kubernetes により、個々のポッドは一時的な使い捨てのリソースとして扱われます。アプリケーションには、データの使用と保持のために、さまざまなアプローチを使用できます。 "ボリューム" とは、複数のポッドにまたがり、アプリケーションライフサイクルを通じて、データを格納、取得および保存する手段です。

従来のボリュームは、Azure Storage に支えられた Kubernetes リソースとして作成されます。データボリュームを手動で作成してポッドに直接割り当てることも、Kubernetes で自動的に作成することもできます。データボリュームには、Azure ディスク、Azure Files、Azure NetApp Files、または Azure BLOB を使用できます。

注意

使用される VM SKU によっては、Azure Disk CSI ドライバーにノードごとのボリューム制限がある場合があります。一部の強力な VM (16 コアなど) の場合、制限はノードあたり 64 ボリュームです。 VM SKU あたりの制限を特定するには、提供される VM SKU ごとの [最大データディスク数] 列を確認します。提供される VM SKU とそれに対応する詳細な容量制限の一覧については、「汎用仮想マシンのサイズ」を参照してください。

Azure Files と Azure NetApp Files のうち、どちらがワークロードに最適かを判断するには、「Azure Files と Azure NetApp Files の比較」という記事に記載されている情報を参照してください。

Azure ディスク

Azure ディスクは、Kubernetes DataDisk リソースを作成するために使用します。ディスクの種類には次のものが含まれます。

Ultra Disks
Premium SSD
Standard SSD
Standard HDD

ヒント

ほとんどの運用ワークロードと開発ワークロードでは Premium SSD を使用します。

Azure ディスクは ReadWriteOnce としてマウントされるため、1 つのノードでしか使用できません。ストレージボリュームに複数のノードのポッドで同時にアクセスするためには、Azure Files を使用してください。

Azure Files

Azure Files を使って、Azure Storage アカウントを使うサーバーメッセージブロック (SMB) バージョン 3.1.1 共有またはネットワークファイルシステム (NFS) バージョン 4.1 共有をポッドにマウントします。 Azure Files を使用すると、複数のノードとポッドにまたがってデータを共有できます。また、以下を使用できます。

ハイパフォーマンス SSD に支えられた Azure Premium ストレージ
通常の HDD に支えられた Azure Standard ストレージ

Azure NetApp Files

Ultra Storage
Premium Storage
Standard Storage

Azure Blob Storage

Azure Blob Storage を使って BLOB ストレージコンテナーを作成し、NFS v3.0 プロトコルまたは BlobFuse を使ってそれをマウントします。

ブロック BLOB

ボリュームの種類

Kubernetes ボリュームは、情報を格納および取得するための単なる従来のディスクを超えるものです。 Kubernetes のボリュームは、コンテナーで使用するために、ポッドにデータを挿入する手段としても使用できます。

Kubernetes の一般的なボリュームの種類は次のとおりです。

emptyDir

一般的にポッドの一時的なスペースとして使用されます。ポッド内のすべてのコンテナーが、このボリューム上のデータにアクセスできます。このボリュームの種類に書き込まれたデータは、ポッドの存続期間中のみ存続します。ポッドを削除すると、ボリュームも削除されます。一般的にこのボリュームは基礎となるローカルノードのディスクストレージを使用しますが、ノードのメモリ内のみに存在することもできます。

secret

"シークレット" ボリュームを使用すると、パスワードなどの機密データをポッドに挿入することができます。

Kubernetes API を使用してシークレットを作成します。
ポッドまたはデプロイを定義し、特定のシークレットを要求します。
- シークレットは、それを必要とするスケジュールされたポッドを持つノードにのみ提供されます。
- シークレットは tmpfs に格納され、ディスクには書き込まれません。
シークレットを必要とするノードの最後のポッドを削除すると、ノードの tmpfs からシークレットが削除されます。
- シークレットは、指定した名前空間内に格納され、同じ名前空間内のポッドによってのみアクセスできます。

configMap

configMap を使用すると、アプリケーション構成情報など、キーと値のペアのプロパティをポッドに挿入することができます。アプリケーションの構成情報を Kubernetes リソースとして定義することで、デプロイ時に簡単に更新し、新しいポッドのインスタンスに適用することができます。

シークレットの使用と同様に、以下を実行できます。

Kubernetes API を使用して ConfigMap を作成する。
ポッドやデプロイを定義する際に ConfigMap を要求する。
- ConfigMap は、指定した名前空間内に格納され、同じ名前空間内のポッドによってのみアクセスできます。

永続ボリューム

ポッドのライフサイクルの一部として定義および作成されたボリュームが存在するのは、ポッドを削除するまでです。メンテナンスイベントでポッドが別のホストに再スケジュールされた場合でも、多くの場合、ポッドはストレージがそのまま存在することを予期しています (特に StatefulSets)。 "永続ボリューム" (PV) は、Kubernetes API によって作成および管理されるストレージリソースであり、個々のポッドの有効期間が終了しても存在できます。

Azure ディスクまたは Azure Files を使用して PersistentVolume を用意できます。「ボリューム」セクションで説明したように、多くの場合、ディスクまたは Files の選択はデータへの同時アクセスの必要性またはパフォーマンスレベルによって決まります。

Azure Kubernetes Services (AKS) クラスターでの永続ボリューム

PersistentVolume は、クラスター管理者が "静的に" 作成することも、Kubernetes API サーバーが "動的に" 作成することもできます。ポッドがスケジュールされ、現在使用不能なストレージを要求する場合、Kubernetes は基礎となる Azure ディスクまたは Files ストレージを作成して、ポッドに接続できます。動的なプロビジョニングでは StorageClass を使用して、どの種類の Azure Storage を作成する必要があるかを特定します。

重要

永続ボリュームは、2 つのオペレーティングシステム間のファイルシステムのサポートの違いにより、Windows ポッドおよび Linux ポッドで共有できません。

ストレージクラス

Premium や Standard など異なる階層を定義するために、StorageClass を作成できます。

StorageClass によって reclaimPolicy も定義されます。永続ボリュームを削除すると、reclaimPolicy により、基礎となる Azure ストレージリソースの動作が制御されます。基礎となるストレージリソースは削除することも、将来のポッドで使用するために保持しておくこともできます。

Container Storage Interface (CSI) ドライバーを使用するクラスターの場合、次の追加の StorageClasses が作成されます。

権限	理由
`managed-csi`	Azure StandardSSD ローカル冗長ストレージ (LRS) を使用して、マネージドディスクを作成します。解放ポリシーによって、基礎となる Azure ディスクを使用していた永続ボリュームが削除されるときに、ディスクも確実に削除されます。ストレージクラスによって永続ボリュームを拡張可能にする構成も行われるため、必要なのは、永続ボリューム要求を新しいサイズで編集することだけです。
`managed-csi-premium`	Azure Premium ローカル冗長ストレージ (LRS) を使用して、マネージドディスクを作成します。ここでも、解放ポリシーによって、基礎となる Azure ディスクを使用していた永続ボリュームが削除されるときに、ディスクも確実に削除されます。同様に、このストレージクラスを使用して、永続ボリュームを拡張できます。
`azurefile-csi`	Azure Standard ストレージを使用して Azure ファイル共有を作成します。解放ポリシーを使用すると、基礎となる Azure ファイル共有は、それを使用していた永続ボリュームが削除されるときに、確実に削除されます。
`azurefile-csi-premium`	Azure Premium ストレージを使用して Azure ファイル共有を作成します。解放ポリシーを使用すると、基礎となる Azure ファイル共有は、それを使用していた永続ボリュームが削除されるときに、確実に削除されます。
`azureblob-nfs-premium`	Azure Premium ストレージを使って Azure Blob Storage コンテナーを作成し、NFS v3 プロトコルを使って接続します。解放ポリシーによって、基礎となる Azure Blob ストレージコンテナーは、それを使用していた永続ボリュームが削除されるときに、確実に削除されます。
`azureblob-fuse-premium`	Azure Premium ストレージを使って Azure Blob Storage コンテナーを作成し、BlobFuse を使って接続します。解放ポリシーによって、基礎となる Azure Blob ストレージコンテナーは、それを使用していた永続ボリュームが削除されるときに、確実に削除されます。

永続ボリュームに StorageClass を指定しない限り、既定の StorageClass が使用されます。永続ボリュームを要求する際には、ボリュームが必要な適切なストレージを使用していることをご確認ください。

重要

Kubernetes バージョン 1.21 以降、AKS の既定では CSI ドライバーのみが使われるようになり、CSI の移行が有効になりました。既存のツリー内永続ボリュームは引き続き機能しますが、バージョン 1.26 以降、ツリー内ドライバーを使用して作成されたボリューム、およびファイルとディスク用にプロビジョニングされたストレージは AKS でサポートされなくなります。

default クラスは managed-csi と同じになります。

kubectl を使用して、その他のニーズのために StorageClass を作成できます。次の例は、Premium マネージドディスクを使用し、ポッドの削除時に基礎となる Azure ディスクを "保持する" ように指定します。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_LRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

注意

AKS は、既定のストレージクラスを調整し、それらのストレージクラスに加えた変更をすべて上書きします。

ストレージクラスの詳細については、Kubernetes の StorageClass に関する記事を参照してください。

永続ボリューム要求

PersistentVolumeClaim は、特定の StorageClass のストレージ、アクセスモード、サイズを要求します。 Kubernetes API サーバーは、定義された StorageClass に基づいて要求を満たす既存のリソースがない場合、基礎となる Azure ストレージリソースを動的にプロビジョニングできます。

ボリュームがポッドに接続されると、ポッドの定義にボリュームマウントが含まれます。

Azure Kubernetes Services (AKS) クラスターでの永続ボリューム要求

ストレージを要求したポッドに、使用可能なストレージリソースがポッドに割り当てられると、PersistentVolume が PersistentVolumeClaim に "バインド" されます。永続ボリュームは、要求に 1 対 1 でマップされます。

次の例の YAML マニフェストでは、managed-premium StorageClass を使用し、サイズが 5Gi のディスクを要求する永続ボリューム要求が示されます。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

ポッド定義を作成するときは、以下も指定します。

目的のストレージを要求するための永続ボリュームクレーム。
アプリケーションからデータの読み取りと書き込みを行うための volumeMount。

次の例の YAML マニフェストでは、前の永続ボリューム要求を使用してボリュームを /mnt/azure にマウントする方法が示されます。

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Windows コンテナーにボリュームをマウントするには、ドライブ文字とパスを指定します。次に例を示します。

...      
       volumeMounts:
        - mountPath: "d:"
          name: volume
        - mountPath: "c:\k"
          name: k-dir
...

次のステップ

関連するベストプラクティスについては、AKS のストレージとバックアップに関するベストプラクティスに関する記事を参照してください。

CSI ドライバーの使用方法については、次のハウツー記事を参照してください。

Kubernetes と AKS の中心概念の詳細については、次の記事を参照してください。

Azure Kubernetes Service (AKS) でのアプリケーションのストレージオプション

ボリューム

Azure ディスク

Azure Files

Azure NetApp Files

Azure Blob Storage

ボリュームの種類

emptyDir

secret

configMap

永続ボリューム

ストレージクラス

永続ボリューム要求

次のステップ

その他のリソース

その他のリソース

Azure Kubernetes Service (AKS) でのアプリケーションのストレージ オプション

ボリューム

Azure ディスク

Azure Files

Azure NetApp Files

Azure Blob Storage

ボリュームの種類

emptyDir

secret

configMap

永続ボリューム

ストレージ クラス

永続ボリューム要求

次のステップ

その他のリソース

その他のリソース

Azure Kubernetes Service (AKS) でのアプリケーションのストレージオプション

ストレージクラス