Container Service for Kubernetes:CNFS を使用した汎用 CPFS 動的ボリュームの管理

ワークフロー

動的ボリュームを使用する場合、アプリケーションが永続ボリューム要求 (PVC) を作成すると、システムは指定された StorageClass に基づいて永続ボリューム (PV) を自動的にプロビジョニングします。この方法により、事前プロビジョニングが不要になり、自動ボリューム拡張がサポートされます。

クラスターで CPFS 動的ボリュームをマウントするワークフローを次の図に示します。

前提条件

• コンポーネントがバージョン要件を満たしていることを確認してください。

  クラスターのアップグレードについては、「ACK クラスターのアップグレード」をご参照ください。

  1.26 以降

  • CSI コンポーネントのバージョンが v1.32.2-757e24b-aliyun 以降であることを確認してください。

    CSI コンポーネントのアップグレードについては、「CSI コンポーネントの管理」をご参照ください。

  • cnfs-nas-daemon コンポーネントがインストールされており、cnfs-nas-daemon を有効にするために csi-plugin コンポーネントの FeatureGate に AlinasMountProxy=true を追加していること。詳細については、「cnfs-nas-daemon コンポーネントの管理」をご参照ください。

  1.26 より前のバージョン

  • CSI コンポーネントのバージョンが v1.24.11-5221f79-aliyun 以降であることを確認してください。

    CSI コンポーネントのアップグレードについては、「CSI コンポーネントの管理」をご参照ください。

  • クライアント依存関係をインストールし、csi-plugin コンポーネントを再起動します。

    ステップを表示するには展開します

    csi-plugin ConfigMap を構成して、起動時にクライアント依存関係を自動的にインストールします。

    1. csi-plugin という名前の ConfigMap が存在するかどうかを確認します。

       kubectl -n kube-system get cm csi-plugin

       ConfigMap が存在する場合

       csi-plugin という名前の ConfigMap がすでに存在する場合は、ConfigMap を更新します。

       kubectl edit configmap csi-plugin -n kube-system

       data の下に cnfs-client-properties フィールドを追加し、cpfs-efc=true を設定してクライアント依存関係をインストールします。

       ...
       data:
         cnfs-client-properties: |
           cpfs-efc=true   # Install client dependencies when csi-plugin starts.

       ConfigMap が存在しない場合

       csi-plugin という名前の ConfigMap が存在しない場合は、kube-system 名前空間に作成します。

       cat <<EOF | kubectl apply -f -
       apiVersion: v1
       kind: ConfigMap
       metadata:
         name: csi-plugin
         namespace: kube-system
       data:
         cnfs-client-properties: |
           cpfs-efc=true   # Install the client dependencies when csi-plugin starts.
       EOF

    2. csi-plugin コンポーネントを再起動します。

       kubectl -n kube-system rollout restart daemonset csi-plugin

• クラスターと同じ VPC 内に汎用 CPFS ファイルシステムとそれに対応するプロトコルサービスを作成し、マウントターゲットアドレスを取得していること。詳細については、「プロトコルサービスの作成とマウントターゲットアドレスの取得」をご参照ください。

  最適なパフォーマンスを得るには、CPFS プロトコルサービスのマウントターゲットとクラスターを同じ vSwitch に配置してください。

使用制限

• CPFS 汎用エディションは、一部のリージョンでのみ利用可能です。詳細については、「CPFS 汎用エディションの利用可能リージョン」をご参照ください。

• CPFS ファイルシステムは、同じ VPC 内のクラスターにのみマウントできます。

CPFS の使用制限の詳細については、「使用制限」をご参照ください。

ステップ 1: CNFS オブジェクトの作成

既存の CPFS ファイルシステムをクラスターに登録するために CNFS オブジェクトを作成します。

1. 次のテンプレートを使用して、cnfs.yaml という名前のファイルを作成します。

   apiVersion: storage.alibabacloud.com/v1beta1
   kind: ContainerNetworkFileSystem
   metadata:
     name: cnfs-nfs-cpfs
   spec:
     # バックエンドストレージタイプを CPFS として指定します。
     type: cpfs  
     # この CNFS オブジェクトを削除しても、バックエンドの CPFS ファイルシステムは削除されません。
     reclaimPolicy: Retain  
     parameters:
       # CPFS プロトコルサービスのマウントターゲットのドメイン名。
       protocolServer: cpfs-xxxx.xxxx.cpfs.aliyuncs.com  
       # NFS クライアントを使用してボリュームをマウントします。
       useClient: NFSClient  

   パラメーター:

   パラメーター	説明
   spec.type	バックエンドストレージタイプ。これを cpfs に設定します。
   spec.reclaimPolicy	リクレイムポリシー。Retain のみがサポートされています。この設定により、CNFS オブジェクトが削除されてもバックエンドの CPFS ファイルシステムが削除されるのを防ぎます。
   spec.parameters.protocolServer
   spec.parameters.useClient	NFS クライアントを使用してマウントするには、これを NFSClient に設定します。

2. CNFS オブジェクトを作成します。

   kubectl apply -f cnfs.yaml

3. CNFS オブジェクトのステータスを確認し、Available であることを確認します。

   kubectl get cnfs cnfs-nfs-cpfs -o jsonpath='{.status.status}'

ステップ 2: StorageClass の作成

動的プロビジョニングのテンプレートとして機能し、作成した CNFS オブジェクトを参照する StorageClass を作成します。

1. 次のテンプレートを使用して、sc.yaml という名前のファイルを作成します。

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: cnfs-nfs-cpfs-sc
   # マウントオプション。
   mountOptions:  
     - nolock,tcp,noresvport
     - vers=3
   parameters:
     # サブディレクトリベースの PV を作成します。
     volumeAs: subpath  
     # 以前に作成した CNFS オブジェクトを参照します。
     containerNetworkFileSystem: "cnfs-nfs-cpfs"  
     # 汎用 CPFS プロトコルサービスのエクスポートパス。
     path: "/share"  
     # PVC が削除されたときのデータ処理ポリシー。`true` はデータを削除する代わりにアーカイブします。
     archiveOnDelete: "true"  
   provisioner: nasplugin.csi.alibabacloud.com
   # PV リクレイムポリシー。この例では Retain のみがサポートされています。
   reclaimPolicy: Retain  
   # ボリューム拡張を許可します。
   allowVolumeExpansion: true  

   パラメーター:

   パラメーター	説明
   mountOptions	マウントオプション。例に示されているデフォルト値を使用できます。
   parameters.volumeAs	subpath: サブパスモード。各 PV は CPFS ファイルシステム上の独立したサブディレクトリに対応し、データ隔離を提供します。 sharepath: シェアパスモード。この StorageClass から作成されたすべての PV は、CPFS ファイルシステム上の同じディレクトリを共有します。
   parameters.containerNetworkFileSystem	参照する CNFS オブジェクト。
   parameters.path	汎用 CPFS プロトコルサービスのエクスポートパス (例: /share)。/share/dir のようにサブディレクトリを指定することもできます。 現在、通常のディレクトリのみがサポートされています。ファイルセットはサポートされていません。
   parameters.archiveOnDelete	このパラメーターは、volumeAs が subpath に設定され、reclaimPolicy が Delete に設定されている場合にのみ有効になります。 汎用 CPFS は共有ストレージサービスです。このパラメーターは、削除前の二次確認を提供します。 PVC が削除されたときにサブディレクトリデータがどのように処理されるかを制御します。 true (デフォルト): サブディレクトリは削除される代わりにアーカイブされ、archived-{pvName}.{timestamp} に名前が変更されます。データを手動で回復できます。 false: サブディレクトリとそのすべてのファイルを完全に削除します。このデータは回復できません。 この操作は、CPFS ファイルシステム自体ではなく、CPFS サブディレクトリとそのファイルを削除するだけです。CPFS ファイルシステムを削除するには、「ファイルシステムの削除」をご参照ください。
   reclaimPolicy	csi-provisioner がマネージドコンポーネントである場合、そのバージョンはv1.34.1以降である必要があります。アンマネージドコンポーネントにはバージョン制限はありません。 このパラメーターは、volumeAs が subpath に設定されている場合にのみ有効になります。 PV のリクレイムポリシー。PVC が削除された後のリソースの処理方法を制御します。 Delete: PVC が削除されると、PV を自動的に解放します。archiveOnDelete パラメーターは、バックエンドのサブディレクトリデータも削除するかどうかを決定します。 Retain: PVC が削除されても、PV は保持され、バックエンドデータは影響を受けません。リソースを手動でクリーンアップする必要があります。このオプションは、高いデータセキュリティ要件を持つシナリオに適しています。
   allowVolumeExpansion	このパラメーターが有効になっている場合、CPFS ボリュームは自動的に拡張できます。

2. StorageClass を作成します。

   kubectl apply -f sc.yaml

3. StorageClass が正常に作成されたことを確認します。

   kubectl get sc cnfs-nfs-cpfs-sc

   期待される出力:

   NAME               PROVISIONER                      RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
   cnfs-nfs-cpfs-sc   nasplugin.csi.alibabacloud.com   Retain          Immediate           true                   9s

ステップ 3: アプリケーションの作成

ワークロードを作成し、作成した StorageClass を volumeClaimTemplates セクションで指定します。

1. 次のテンプレートを使用して、sts.yaml という名前のファイルを作成します。

   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: cnfs-nfs-cpfs-sts
   spec:
     selector:
       matchLabels:
         app: nginx
     serviceName: "nginx"
     replicas: 2
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
           volumeMounts:
           - name: pvc
             # ストレージボリュームをコンテナ内の /data ディレクトリにマウントします。
             mountPath: /data  
     # PVC テンプレートを定義します。StatefulSet コントローラーは、各 Pod 用に PVC を動的に作成します。
     volumeClaimTemplates:
     - metadata:
         name: pvc
       spec:
         accessModes: [ "ReadWriteOnce" ]
         # 以前に作成した StorageClass を参照します。
         storageClassName: "cnfs-nfs-cpfs-sc"     
         resources:
           requests:
             storage: 50Gi

2. アプリケーションを作成します。

   kubectl apply -f sts.yaml

3. Pod が実行中ステータスであることを確認します。

   kubectl get pod | grep cnfs-nfs-cpfs-sts

   期待される出力:

   cnfs-nfs-cpfs-sts-0   1/1     Running   0          11s
   cnfs-nfs-cpfs-sts-1   1/1     Running   0          9s

4. Pod が CPFS ストレージボリュームをマウントしていることを確認します。

   kubectl exec cnfs-nfs-cpfs-sts-0 -- mount | grep nfs

   次の出力は、CNFS が NFS クライアントを使用して CPFS ファイルシステムを正常にマウントしたことを示しています。

   cpfs-********-********.cn-shanghai.cpfs.aliyuncs.com:/share/nas-804e8cb1-2355-4026-87fc-ee061e14f5f9 on /data type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,noresvport,proto=tcp,port=30000,timeo=600,retrans=2,sec=sys,mountaddr=127.XX.XX.255,mountvers=3,mountport=30000,mountproto=tcp,local_lock=all,addr=127.XX.XX.255)

ステップ 4: 結果の検証

アプリケーションが作成されると、システムは自動的にボリュームをプロビジョニングしてマウントします。

kubectl get pvc -l app=nginx

NAME                      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS       VOLUMEATTRIBUTESCLASS   AGE
pvc-cnfs-nfs-cpfs-sts-0   Bound    nas-8d2530eb-fcf9-4ad5-b5f8-bae02a1*****   50Gi       RWO            cnfs-nfs-cpfs-sc   <unset>                 63s
pvc-cnfs-nfs-cpfs-sts-1   Bound    nas-e84cadaf-ce35-4745-8cbb-2a80026*****   50Gi       RWO            cnfs-nfs-cpfs-sc   <unset>                 61s

kubectl exec cnfs-nfs-cpfs-sts-0 -- mount | grep /data

cpfs-....aliyuncs.com:/share/nas-804e8cb1-2355-4026-87fc-ee061e1****** on /data type nfs (rw,...)

本番環境のベストプラクティス

• データ保護: PVC の削除による偶発的なデータ損失を防ぐため、StorageClass で reclaimPolicy を Retain に、archiveOnDelete を true に設定します。

リソースのクリーンアップ

予期せぬ課金を回避し、データセキュリティを確保するために、不要になったリソースを解放するには、この手順に従ってください。

1. ワークロードの削除

   • 操作: StatefulSet など、関連する PVC を使用するすべてのアプリケーションを削除します。この操作により、実行中の Pod が停止し、ストレージボリュームがアンマウントされます。

   • コマンド例: kubectl delete statefulset <your-statefulset-name>

2. PVC の削除

   • 操作: アプリケーションに関連付けられた PVC を削除します。バックエンドデータの処理は、volumeAs、reclaimPolicy、および archiveOnDelete の組み合わせによって決定されます。

     • volumeAs: subpath

       各 PVC は独立したサブディレクトリに対応します。削除動作は次のとおりです。

       • reclaimPolicy: Retain: PV は保持され、CPFS サブディレクトリ内のデータは変更されません。手動でクリーンアップを実行する必要があります。

       • reclaimPolicy: Delete + archiveOnDelete: "true": PV は自動的に解放されます。サブディレクトリはアーカイブされ、archived-{pvName}.{timestamp} に名前が変更され、データは失われません。

       • reclaimPolicy: Delete + archiveOnDelete: "false": PV を自動的に解放し、サブディレクトリとそのファイルを完全に削除します。このデータは回復できません。注意して進めてください。

     • volumeAs: sharepath

       複数の PVC が同じディレクトリを共有します。PVC を削除しても、バックエンドディレクトリやそのデータには影響しません。reclaimPolicy および archiveOnDelete パラメーターは効果がありません。

     構成に関係なく、CPFS ファイルシステム自体は削除されません。CPFS ファイルシステムを削除するには、「ファイルシステムの削除」をご参照ください。

   • コマンド例: kubectl delete pvc <your-pvc-name>

3. Kubernetes ストレージリソースの削除

   この操作は、クラスター内のリソース定義を削除するだけです。バックエンドの CPFS ファイルシステムは削除されません。

   1. PV の削除

      • 操作: reclaimPolicy が Retain に設定されている場合、PVC が削除された後、PV のステータスは Released に変更されます。データが不要になったことを確認したら、PV を手動で削除できます。

      • コマンド例: kubectl delete pv <your-pv-name>

   2. StorageClass の削除

      • 操作: このタイプのストレージが不要になった場合は、対応する StorageClass を削除できます。

      • コマンド例: kubectl delete sc <your-storageclass-name>

   3. CNFS オブジェクトの削除

      • 操作: クラスターで CPFS ファイルシステムを使用する必要がなくなった場合は、CNFS オブジェクトを削除できます。CNFS オブジェクトを削除しても、バックエンドの CPFS ファイルシステムは削除されません。

      • コマンド例: kubectl delete cnfs <your-cnfs-name>