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

[アーティクル]
08/30/2023

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

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

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

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

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

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

Storage options for applications in an Azure Kubernetes Services (AKS) cluster

エフェメラル OS ディスク

既定では、VM を別のホストに再配置するときにデータの損失を防ぐために、Azure によって仮想マシンのオペレーティングシステムディスクが Azure Storage に自動的にレプリケートされます。ただし、コンテナーはローカルの状態を永続化するように設計されていないため、この動作の価値は限定的であり、いくつかの欠点があります。これらの欠点には、ノードのプロビジョニング速度の低下や読み取り/書き込みの待機時間の短縮などがありますが、これらに限定されません。

これに対して、エフェメラル OS ディスクは、一時ディスクと同様に、ホストマシンにのみ格納されます。この構成では、読み取り/書き込みの待機時間が短縮されるとともに、ノードのスケーリングやクラスターのアップグレードが高速になります。

注意

OS 用に Azure マネージドディスクを明示的に要求しないと、AKS は、指定されたノードプール構成で可能であれば、既定でエフェメラル OS を使います。

エフェメラル OS ディスクのサイズ要件と推奨事項については、Azure VM のドキュメントを参照してください。一般的なサイズ設定の考慮事項をいくつか以下に示します。

AKS の既定の VM サイズである Standard_DS2_v2 SKU を既定の OS ディスクサイズである 100 GiB で使う場合、既定の VM サイズはエフェメラル OS をサポートしていますが、キャッシュサイズは 86 GiB だけになります。明示的に指定しない場合、この構成は既定でマネージドディスクになります。エフェメラル OS を要求すると、検証エラーが発生します。
同じ Standard_DS2_v2 SKU を 60 GiB の OS ディスクで要求した場合、この構成は既定でエフェメラル OS になります。要求された 60 GiB のサイズは、最大キャッシュサイズ 86 GiB より小さくなります。
Standard_D8s_v3 SKU と 100 GB の OS ディスクを選んだ場合、この VM サイズはエフェメラル OS をサポートし、キャッシュ領域は 200 GiB になります。 OS ディスクの種類を指定しないと、ノードプールは既定でエフェメラル OS を受け取ります。

最新世代の VM シリーズには専用キャッシュはなく、一時ストレージのみが含まれます。たとえば、既定の OS ディスクサイズ 100 GiB で Standard_E2bds_v5 VM サイズを選択した場合、エフェメラル OS ディスクはサポートされますが、一時ストレージは 75 GB のみになります。明示的に指定しない場合、この構成は既定でマネージド OS ディスクになります。エフェメラル OS ディスクを要求すると、検証エラーが発生します。

同じ Standard_E2bds_v5 VM サイズと 60 GiB の OS ディスクを要求した場合、この構成は既定でエフェメラル OS ディスクになります。要求したサイズ 60 GiB は、最大一時ストレージの 75 GiB より小さくなります。
Standard_E4bds_v5 SKU と 100 GiB の OS ディスクを選んだ場合、この VM サイズはエフェメラル OS をサポートし、150 GiB の一時ストレージを備えます。 OS ディスクの種類を指定しないと、既定では、Azure によってエフェメラル OS ディスクがノードプールにプロビジョニングされます。

カスタマーマネージドキー

AKS クラスター上の独自のキーを使って、エフェメラル OS ディスクの暗号化を管理できます。詳細については、「AKS 上の Azure ディスクでのカスタマーマネージドキーの使用」を参照してください。

ボリューム

通常、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 を要求する。
- ConfigMaps は、指定した名前空間内に保存され、同じ名前空間内のポッドからのみアクセスできます。

永続ボリューム

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

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

Persistent volumes in an Azure Kubernetes Services (AKS) cluster

クラスター管理者は 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_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

注意

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

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

永続ボリューム要求

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

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

Persistent volume claims in an Azure Kubernetes Services (AKS) cluster

ストレージを要求したポッドに、使用可能なストレージリソースがポッドに割り当てられると、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 のストレージとバックアップ」と「AKS ストレージに関する考慮事項」を参照してください。

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

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

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