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

[アーティクル]
08/02/2024

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

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

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

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

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

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

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

既定の OS ディスクのサイズ設定

新しいクラスターを作成する、または既存のクラスターに新しいノードプールを追加する場合、既定では vCPU の数に応じて OS ディスクサイズが決まります。 vCPU の数は、VM SKU に基づきます。次の表は、各 VM SKU の既定の OS ディスクサイズをリストしています。

VM SKU コア (vCPU)	既定の OS ディスクの層	プロビジョニングされた IOPS	プロビジョニングされたスループット (Mbps)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

重要

既定の OS ディスクのサイズ設定は、新しいクラスターまたはノードプールで、エフェメラル OS ディスクがサポートされておらず、既定の OS ディスクサイズが指定されていない場合にのみ使われます。既定の OS ディスクサイズは、クラスターのパフォーマンスやコストに影響する可能性があります。クラスターまたはノードプールの作成後に OS ディスクサイズを変更することはできません。この既定のディスクサイズ設定は、2022 年 7 月以降に作成されたクラスターまたはノードプールに影響します。

エフェメラル 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 リソースを作成するために使用します。ディスクの種類には次のものが含まれます。

Premium SSD (ほとんどのワークロードに推奨)
Ultra ディスク
Standard SSD
Standard HDD

ヒント

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

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

Azure Files

Azure Files を使用して、サーバーメッセージブロック (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 Storage データサービスを使用し、永続ボリュームを提供できます。

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

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

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

重要

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

ストレージクラス

Premium や Standard など、さまざまなレベルのストレージを指定するには、ストレージクラスを作成します。

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

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

ストレージクラス	説明
`managed-csi`	Azure Standard SSD ローカル冗長ストレージ (LRS) を使用して、マネージドディスクを作成します。解放ポリシーによって、基礎となる Azure ディスクを使用していた永続ボリュームが削除されるときに、ディスクも確実に削除されます。ストレージクラスは、永続ボリュームを拡張可能になるように構成します。永続ボリューム要求を編集して、新しいサイズを指定できます。 Kubernetes バージョン 1.29 以降、複数の可用性ゾーンにデプロイされた Azure Kubernetes Service (AKS) クラスターでは、このストレージクラスは Azure Standard SSD ゾーン冗長ストレージ (ZRS) を利用してマネージドディスクを作成します。
`managed-csi-premium`	Azure Premium ローカル冗長ストレージ (LRS) を使用して、マネージドディスクを作成します。ここでも、解放ポリシーによって、基礎となる Azure ディスクを使用していた永続ボリュームが削除されるときに、ディスクも確実に削除されます。同様に、このストレージクラスを使用して、永続ボリュームを拡張できます。 Kubernetes バージョン 1.29 以降、複数の可用性ゾーンにデプロイされた Azure Kubernetes Service (AKS) クラスターでは、このストレージクラスは Azure Premium ゾーン冗長ストレージ (ZRS) を利用してマネージドディスクを作成します。
`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 ストレージコンテナーは、それを使用していた永続ボリュームが削除されるときに、確実に削除されます。

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

重要

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

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

Kubernetes バージョン 1.29 以降では、複数の可用性ゾーンに Azure Kubernetes Service (AKS) クラスターをデプロイすると、AKS はゾーン冗長ストレージ (ZRS) を利用して、組み込みのストレージクラス内にマネージドディスクを作成します。 ZRS により、ユーザーが選んだリージョン内の複数の Azure 可用性ゾーン間での Azure マネージドディスクの同期レプリケーションが保証されます。この冗長性戦略により、アプリケーションの回復性が強化され、データセンターの障害からデータが保護されます。

ただし、ゾーン冗長ストレージ (ZRS) は、ローカル冗長ストレージ (LRS) と比べてコストが高くなる点に注意してください。コストの最適化が優先される場合は、skuname パラメーターを LRS に設定して新しいストレージクラスを作成できます。その後、永続ボリューム要求 (PVC) で新しいストレージクラスを使用できます。

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

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 に関する記事を参照してください。

永続ボリューム要求

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

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

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

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

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

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

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

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

次の例の 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) でのアプリケーションのストレージオプション

既定の OS ディスクのサイズ設定

エフェメラル OS ディスク

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

ボリューム

Azure ディスク

Azure Files

Azure NetApp Files

Azure Blob Storage

ボリュームの種類

emptyDir

secret

configMap

永続ボリューム

ストレージクラス

永続ボリューム要求

次のステップ

その他のリソース

次の方法で共有

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

既定の OS ディスクのサイズ設定

エフェメラル OS ディスク

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

ボリューム

Azure ディスク

Azure Files

Azure NetApp Files

Azure Blob Storage

ボリュームの種類

emptyDir

secret

configMap

永続ボリューム

ストレージ クラス

永続ボリューム要求

次のステップ

その他のリソース

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

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

ストレージクラス