ACK でのステートフルアプリケーションの静的ディスクボリュームのマウント - ACK

静的にプロビジョニングされたディスクボリュームを使用すると、既存の Alibaba Cloud ディスクを Pod にアタッチでき、Pod の再起動および再スケジューリング後もデータが保持されます。動的プロビジョニングとは異なり、永続ボリューム (PV) および永続ボリューム要求 (PVC) を手動で作成し、その後、その PVC を参照するアプリケーションをデプロイします。

このプロセスの概要は以下のとおりです：

クラスター管理者として、既存のディスクをバックエンドとする PV を作成します。
ラベルセレクターを使用して PV にバインドされる PVC を作成します。
PVC をマウントするアプリケーションをデプロイします。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

ACK マネージドクラスター。詳細については、「ACK マネージドクラスターの作成」をご参照ください。
既存の Alibaba Cloud ディスク。詳細については、「ディスクの作成」をご参照ください。
kubectl がクラスターに接続されていること。詳細については、「クラスターの kubeconfig ファイルを取得し、kubectl を使用してクラスターに接続する」をご参照ください。

制限事項

各ディスクは、同時に 1 つの Pod にのみマウントできます。
ディスクは、同一ゾーン内のノードにのみマウントできます。

ユースケース

静的ディスクプロビジョニングは、以下のようなユースケースに適しています。

高 I/O 要件を有するステートフルワークロード — MySQL や Redis などのデータベースで、データ共有を伴わない専用ブロックストレージが必要な場合。
高速ログ書き込み — 高スループットで継続的にログデータを書き込むアプリケーション。
Pod に依存しないデータストレージ — 個別の Pod のライフサイクルを超えて保持される必要があるデータ。

PV の作成

以下の内容で pv-static.yaml というファイルを作成します。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: <your-disk-id>
  labels:
    alicloud-pvname: <your-disk-id>
    failure-domain.beta.kubernetes.io/zone: <your-zone>
    failure-domain.beta.kubernetes.io/region: <your-region>
spec:
  capacity:
    storage: 20Gi
  accessModes:
    - ReadWriteOnce
  flexVolume:
    driver: "alicloud/disk"
    fsType: "ext4"
    options:
      volumeId: "<your-disk-id>"

プレースホルダーを実際の値に置き換えます。

フィールド	説明	必須	例
`name` (メタデータ)	PV の名前。ディスク ID を指定します。	はい	`<your-disk-id>`
`alicloud-pvname`	PVC のラベルセレクターがこの PV にバインドするために使用するラベル。ディスク ID を指定します。	はい	`<your-disk-id>`
`failure-domain.beta.kubernetes.io/zone`	ディスクがデプロイされているゾーン。マルチゾーンクラスターでは、Pod を正しいゾーンにスケジュールするために必要です。	はい（マルチゾーンクラスターの場合）	`cn-hangzhou-b`
`failure-domain.beta.kubernetes.io/region`	ディスクがデプロイされているリージョン。マルチゾーンクラスターでは必要です。	はい（マルチゾーンクラスターの場合）	`cn-hangzhou`
`capacity.storage`	ストレージ容量。	はい	`20Gi`
`volumeId`	アタッチする既存のディスクの ID。	はい	`<your-disk-id>`

マルチゾーンにデプロイされたクラスターでは、failure-domain.beta.kubernetes.io/zone および failure-domain.beta.kubernetes.io/region ラベルにより、Pod がディスクが配置されているゾーンにスケジュールされます。詳細については、「静的にプロビジョニングされたディスクボリュームのマウント」をご参照ください。

マニフェストを適用します。
```
kubectl create -f pv-static.yaml
```
PV が作成されたことを確認します：ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。[クラスター] ページで、管理するクラスターを見つけ、クラスターの名前または [操作] 列の [詳細] をクリックします。詳細ページの左側のナビゲーションウィンドウで、[ボリューム > Persistent Volume] を選択します。新しく作成された PV が表示されていることを確認します。

PVC の作成

以下の内容で pvc-static.yaml というファイルを作成します。
```
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvc-disk
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  selector:
    matchLabels:
      alicloud-pvname: <your-disk-id>
```
<your-disk-id> を、PV 作成時に使用したディスク ID に置き換えます。selector.matchLabels フィールドにより、この PVC は一致する alicloud-pvname ラベルを持つ PV にバインドされます。
マニフェストを適用します。
```
kubectl create -f pvc-static.yaml
```
PVC が作成されたことを確認します。 ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。クラスターページで、管理するクラスターを見つけ、クラスター名をクリックするか、[操作] 列の [詳細] をクリックします。詳細ページの左側のナビゲーションウィンドウで、[ボリューム] > [永続ボリューム要求] を選択します。永続ボリューム要求ページで、新しく作成された PVC が表示されていることを確認します。

アプリケーションのデプロイ

以下の内容で static.yaml というファイルを作成します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-static
  labels:
    app: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        volumeMounts:
          - name: disk-pvc
            mountPath: "/data"
      volumes:
        - name: disk-pvc
          persistentVolumeClaim:
            claimName: pvc-disk

この Deployment では、pvc-disk PVC をコンテナ内の /data パスにマウントします。

マニフェストを適用します。
```
kubectl create -f static.yaml
```
Deployment および Pod が実行中であることを確認します。
```
kubectl get pod | grep static
```
期待される出力：
```
nginx-static-78c7dcb9d7-g****   2/2     Running     0          32s
```
ACK コンソールでも確認できます。[ワークロード] > [デプロイメント] に移動し、nginx-static が一覧表示されていることを確認します。

データの永続性の確認

以下の手順を実行し、ディスクに書き込まれたデータが Pod の削除および再作成後も保持されることを確認します。

ディスクが /data にマウントされていることを確認します。

kubectl exec nginx-static-78c7dcb9d7-g**** -- df | grep data

期待される出力：

/dev/vdf        20511312    45080  20449848   1% /data

/data のファイル一覧を表示します。
```
kubectl exec nginx-static-78c7dcb9d7-g**** -- ls /data
```
期待される出力：
```
lost+found
```

テストファイルを作成します。

kubectl exec nginx-static-78c7dcb9d7-g**** -- touch /data/static

ファイルが存在することを確認します。
```
kubectl exec nginx-static-78c7dcb9d7-g**** -- ls /data
```
期待される出力：
```
static
lost+found
```

Pod を削除して再作成をトリガーします。

kubectl delete pod nginx-static-78c7dcb9d7-g****

期待される出力：

pod "nginx-static-78c7dcb9d7-g****" deleted

別ターミナルで、Pod のライフサイクルを監視します。

kubectl get pod -w -l app=nginx

期待される出力：

NAME                            READY   STATUS            RESTARTS   AGE
nginx-static-78c7dcb9d7-g****   2/2     Running           0          50s
nginx-static-78c7dcb9d7-g****   2/2     Terminating       0          72s
nginx-static-78c7dcb9d7-h****   0/2     Pending           0          0s
nginx-static-78c7dcb9d7-h****   0/2     Pending           0          0s
nginx-static-78c7dcb9d7-h****   0/2     Init:0/1          0          0s
nginx-static-78c7dcb9d7-g****   0/2     Terminating       0          73s
nginx-static-78c7dcb9d7-h****   0/2     Init:0/1          0          5s
nginx-static-78c7dcb9d7-g****   0/2     Terminating       0          78s
nginx-static-78c7dcb9d7-g****   0/2     Terminating       0          78s
nginx-static-78c7dcb9d7-h****   0/2     PodInitializing   0          6s
nginx-static-78c7dcb9d7-h****   2/2     Running           0          8s

再作成された Pod の名前を取得します。

kubectl get pod

期待される出力：

NAME                            READY   STATUS      RESTARTS   AGE
nginx-static-78c7dcb9d7-h****   2/2     Running     0          14s

再作成された Pod 内でテストファイルが引き続き存在することを確認します。
```
kubectl exec nginx-static-78c7dcb9d7-h6brd -- ls /data
```
期待される出力：
```
static
lost+found
```
static ファイルが存在することから、ディスクに書き込まれたデータが Pod の削除および再作成を経ても保持されることが確認されます。

次のステップ

ストレージクラスを自動 PV 作成に使用するには、動的にプロビジョニングされたディスクボリュームを使用した永続ストレージを参照してください。
静的にプロビジョニングされたディスクボリュームのマウントに関する詳細設定オプションについては、「静的にプロビジョニングされたディスクボリュームのマウント」をご参照ください。