次の方法で共有

Kubernetes クラスターのストレージ オプション

この記事では、Amazon Elastic Kubernetes Service (EKS) と Azure Kubernetes Service (AKS) のストレージ機能を比較します。 また、AKS 上のワークロード データのストレージ オプションについても説明します。

注記

この記事は、Amazon EKS に精通している専門家が Azure Kubernetes Service (AKS) を理解するのに役立つ一連の記事の一部です。

Amazon EKS ストレージ オプション

Amazon EKS は、データストレージを必要とするアプリケーションにさまざまな種類のストレージボリュームを提供します。 これらのボリュームは、一時的かつ長期的なストレージに使用できます。

エフェメラル ボリューム

一時的なローカル ボリュームを必要とするが、再起動後にデータを保持する必要がないアプリケーションの場合は、エフェメラル ボリュームを使用します。 Kubernetes では、 emptyDir、 ConfigMap、 downwardAPI、 シークレット、 hostPath など、さまざまな種類のエフェメラル ボリュームがサポートされています。 コスト効率とパフォーマンスを確保するには、最適なホスト ボリュームを選択します。 Amazon EKS では、 gp3 をホスト ルート ボリュームとして使用できます。これは、gp2 ボリューム未満のコストです。

EC2 インスタンスに一時的なブロックレベルのストレージを提供する Amazon EC2 インスタンス ストアを使用することもできます。 これらのボリュームはホストに物理的にアタッチされ、インスタンスの有効期間中にのみ存在します。 Kubernetes でローカル ストア ボリュームを使用するには、Amazon EC2 ユーザー データを使用してディスクをパーティション分割、構成、フォーマットする必要があります。

永続ボリューム

通常、Kubernetes を使用してステートレス アプリケーションを実行しますが、永続的なデータ ストレージが必要な場合があります。 Kubernetes 永続ボリュームを使用すると、ポッドとは別にデータを格納して、特定のポッドの有効期間を超えてデータを保持できます。 Amazon EKS では、Amazon EBS、 Amazon Elastic File System (EFS)、 Amazon FSx for Lustre、Amazon FSx forNetApp ONTAP など、永続ボリュームのさまざまな種類のストレージ オプションがサポートされています。

ブロックレベルのストレージと、データベースとスループットを集中的に使用するアプリケーションには 、Amazon EBS ボリュームを使用します。 Amazon EKS ユーザーは、最新世代のブロック ストレージ gp3 を使用して、価格とパフォーマンスのバランスを取ることができます。 パフォーマンスの高いアプリケーションでは、 io2 Block Express ボリュームを使用できます。

Amazon EFS は、複数のコンテナーとノード間で共有できるサーバーレスのエラスティック ファイル システムです。 ファイルが追加または削除されると、自動的に拡大および縮小されるため、容量計画が不要になります。 Amazon EFS Container Storage Interface (CSI) ドライバーは、Amazon EFS と Kubernetes を統合します。

Amazon FSx for Lustre は、高パフォーマンスの並列ファイル ストレージを提供します。 この種類のストレージは、高スループットと待機時間の短い操作を必要とするシナリオに使用します。 このファイルストレージを Amazon S3 データリポジトリにリンクして、大規模なデータセットを格納できます。 Amazon FSx for NetApp ONTAP は、NetApp の ONTAP ファイル システム上に構築されたフル マネージドの共有ストレージ ソリューションです。

ストレージ構成を最適化し、バックアップとスナップショットを管理するには、 AWS Compute Optimizer や Velero などのツールを使用します。

AKS ストレージ オプション

AKS で実行されるアプリケーションでは、データの格納と取得が必要になる場合があります。 一部のアプリケーション ワークロードでは、不要な空のノードでローカルの高速ストレージを使用できます。 ただし、他のアプリケーション ワークロードでは、Azure プラットフォーム内のより定期的なデータ ボリュームに保持されるストレージが必要です。 複数のポッドに以下が必要になる場合があります。

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

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

ボリュームの種類

Kubernetes ボリュームは、情報を格納および取得するための従来のディスク以上のものを表します。 Kubernetes ボリュームを使用して、ポッドにデータを注入し、そのコンテナーが利用できるようにすることもできます。

Kubernetes の一般的なボリュームの種類には、 emptyDirs、 シークレット、 ConfigMap が含まれます。

EmptyDirs

emptyDir ボリュームを定義するポッドの場合、ポッドがノードに割り当てられるとボリュームが作成されます。 名前が示すように、emptyDir ボリュームは最初は空です。 ポッド内のすべてのコンテナーは、emptyDir ボリューム内の同じファイルの読み取りと書き込みを行うことができますが、このボリュームは各コンテナー内の同じパスまたは異なるパスにマウントできます。 何らかの理由でポッドがノードから削除されると、emptyDir 内のデータは完全に削除されます。

シークレット

シークレットは、パスワード、トークン、キーなど、少量の機密データを保持するオブジェクトです。 シークレットを使用しない場合、この情報はポッドの仕様またはコンテナー イメージに含まれます。 シークレットを使用すると、機密データをアプリケーション コードに直接埋め込む必要がなくなります。 シークレットは、それらを使用するポッドとは別に作成できます。 この方法により、ポッドの作成、表示、編集時にシークレットとそのデータが公開されるリスクが軽減されます。 Kubernetes とクラスターで実行されるアプリケーションは、機密データが不揮発性ストレージに書き込まれないようにするなど、シークレットに関する追加の予防措置を講じる可能性があります。 シークレットは ConfigMaps に似ていますが、機密データを格納するように特別に設計されています。

シークレットは、次の目的で使用できます。

Kubernetes コントロール プレーンでは、 ブートストラップ トークン シークレットなどのシークレットも使用して、ノードの登録を自動化します。

ConfigMaps

ConfigMap は、キーと値のペアに非コンフィデンシャル データを格納するために使用する Kubernetes オブジェクトです。 ポッド は、環境変数、コマンドライン引数、または ボリューム内の構成ファイルとして ConfigMap を使用できます。 ConfigMap を使用すると、環境固有の構成を コンテナー イメージから切り離すことができます。これにより、アプリケーションを簡単に移植できます。

ConfigMap では、秘密や暗号化は提供されません。 機密データを格納する場合は、ConfigMap ではなく シークレット を使用するか、他のパートナー ツールを使用してデータをプライベートに保ちます。

ConfigMap を使用して、アプリケーション コードとは別に構成データを設定できます。 たとえば、開発用にコンピューター上で実行し、実際のトラフィックを処理するためにクラウドで実行するアプリケーションを開発できます。 DATABASE_HOSTという名前の環境変数を検索するコードを記述できます。 ローカルで、その変数を localhost に設定します。 クラウドで、データベース コンポーネントをクラスターに公開する Kubernetes サービス を参照するように設定します。 この方法では、クラウドで実行されるコンテナー イメージをフェッチし、必要に応じて同じコードをローカルでデバッグできます。

永続ボリューム

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

Azure ディスク ストレージと Azure Files のどちらを使用するかを決定するには、アプリケーションで同時データ アクセスが必要か、特定のパフォーマンスレベルが必要かを検討します。

AKS クラスター内の永続ボリュームの図。

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

重要

Windows ポッドと Linux ポッドは、オペレーティング システムが異なるファイル システムをサポートしているため、永続ボリュームを共有できません。

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

ストレージ クラス

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

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

Azure Container Storage を使用するクラスターには、acstor-<storage-pool-name>と呼ばれる追加のストレージ クラスがあります。 内部ストレージ クラスも作成されます。

CSI ドライバーを使用するクラスターでは、次の追加のストレージ クラスが作成されます。

ストレージ クラス 説明
managed-csi Azure Standard SSD とローカル冗長ストレージ (LRS) を使用してマネージド ディスクを作成します。 再利用ポリシーにより、基になる Azure ディスクは、それを使用した永続ボリュームが削除されたときに削除されます。 ストレージ クラスは、永続ボリュームを拡張可能になるように構成します。 永続ボリューム要求を編集して、新しいサイズを指定できます。

Kubernetes バージョン 1.29 以降では、このストレージ クラスは Standard SSD とゾーン冗長ストレージ (ZRS) を使用して、複数の可用性ゾーンにデプロイされる AKS クラスターのマネージド ディスクを作成します。
managed-csi-premium AZURE Premium SSD と LRS を使用してマネージド ディスクを作成します。 再利用ポリシーにより、基になる Azure ディスクは、それを使用した永続ボリュームが削除されたときに削除されます。 このストレージ クラスを使用すると、永続ボリュームを拡張できます。

Kubernetes バージョン 1.29 以降の場合、このストレージ クラスは、ZRS で Premium SSD を使用して、複数の可用性ゾーンにデプロイされる AKS クラスター用のマネージド ディスクを作成します。
azurefile-csi Standard SSD ストレージを使用して Azure ファイル共有を作成します。 解放ポリシーを使用すると、基礎となる Azure ファイル共有は、それを使用していた永続ボリュームが削除されるときに、確実に削除されます。
azurefile-csi-premium Premium SSD ストレージを使用して Azure ファイル共有を作成します。 解放ポリシーを使用すると、基礎となる Azure ファイル共有は、それを使用していた永続ボリュームが削除されるときに、確実に削除されます。
azureblob-nfs-premium Premium SSD ストレージを使用して Blob Storage コンテナーを作成し、ネットワーク ファイル システム (NFS) v3 プロトコル経由で接続します。 再利用ポリシーを使用すると、基になる Blob Storage コンテナーは、それを使用した永続ボリュームが削除されたときに削除されます。
azureblob-fuse-premium Premium SSD ストレージを使用して Blob Storage コンテナーを作成し、BlobFuse 経由で接続します。 再利用ポリシーを使用すると、基になる Blob Storage コンテナーは、それを使用した永続ボリュームが削除されたときに削除されます。

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

重要

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

default クラスは、managed-csi クラスと同じです。

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

ただし、ZRS のコストは LRS を超えています。 コストの最適化が優先される場合は、 skuname パラメーターが LRS に設定された新しいストレージ クラスを作成できます。 その後、永続ボリューム要求で新しいストレージ クラスを使用できます。

kubectlを使用して、他のニーズに合わせてストレージ クラスを作成できます。 次の例では、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」を参照してください。

永続ボリューム要求

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

ポッド定義には、ボリュームがポッドに接続した後のボリューム マウントが含まれます。

AKS クラスター内の永続ボリューム要求の図。

ストレージを要求するポッドに使用可能なストレージ リソースが割り当てられると、永続ボリュームは永続ボリューム要求に バインド されます。 各永続ボリュームは、専用ストレージを確保するために、1 つの永続ボリューム要求に関連付けられます。

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

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
...

エフェメラル OS ディスク

既定では、仮想マシン (VM) のオペレーティング システム ディスクが Azure Storage に自動的にレプリケートされ、VM が別のホストに再配置されるときにデータが失われるのを防ぎます。 ただし、コンテナーはローカルの状態を保持するように設計されていないため、この動作によって、限られた値と欠点が提供されます。 これらの欠点には、ノードのプロビジョニングが遅く、読み取りと書き込みの待機時間が長くなることがあります。

これに対し、エフェメラル OS ディスクは、一時ディスクのようにホスト コンピューターにのみ格納されます。 この構成により、読み取りと書き込みの待機時間が短縮され、ノードのスケーリングとクラスターのアップグレードが高速化されます。

OS に 対して Azure マネージド ディスク を要求しない場合、AKS では、特定のノード プール構成に対して可能であれば、一時的な OS ディスクが既定で使用されます。

サイズ要件と推奨事項については、 Azure VM のエフェメラル OS ディスクに関するページを参照してください。 次のサイズ変更に関する考慮事項を検討してください。

  • 既定の OS ディスク サイズが 100 GiB の SKU Standard_DS2_v2 AKS の既定の VM サイズを使用する場合、既定の VM サイズはエフェメラル OS ディスクをサポートしますが、キャッシュ サイズは 86 GiB のみです。 指定しない場合、この構成は既定でマネージド ディスクに設定されます。 エフェメラル OS ディスクを要求すると、検証エラーが発生します。

  • 60 GiB OS ディスクで同じStandard_DS2_v2 SKU を要求した場合、この構成は既定でエフェメラル OS ディスクになります。 要求された 60 GiB のサイズは、最大キャッシュ サイズ 86 GiB より小さくなります。

  • 100 GB の OS ディスクを持つ Standard_D8s_v3 SKU を選択した場合、この VM サイズはエフェメラル OS ディスクをサポートし、キャッシュ サイズは 200 GiB です。 OS ディスクの種類を指定しない場合、ノード プールは既定でエフェメラル OS ディスクを受け取ります。

最新世代の VM シリーズには専用キャッシュがないため、一時ストレージのみが含まれます。

  • 既定の OS ディスク サイズが 100 GiB の Standard_E2bds_v5 VM サイズを選択した場合、VM はエフェメラル OS ディスクをサポートしますが、一時ストレージは 75 GB のみです。 指定しない場合、この構成は既定でマネージド OS ディスクに設定されます。 エフェメラル OS ディスクを要求すると、検証エラーが発生します。

  • 60 GiB OS ディスクで同じStandard_E2bds_v5 VM サイズを要求する場合、この構成は既定でエフェメラル OS ディスクになります。 要求したサイズ 60 GiB は、最大一時ストレージの 75 GiB より小さくなります。

  • 100 GiB OS ディスクを持つ Standard_E4bds_v5 SKU を選択した場合、この VM サイズはエフェメラル OS ディスクをサポートし、150 GiB の一時ストレージを備えています。 OS ディスクの種類を指定しない場合、Azure は一時的な OS ディスクをノード プールにプロビジョニングします。

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

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

ボリューム

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

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

注記

VM SKU によっては、Azure ディスク CSI ドライバーに各ノードのボリューム制限がある場合があります。 16 コアなど、一部の高パフォーマンス VM では、ノードあたり 64 ボリュームが制限されます。 VM SKU あたりの制限を特定するには、各 VM SKU の [最大データ ディスク 数] 列を確認します。 VM SKU とそれに対応する容量制限の一覧については、 汎用 VM のサイズに関する記事を参照してください。

Azure Files と Azure NetApp Files の間で決定するには、 Azure Files と Azure NetApp Files の比較に関するページを参照してください。

Azure ディスク ストレージ

既定では、AKS クラスターには、managed-csi ストレージを使用する事前に作成されたmanaged-csi-premiumとストレージ クラスが付属しています。 Amazon EBS と同様に、これらのクラスでは、ポッド アクセス用にノードに接続されるマネージド ディスクまたはブロック デバイスが作成されます。

ディスク クラスを使用すると、 静的 ボリュームと 動的 ボリュームの両方のプロビジョニングが可能になります。 回収ポリシーにより、永続ボリュームを使用してディスクが削除されます。 ディスクを展開するには、永続ボリューム要求を編集します。

これらのストレージ クラスでは 、LRS で Azure マネージド ディスクが使用されます。 LRS のデータには、Azure プライマリ リージョンの 1 つの物理的な場所に 3 つの同期コピーがあります。 LRS は最もコストのかからないレプリケーション オプションですが、データセンターの障害に対する保護は提供されません。 ZRS マネージド ディスクを使用するカスタム ストレージ クラスを定義できます。

ZRS は、リージョン内の 3 つの Azure 可用性ゾーン間で Azure マネージド ディスクを同期的にレプリケートします。 各可用性ゾーンは、独立した電源、冷却、ネットワークを備える個別の物理的な場所です。 ZRS ディスクは、1 年間に少なくとも 99.99999999999% の持続性を提供します。 ZRS マネージド ディスクは、別の 可用性ゾーン内の VM によって接続できます。 ZRS ディスクは、すべての Azure リージョンで使用できるわけではありません。 詳細については、可用性を 向上させるための Azure ディスクの ZRS オプションに関するページを参照してください。

データ損失のリスクを軽減するには、 AKS バックアップ を使用して、ディスク ストレージ データの定期的なバックアップまたはスナップショットを作成します。 または、組み込みのスナップショット テクノロジを持つ Velero や Azure Backup などのパートナー ソリューションを使用できます。

Azure ディスク ストレージを使用して、Kubernetes DataDisk リソースを作成できます。 次の種類のディスクを使用できます。

ヒント

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

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

Premium SSD v2 ディスク

Premium SSD v2 ディスク は、入力/出力 (I/O) の負荷の高いエンタープライズ ワークロード向けに設計されています。 一貫性のあるミリ秒未満のディスク待機時間、1 秒あたりの高い入出力操作 (IOPS)、高スループットが提供されます。 Premium SSD v2 ディスクのパフォーマンス (容量、IOPS、スループット) は、いつでも個別に構成できます。 そのため、パフォーマンスのニーズを満たしながら、コスト効率を簡単に向上させることができます。 Azure Premium SSD v2 ディスクを使用するように新規または既存の AKS クラスターを構成する方法の詳細については、 AKS での Premium SSD v2 ディスクの使用に関するページを参照してください。

超高性能ディスクストレージ

Ultra Disk Storage は、Azure VM の高スループット、高 IOPS、および一貫した低待機時間のディスク ストレージを提供する Azure マネージド ディスク層です。 データ集中型およびトランザクション負荷の高いワークロードには、Ultra Disk Storage を使用します。 他のディスク ストレージ SKU や Amazon EBS と同様に、Ultra Disk Storage は一度に 1 つのポッドをマウントし、同時アクセスを提供しません。

AKS クラスターで Ultra Disk Storage を有効にするには、フラグ --enable-ultra-ssdを使用します。

Ultra Disk Storage の 制限事項に注意し、互換性のある VM サイズを選択してください。 Ultra Disk Storage には LRS レプリケーションがあります。

独自のキーの使用 (BYOK)

Azure は、AKS クラスターの OS ディスクとデータ ディスクを含め、保存時のマネージド ディスク内のすべてのデータを暗号化します。 規定では、データは Microsoft のマネージド キーで暗号化されます。 暗号化キーをより詳細に制御するために、カスタマー マネージド キーを提供して、AKS クラスターの OS ディスクとデータ ディスクの両方に保存時の暗号化を提供できます。 詳細については、 AKS での Azure マネージド ディスクの BYOK と Azure ディスク ストレージのサーバー側暗号化に関するページを参照してください。

Azure Files

ディスク ストレージはボリュームへの同時アクセスを提供できませんが、 Azure Files を使用して、Azure Storage によってサポートされているサーバー メッセージ ブロック (SMB) バージョン 3.1.1 共有または NFS バージョン 4.1 共有をマウントできます。 このプロセスでは、Amazon EFS に似たネットワーク接続ストレージが提供されます。 Azure Files には、次の 2 つのストレージ オプションがあります。

  • Azure Files Standard ストレージは、通常のハード ディスク ドライブ (HDD) を使用してファイル共有をバックアップします。

  • Azure Files Premium ストレージは、高パフォーマンスのソリッド ステート ドライブ (SSD) を使用してファイル共有をバックアップします。 Premium のファイル共有の最小サイズは 100 GB です。

Azure Files には、障害が発生した場合にデータを保護するための次のストレージ アカウント レプリケーション オプションがあります。

Azure Files のコストを最適化するには、 Azure Files 容量予約を購入します。

Azure NetApp ファイルズ

Azure NetApp Files は、Azure 上で実行され、NFS (NFSv3 または NFSv4.1)、SMB、デュアル プロトコル (NFSv3、SMB、NFSv4.1、SMB) ボリュームを使用してボリュームをサポートする、エンタープライズ クラスの高パフォーマンスの従量制課金ファイル ストレージ サービスです。 Kubernetes ユーザーには、Azure NetApp Files ボリュームを Kubernetes のワークロードに使用するために以下の 2 つのオプションがあります。

  • Azure NetApp Files ボリュームを静的に作成します。 Azure CLI または Azure portal を使用して、AKS の外部でボリュームを作成します。 作成後、これらのボリュームは、 PersistentVolumeを作成することによって Kubernetes に公開されます。 静的に作成された Azure NetApp Files ボリュームには、多くの制限があります。 たとえば、展開することはできないため、オーバープロビジョニングする必要があります。 ほとんどのユース ケースでは、静的に作成されたボリュームは推奨されません。

  • Kubernetes を使用して Azure NetApp Files ボリュームを動的に作成します。 これは、Astra Trident を使用して Kubernetes を介して複数のボリュームを直接作成する場合に推奨される方法です。 Astra Trident は、CSI に準拠した動的ストレージ オーケストレーターであり、Kubernetes を通じてボリュームをネイティブにプロビジョニングするのに役立ちます。

詳細については、「 AKS 用の Azure NetApp Files の構成」を参照してください。

ブロブストレージ

Blob Storage CSI ドライバーは、AKS が Blob Storage のライフサイクルを管理するために使用する CSI 仕様に準拠したドライバーです。 CSI は、Kubernetes のコンテナー化されたワークロードに任意のブロックおよびファイル ストレージ システムを公開する標準です。

AKS がプラグインを記述、デプロイ、および反復処理できるように、CSI を採用して使用します。プラグインは、新しいストレージ システムを公開するか、Kubernetes の既存のストレージ システムを改善します。 AKS の CSI ドライバーでは、Kubernetes のコア コードを変更し、リリース サイクルを待つ必要がなくなります。

Blob Storage をファイル システムとしてコンテナーまたはポッドにマウントする場合、次のような大量の非構造化データを処理するアプリケーションで使用できます。

  • ログ ファイル データ。
  • 画像、ドキュメント、ストリーミング ビデオまたはオーディオ。
  • ディザスター リカバリー データ。

アプリケーションは、 BlobFuse または NFS 3.0 プロトコルを使用して、オブジェクト ストレージ上のデータにアクセスできます。 Blob Storage CSI ドライバーを導入する前に、唯一のオプションは、サポートされていないドライバーを手動でインストールして、AKS で実行されるアプリケーションから Blob Storage にアクセスすることでした。 AKS で有効になっている Blob Storage CSI ドライバーには、azureblob-fuse-premium と azureblob-nfs-premium の 2 つの組み込みストレージ クラスがあります。

CSI ドライバーがサポートされている AKS クラスターを作成するには、 AKS の CSI ドライバーを参照してください。 詳細については、「 Azure Files、Blob Storage、Azure NetApp Files と NFS へのアクセスを比較する」を参照してください。

Azure HPC Cache

HPC Cache を使用すると、パフォーマンスの高いコンピューティング タスクのためにデータへのアクセスが高速化され、クラウド ソリューションのスケーラビリティが提供されます。 このストレージ ソリューションを選択する場合は、 HPC Cache をサポートするリージョンに AKS クラスターをデプロイしてください。

NFS サーバー

共有 NFS アクセスの場合は、Azure Files または Azure NetApp Files を使用する必要があります。 ボリューム をエクスポートする NFS サーバーを Azure VM 上に作成 することもできます。

このオプションでは、静的プロビジョニングのみがサポートされます。 NFS 共有をサーバーに手動でプロビジョニングする必要があります。 AKS で NFS 共有を自動的にプロビジョニングすることはできません。

このソリューションは、サービスとしてのプラットフォーム (PaaS) ではなく、サービスとしてのインフラストラクチャ (IaaS) に基づいています。 OS の更新、高可用性、バックアップ、ディザスター リカバリー、スケーラビリティなど、NFS サーバーを管理します。

Azure コンテナー ストレージ

Azure Container Storage は、コンテナー用にネイティブに構築されたクラウドベースのボリューム管理、デプロイ、オーケストレーション サービスです。 Kubernetes と統合されるため、Kubernetes クラスターで実行されるステートフル アプリケーションのデータを格納するために永続ボリュームを動的かつ自動的にプロビジョニングできます。

Azure Container Storage は、実際のデータ ストレージに既存の Azure Storage オファリングを使用し、コンテナー用に意図的に構築されたボリューム オーケストレーションと管理ソリューションを提供します。 Azure Container Storage では、次のバッキング ストレージがサポートされています。

  • Azure ディスク: ストレージ SKU と構成の詳細な制御を提供します。 Azure ディスクは、階層 1 と汎用データベースに適しています。

  • エフェメラル ディスク: AKS ノード (NVMe または一時 SSD) でローカル ストレージ リソースを使用します。 エフェメラル ディスクは、データ持続性の要件がないアプリケーションや、データ レプリケーションのサポートが組み込まれているアプリケーションに適しています。 AKS は、AKS ノード上の使用可能なエフェメラル ストレージを検出し、ボリューム デプロイ用に取得します。

  • Elastic SAN: オンデマンドのフル マネージド リソースをプロビジョニングします。 Elastic SAN は、汎用データベース、ストリーミングおよびメッセージング サービス、継続的インテグレーションおよび継続的デリバリー環境、およびその他の階層 1 または階層 2 のワークロードに適しています。 複数のクラスターが 1 つの記憶域ネットワーク (SAN) に同時にアクセスできます。 ただし、永続ボリュームは、一度に 1 つのコンシューマーによってのみアタッチできます。

以前は、コンテナー用のクラウド ストレージを提供するために、IaaS 中心のワークロード向けのストレージ サービスを適応させるために、個々の CSI ドライバーが必要でした。 この方法により、運用上のオーバーヘッドが発生し、アプリケーションの可用性、スケーラビリティ、パフォーマンス、使いやすさ、コストに関連する問題のリスクが高まります。

Azure Container Storage は、Kubernetes 用のコンテナー ストレージ機能を提供するオープンソース ソリューションである OpenEBS から派生しています。 Azure Container Storage は、Kubernetes 環境のマイクロサービス ベースのストレージ コントローラーを介してマネージド ボリューム オーケストレーション ソリューションを提供します。 この機能により、真のコンテナー ネイティブ ストレージが有効になります。

Azure Container Storage は、次のシナリオに適しています。

  • VM からコンテナーへのイニシアティブを加速: Azure Container Storage は、以前は VM でしか使用できなかった Azure ブロック ストレージ オファリングの制限をなくし、コンテナーで使用できるようにします。 このストレージにはエフェメラル ディスク ストレージが含まれており、Cassandra などのワークロードの待機時間が非常に短くなります。 また、ネイティブの iSCSI と共有プロビジョニングされたターゲットを提供する Elastic SAN も含まれています。

  • Kubernetes を使用してボリューム管理を簡素化する: Azure Container Storage は、Kubernetes コントロール プレーンを介してボリューム オーケストレーションを提供します。 この機能により、異なるコントロール プレーンを切り替えることなく、Kubernetes 内のボリュームのデプロイと管理が簡素化されます。

  • 総保有コストを削減します。 コスト効率を向上させるには、ポッドまたはノードごとにサポートされている永続ボリュームのスケールを増やします。 プロビジョニングに必要なストレージ リソースを減らすには、ストレージ リソースを動的に共有します。 記憶域プール自体のスケールアップ サポートは含まれていません。

Azure Container Storage の主な利点は次のとおりです。

  • ステートフル ポッドを迅速にスケールアウトする: Azure Container Storage は、NVMe-oF や iSCSI などのネットワーク ブロック ストレージ プロトコルを使用して永続ボリュームをマウントします。 この機能により、永続ボリュームの高速な接続とデタッチが保証されます。 小規模なリソースを開始し、必要に応じてデプロイして、初期化中または運用環境でアプリケーションが不足したり中断されたりしないようにすることができます。 ポッドがクラスター全体で再び発生する場合は、アプリケーションの回復性を維持するために、関連付けられている永続ボリュームを新しいポッドに迅速に移動する必要があります。 リモート ネットワーク プロトコルを使用することで、Azure Container Storage はポッドのライフサイクルと緊密に連携し、AKS 上で回復性の高い大規模なステートフル アプリケーションをサポートします。

  • ステートフル ワークロードのパフォーマンスを向上させる: Azure Container Storage を使用すると、RDMA 経由の NVMe-oF を使用して、優れた読み取りパフォーマンスを実現し、ディスクに近い書き込みパフォーマンスを実現できます。 この機能を使用すると、階層 1 の I/O 集中型、汎用、スループットに依存するワークロード、開発/テスト ワークロードなど、さまざまなコンテナー ワークロードのパフォーマンス要件をコスト効率に優れた方法で満たすことができます。 永続ボリュームのアタッチとデタッチの時間を短縮し、ポッドのフェールオーバー時間を最小限に抑えます。

  • Kubernetes ネイティブ ボリュームの調整: さまざまなコントロール プレーン操作に対してツールセットを切り替えることなく、 kubectl コマンドを使用して、ストレージ プールと永続ボリュームを作成し、スナップショットをキャプチャし、ボリュームのライフサイクル全体を管理します。

パートナー ソリューション

Amazon EKS と同様に、AKS は Kubernetes の実装であり、パートナーの Kubernetes ストレージ ソリューションを統合できます。 Kubernetes のパートナー ストレージ ソリューションの例を次に示します。

  • Rook は、Azure Storage 管理者タスクを自動化することで、分散ストレージ システムを自己管理ストレージ サービスに変換します。 Rook は、各ストレージ プロバイダーの Kubernetes オペレーター経由でサービスを提供します。

  • GlusterFS は、一般的な既製ハードウェアを使用して、データ負荷が高く帯域幅を集中的に消費するタスク向けの大規模な分散ストレージ ソリューションを作成する、無料でオープンソースのスケーラブルなネットワーク ファイル システムです。

  • Ceph は、汎用ハードウェア コンポーネントから構築された 1 つのクラスターからオブジェクト、ブロック、およびファイル インターフェイスを持つ信頼性の高いスケーラブルな統合ストレージ サービスを提供します。

  • MinIO マルチクラウド オブジェクト ストレージを使用すると、企業は任意のクラウド上に AWS S3 と互換性のあるデータ インフラストラクチャを構築できます。 データとアプリケーションに一貫性のある移植可能なインターフェイスを提供します。

  • Portworx は、Kubernetes プロジェクトとコンテナー ベースのイニシアティブのためのエンド ツー エンドのストレージとデータの管理ソリューションです。 Portworx は、コンテナーの詳細なストレージ、ディザスター リカバリー、データ セキュリティ、マルチクラウド移行を提供します。

  • Quobyte は、パフォーマンスの高いファイルとオブジェクトのストレージを提供します。このストレージは、パフォーマンスのスケーリング、大量のデータの管理、管理の簡略化を行うために、任意のサーバーまたはクラウドにデプロイできます。

  • Ondat は、あらゆるプラットフォームで一貫したストレージ 層を提供します。 ストレージ レイヤーを管理しなくても、Kubernetes 環境でデータベースまたは永続的なワークロードを実行できます。

Kubernetes ストレージに関する考慮事項

Amazon EKS または AKS のストレージ ソリューションを選択するときは、次の要因を考慮してください。

ストレージ クラスのアクセス モード

Kubernetes バージョン 1.21 以降では、既定では AKS および Amazon EKS ストレージ クラスでは CSI ドライバー のみが使用されます。

サービスが異なると、アクセス モードが異なるストレージ クラスがサポートされます。

サービス リードライトワンス ReadOnlyMany ReadWriteMany
Azure ディスク ストレージ X
Azure Files X X X
Azure NetApp ファイルズ X X X
NFS サーバー X X X
HPCキャッシュ X X X

動的プロビジョニングと静的プロビジョニング

ボリュームを動的にプロビジョニング して、永続ボリュームを静的に作成する管理オーバーヘッドを軽減します。 ポッドを削除するときに未使用のディスクを排除するために、適切な再利用ポリシーを設定します。

バックアップ

永続的なデータをバックアップするツールを選択します。 ツールは、スナップショット、 Azure Backup、 Velero または Kastenなどのストレージの種類に適合する必要があります。

コスト最適化

Azure Storage のコストを最適化するには、サービスでサポートされている場合は Azure 予約 を使用します。 詳細については、「 Kubernetes クラスターのコスト管理」を参照してください。

寄稿者

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要著者:

その他の共同作成者:

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ