# Dynamic Engineでの永続ストレージ用のKubernetes PersistentVolumeClaimsのマウント

PersistentVolumeClaimsを使用して永続ストレージボリュームをコンテナにマウントすることで、データ統合タスク(ビッグデータを含む)、データサービス、ルートタスクで、状態を保持したデータアクセス、複数ポッド間でのデータ共有、ポッド再起動後の永続ストレージ利用ができるようになります。

## 始める前に

[前提条件および重要な考慮事項](https://help.qlik.com/talend/ja-JP/dynamic-engine-configuration-guide/Cloud/custom-kubernetes-resource-mounting)をご覧ください。

## このタスクについて

Kubernetes PersistentVolumeClaims (PVC)をマウントすると、ポッドのライフサイクルに依存しない永続ストレージが提供されます。これは、次のような場合に役立ちます。

* ポッドの再起動後も保持する必要があるデータの保存
* 複数のポッド間でのデータ共有
* 既存のデータボリュームへのアクセス

## 手順

1. Kubernetes PersistentVolumeClaim (PVC) リソースファイルを作成します。
   ### 例

   pvc-custom-claim.yamlというファイルを作成します。
   ```
   cat <<EOF > pvc-custom-claim.yaml
   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: my-custom-claim-linked-to-a-static-or-dynamic-persistentvolume
     namespace: qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 10Gi
     storageClassName: standard 
   EOF
   ```

   $DYNAMIC\_ENGINE\_ENVIRONMENT\_IDを実際のIDに置き換え、storageClassNameをクラスターで使用可能なストレージクラスに合わせて更新します。一貫性を保つために、Dynamic Engine環境に設定したものと同じストレージクラスを使用してください([Dynamic Engine環境サービス専用のストレージクラスのプロビジョニング](https://help.qlik.com/talend/ja-JP/dynamic-engine-configuration-guide/Cloud/deploy-dynamic-engine-with-specific-storageclass "デフォルトのKubernetesストレージクラスを使用する代わりに、Dynamic Engine環境サービス専用のストレージクラスを設定します。")で指定)。

   この例では動的プロビジョニングを使用しています。storageClassNameを指定することで、このPVCの作成時に KubernetesがPersistentVolumeを自動的に作成します。Kubernetesにオンデマンドでストレージをプロビジョニングさせたい場合にこの方法を使用します。

   代わりに静的プロビジョニングを使用する場合(管理者がすでにPersistentVolumeを作成している場合)は、specセクション全体を次のように置き換えます。
   ```
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 10Gi
     volumeName: my-existing-pv
   ```

   my-existing-pvを、管理者が作成した実際のPersistentVolume名に置き換えます。静的プロビジョニングの場合は、storageClassNameを省略します。

   使い分けの方法:
   * 動的プロビジョニング(storageClassNameを使用) - ストレージは必要に応じて自動的に作成されます。ほとんどのシナリオで使用します。
   * 静的プロビジョニング(volumeNameを使用) - 既存のPersistentVolumeにバインドします。特定のボリュームが事前に割り当てられている場合や、特別な設定が必要な場合に使用します。
2. PVCマウントを設定するHelm値ファイルを作成します。
   ### 例

   pvc-values.yamlという名前のファイルを作成します。
   ```
   configuration:
     # For Data Integration and Big Data Job tasks
     jobDeployment:
       additionalSpec:
         enabled: true
         volumeMounts:
           - name: external-data-storage
             mountPath: /tmp/data
         volumes:
           - name: external-data-storage
             persistentVolumeClaim:
               claimName: my-custom-claim-linked-to-a-static-or-dynamic-persistentvolume

     # For Data Service and Route tasks
     dataServiceRouteDeployment:
       additionalSpec:
         enabled: true
         volumeMounts:
           - name: external-data-storage
             mountPath: /tmp/data
         volumes:
           - name: external-data-storage
             persistentVolumeClaim:
               claimName: my-custom-claim-linked-to-a-static-or-dynamic-persistentvolume
   ```

   この設定では、PVC my-custom-claim-linked-to-a-static-or-dynamic-persistentvolumeが/tmp/dataにマウントされます。このパスに書き込まれたすべてのデータは、ポッドの再起動後も保持されます。
3. Dynamic Engine環境をデプロイまたはアップグレードして必要なネームスペースを作成します。
   ```
   helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
     oci://ghcr.io/talend/helm/dynamic-engine-environment \
     --version ${DYNAMIC_ENGINE_VERSION} \
     -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml
   ```

   ${DYNAMIC\_ENGINE\_VERSION}を自分の環境のバージョンに置き換えます。

   このコマンドを実行すると、Dynamic Engine環境とそれに関連付けられたネームスペースqlik-processing-env-$DYNAMIC\_ENGINE\_ENVIRONMENT\_IDを作成します。
4. Dynamic Engine環境のネームスペースにPVCを作成します。
   ```
   kubectl apply -f pvc-custom-claim.yaml
   ```
5. PVCマウントでDynamic Engine環境をアップグレードします。
   ```
   helm upgrade dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
     oci://ghcr.io/talend/helm/dynamic-engine-environment \
     --version ${DYNAMIC_ENGINE_VERSION} \
     -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \
     -f pvc-values.yaml
   ```

   $DYNAMIC\_ENGINE\_ENVIRONMENT\_IDを自分の環境IDに、${DYNAMIC\_ENGINE\_VERSION}を環境のバージョンにそれぞれ置き換えます。
6. 実行中のポッドにPVCがマウントされていることを確認します。
   ```
   # Check PVC status
   kubectl get pvc -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID

   # Verify the mounted volume
   kubectl get pod <pod-name> -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
     -o jsonpath='{.spec.volumes[?(@.name=="external-data-storage")]}' | jq .
   ```

   想定される出力にはPVC参照が表示されます。
   ```
   {
     "name": "external-data-storage",
     "persistentVolumeClaim": {
       "claimName": "my-custom-claim-linked-to-a-static-or-dynamic-persistentvolume"
     }
   }
   ```

## タスクの結果

Dynamic Engine環境のタスクは、PersistentVolumeClaimsを使用して永続ストレージにアクセスできるようになりました。マウントされたディレクトリに書き込まれたデータは、ポッドの再起動、再デプロイ、環境のアップグレード後も保持されます。ReadWriteManyで設定されている場合、複数のポッドが同じPVCにアクセスできます。

永続ボリュームが更新された場合、リロードの動作はタスクの種類によって異なります。

* データ統合(ビッグデータを含む)ジョブタスクの場合、次回のタスク実行では更新された値が自動的に使用されます。
* 継続的に実行されるルートおよびデータサービスタスクの場合、変更内容は実行中のコンテナに自動的にリロードされません。これらのタスクに認証情報の変更を適用するには、[Talend Management Consoleでタスクを更新し](https://help.qlik.com/talend/ja-JP/dynamic-engine-configuration-guide/Cloud/updating-data-service-and-route-tasks-in-dee "Dynamic Engine環境にデプロイされたデータサービスやルートタスクは、ダウンタイムなしでそのアーティファクトバージョンをアップデートしたり、設定を変更したりできます。")、Kubernetesクラスターでの再デプロイをトリガーしてください。