次の方法で共有

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

  • [アーティクル]

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

複数のポッドでは、次のことが必要になる場合があります。

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

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

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

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

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

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

configMap

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

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

  1. Kubernetes API を使用して ConfigMap を作成する。
  2. ポッドやデプロイを定義する際に ConfigMap を要求する。
    • ConfigMaps は、指定した名前空間内に保存され、同じ名前空間内のポッドからのみアクセスできます。

永続ボリューム

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

次の Azure Storage サービスを使用して、永続ボリュームを提供できます。

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

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

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

重要

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

データへのブロック レベルのアクセスのためにフル マネージド ソリューションが必要な場合は、CSI ドライバーの代わりに Azure コンテナー ストレージの使用を検討してください。 Azure コンテナー ストレージは Kubernetes と統合されており、永続ボリュームの動的および自動プロビジョニングが可能になります。 Azure コンテナー ストレージでは、バッキング ストレージとして Azure Disks、エフェメラル ディスク、Azure Elastic SAN (プレビュー) がサポートされており、Kubernetes クラスター上で実行されているステートフル アプリケーションに柔軟性とスケーラビリティが提供されます。

ストレージ クラス

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

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

Azure コンテナー ストレージを使用するクラスターの場合、acstor-<storage-pool-name> という追加のストレージ クラスが表示されます。 内部ストレージ クラスも作成されます。

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 のストレージに関する考慮事項を参照してください。

Azure コンテナー ストレージの詳細については、次の記事を参照してください。

CSI ドライバーの使用の詳細については、次の記事を参照してください。

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