Azure Arc で有効になっている AKS 内のアプリケーションのストレージ オプション
適用対象: AKS on Azure Stack HCI 22H2、Windows Server 上の AKS
Azure Arc によって有効になっている Azure Kubernetes Service を使用して AKS デプロイで実行されるアプリケーションでは、データの格納と取得が必要になる場合があります。 一部のアプリケーション ワークロードでは、ポッドが削除されると、不要なノード上のローカルの高速ストレージをデータで使用できます (Kubernetes は "ポッド" を使用してアプリケーションのインスタンスを実行します)。
他のワークロードでは、より定期的なデータ ボリュームに保持されるストレージが必要になる場合があります。 複数のポッドが同じデータ ボリュームを共有する必要がある場合や、ポッドが別のノードに再スケジュールされている場合は、データ ボリュームを再アタッチすることが必要になる場合があります。 また、ポッドに機密データまたはアプリケーション構成情報が含まれている場合は、ストレージ オプションが必要になる場合があります。
この記事では、AKS Arc のアプリケーションにストレージを提供する主な概念について説明します。
- Volumes
- 永続ボリューム
- ストレージ クラス
- 永続ボリューム要求 (PVC)
ボリューム
多くの場合、アプリケーションではデータの格納と取得を行う必要があります。 通常、Kubernetes では、破棄できる一時的なリソースとして個々のポッドが扱われるため、アプリケーションでデータを使用したり保存したりするためのさまざまなアプローチが提供されています。 ボリュームは、ポッドにまたがって、またアプリケーションのライフサイクルを通してデータを格納、取得、永続化する方法を表します。
Kubernetes では、ボリュームは、情報が格納および取得される従来の情報以上のものを表すことができます。 Kubernetes のボリュームは、コンテナーで使用するために、ポッドにデータを挿入する手段としても使用できます。 Kubernetes の一般的なボリュームの種類は次のとおりです。
emptyDir - 通常、このボリュームはポッド用の一時的な領域として使用されます。 ポッド内のすべてのコンテナーが、このボリューム上のデータにアクセスできます。 この種類のボリュームに書き込まれたデータはポッドの有効期間しか保持されません。ポッドが削除されると、ボリュームは削除されます。 一般的にこのボリュームは基礎となるローカル ノードのディスク ストレージを使用しますが、ノードのメモリ内のみに存在することもできます。
secret - このボリュームは、パスワードなどの機密データをポッドに含めるために使用されます。 まず Kubernetes API を使用してシークレットを作成します。 ポッドまたはデプロイを定義するとき、特定のシークレットを要求できます。 シークレットは、それを必要とするスケジュールされたポッドを持つノードにのみ提供され、シークレットはディスクに書き込まれず、 tmpfs に格納されます。 シークレットを必要とするノード上の最後のポッドが削除されると、そのシークレットはノードの tmpfs から削除されます。 シークレットは、指定した名前空間内に格納され、同じ名前空間内のポッドによってのみアクセスできます。
configMap - この種類のボリュームは、アプリケーション構成情報など、キーと値のペアのプロパティをポッドに挿入するために使用されます。 コンテナー イメージ内にアプリケーション構成情報を定義する代わりに、Kubernetes リソースとして定義すると、簡単に更新でき、デプロイ時にポッドの新しいインスタンスに適用できます。 シークレットの使用と同様に、最初に Kubernetes API を使用して ConfigMap を作成します。 この ConfigMap は、ポッドまたはデプロイを定義するときに要求できます。 ConfigMaps は特定の名前空間内に格納され、同じ名前空間内のポッドのみがアクセスできます。
永続ボリューム
ポッド ライフサイクルの一部として定義および作成されるボリュームは、そのポッドが削除されるまでしか存在しません。 メンテナンス イベントでポッドが別のホストに再スケジュールされた場合でも、多くの場合、ポッドはストレージがそのまま存在することを予期しています (特に StatefulSets)。 永続ボリュームは、Kubernetes API によって作成および管理されるストレージ リソースであり、個々のポッドの有効期間が終了しても存在できます。
クラスター管理者は、永続ボリュームを静的に作成することも、Kubernetes API サーバーによってボリュームを動的に作成することもできます。 ポッドがスケジュールされ、そのポッドが現在使用可能でないストレージを要求すると、Kubernetes は基礎となる VHDX ファイルを作成して、ポッドに接続することができます。 動的なプロビジョニングでは StorageClass を使用して、どの種類の Azure Storage を作成する必要があるかを特定します。
ストレージ クラス
ストレージのさまざまな層 (および場所) を定義するには、 StorageClassを作成します。 StorageClassはreclaimPolicyも定義します。 この reclaimPolicy は、ポッドが削除され、永続ボリュームが不要になった場合の、基になるストレージ リソースの動作を制御します。 基礎となるストレージ リソースは削除することも、将来のポッドで使用するために保持しておくこともできます。
AKS Arc では、 default ストレージ クラスが自動的に作成され、CSV を使用して VHDX ベースのボリュームが作成されます。 解放ポリシーによって、基礎となる VHDX を使用していた永続ボリュームが削除されるときに、VHDX も確実に削除されます。 ストレージ クラスによって永続ボリュームを拡張可能にする構成も行われるため、必要なのは、永続ボリューム要求を新しいサイズを使用して編集することだけです。
永続ボリュームに StorageClass が指定されていない場合は、既定の StorageClass が使用されます。 永続ボリュームを要求するときは、それらが適切なストレージを使用していることを確認してください。 追加のニーズに合わせて、 StorageClass を作成できます。
永続ボリューム要求
PersistentVolumeClaimは、特定のStorageClassおよびサイズのReadWriteOnceまたはReadWriteManyストレージを要求します。 Kubernetes API サーバーは、定義された StorageClass に基づいて要求を満たす既存のリソースがない場合に、基になるストレージ リソースを AKS Arc に動的にプロビジョニングできます。 ボリュームがポッドに接続されると、ポッドの定義にボリューム マウントが含まれます。
PersistentVolumeはPersistentVolumeClaimそれを要求するポッドに使用可能なストレージ リソースが割り当てられるとバインドされます。 永続ボリュームと要求は 1 対 1 のマッピングです。
次の YAML マニフェストの例は、既定の StorageClass を使用し、5Gi ディスクを要求する永続ボリューム要求を示しています。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: aks-hci-vhdx
spec:
accessModes:
- ReadWriteOnce
storageClassName: default
resources:
requests:
storage: 5Gi
ポッド定義を作成するときに、目的のストレージを要求する永続ボリューム要求を指定します。 また、アプリケーションでデータの読み取りと書き込みを行う volumeMount も指定します。 次の例の YAML マニフェストは、前の永続ボリューム要求を使用してボリュームを/mnt/aks-hci にマウントする方法を示しています。
kind: Pod
apiVersion: v1
metadata:
name: nginx
spec:
containers:
- name: myfrontend
image: k8s.gcr.io/nginx
volumeMounts:
- mountPath: "/mnt/aks-hci"
name: volume
nodeSelector:
kubernetes.io/os: linux
volumes:
- name: volume
persistentVolumeClaim:
claimName: aks-hci-vhdx
次の例は、Windows コンテナーにボリュームをマウントし、ドライブ文字とパスを指定する方法を示しています。
volumeMounts:
- mountPath: "d:"
name: volume
- mountPath: "c:\k"
name: k-dir