AKS でカスタムストレージクラスを使用して Azure Local で外部ストレージ (SAN) を使用する

Overview

このドキュメントでは、カスタム Kubernetes ストレージクラスと永続ボリュームを使用して外部記憶域ネットワーク (SAN) リソースを使用するように Azure Local で AKS クラスターを構成する手順について説明します。基になるメカニズムはコンテナーストレージインターフェイス (CSI) です。これにより、Kubernetes は標準化された方法で幅広いストレージバックエンドと対話できます。 SAN プロビジョンナーにマップするカスタム StorageClass を定義することで、ワークロードはボリュームごとに手動で管理者の介入を行うことなく、永続ストレージを動的に要求およびバインドできます。

前提条件

Azure にデプロイおよび登録された Azure ローカルクラスター。
aksarc および connectedk8s 拡張機能と共にインストールされた Azure CLI。
Azure ローカルクラスター用に構成されたカスタムの場所。
AKS クラスター用に作成された論理ネットワーク (vnet)。
クラスター管理者アクセス権を持つ Microsoft Entra グループ。
Azure Local クラスターノードからプロビジョニングされ、アクセス可能な外部 SAN ストレージへのアクセス。
kubectl がローカルにインストールされています。

手順 1: AKS クラスターを作成する

オプション A: Azure portal

Azure portal で Azure ローカルクラスターに移動します。
左側のメニューで、[リソース → Kubernetes クラスター] をクリックします。
[Kubernetes クラスターの作成] をクリックします。
クラスター名を指定し、Azure ローカルクラスターのカスタムの場所を選択し、残りのフィールドに入力します。
ウィザードを続行し、[作成] をクリックします。

オプション B: Azure CLI

次のコマンドを実行する前に、必要な Azure CLI 拡張機能をインストールします。 Azure にサインインし、ターゲットサブスクリプションを設定してから、次のコマンドを実行します。

az aksarc create \
  -n $aksclustername \
  -g $resource_group \
  --custom-location $customlocationID \
  --vnet-ids $logicnetId \
  --aad-admin-group-object-ids $aadgroupID \
  --generate-ssh-keys

手順 2: Kubernetes クラスターに接続する

ターミナルウィンドウで az connectedk8s proxy コマンドを実行して、新しく作成されたクラスターに接続します。これにより、Arc に接続されたクラスターへのローカルプロキシが確立されます。次に、同じ作業フォルダーを指す新しい PowerShell ウィンドウを開きます。

クラスターで動作する後続のすべての kubectl コマンドでは、次のフラグを追加して Kubernetes 構成ファイルを明示的に指定することが必要になる場合があります。

--kubeconfig .\aks-arc-kube-config

手順 3: ディスク用のカスタムストレージクラスを作成する

カスタム StorageClass は、Kubernetes がストレージ要求を Azure Local で使用可能な特定の SAN ベースのディスクの種類にマップする方法です。 StorageClass 定義は、CSI プロビジョニング、再利用ポリシー、バインドモード、およびストレージベンダーの CSI ドライバーで必要な SAN 固有のパラメーターを指定します。

Microsoft Learn のドキュメントに従って、ディスク用のカスタムストレージクラスを作成します。Azure Arc で有効になっている AKS で Container Storage Interface (CSI) ディスクドライバーを使用する - Azure Arc で有効になっている AKS |Microsoft Learn

または、Azure portal を使用します。AKS クラスターページに移動し、ストレージ→ Kubernetes リソースをクリックします。このページでは、ストレージクラス、永続ボリューム要求、および永続ボリュームを作成および管理できます。

手順 4: 永続ボリューム要求を作成する (PVC)

StorageClass が作成されたら、永続ボリューム要求 (PVC) を定義して、SAN ストレージリソースにバインドされている永続ボリュームを要求します。次の例では、カスタムストレージクラスを使用して 1 GiB ボリュームを要求します。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: aks-hci-vhdx
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: <your custom storage class name>
  resources:
    requests:
      storage: 1Gi

手順 5: ポッドで永続ボリュームを使用する

volumeMount を使用して、ポッド定義内の PVC を参照します。次の例では、SAN ベースのボリュームを /mnt/aks-hci にマウントする nginx コンテナーをデプロイします。このコンテナーでは、アプリケーションでデータの読み取りと書き込みを行うことができます。

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/aks-hci"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: aks-hci-vhdx

手順 6: 永続ボリュームを使用してサンプルアプリケーションをデプロイする

次の完全なマニフェストは、Redis バックエンドと Web フロントエンドで構成される Azure Vote アプリケーションをデプロイします。どちらのコンポーネントも SAN ベースの永続ボリュームをマウントし、Azure Local 上の外部ストレージとのエンドツーエンドの統合を示します。

Note

このマニフェストを適用する前に、(手順 4 で説明されているように) カスタムストレージクラスを使用して、PVC aks-hci-vhdx-1 と aks-hci-vhdx-2 が既に作成されていることを確認します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-vote-back
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-back
  template:
    metadata:
      labels:
        app: azure-vote-back
    spec:
      nodeSelector:
        "kubernetes.io/os": linux
      containers:
      - name: azure-vote-back
        image: mcr.microsoft.com/oss/bitnami/redis:6.0.8
        env:
        - name: ALLOW_EMPTY_PASSWORD
          value: "yes"
        ports:
        - containerPort: 6379
          name: redis
        volumeMounts:
        - mountPath: "/mnt/aks-hci"
          name: volume1
      volumes:
        - name: volume1
          persistentVolumeClaim:
            claimName: aks-hci-vhdx-1
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-back
spec:
  ports:
  - port: 6379
  selector:
    app: azure-vote-back
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: azure-vote-front
spec:
  replicas: 1
  selector:
    matchLabels:
      app: azure-vote-front
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: azure-vote-front
    spec:
      nodeSelector:
        "kubernetes.io/os": linux
      containers:
      - name: azure-vote-front
        image: lgmorand/azure-vote-front:v1
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
          limits:
            cpu: 500m
        env:
        - name: REDIS
          value: "azure-vote-back"
        volumeMounts:
        - mountPath: "/mnt/aks-hci"
          name: volume2
      volumes:
        - name: volume2
          persistentVolumeClaim:
            claimName: aks-hci-vhdx-2
---
apiVersion: v1
kind: Service
metadata:
  name: azure-vote-front
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: azure-vote-front

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-08-24