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

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

始める前に

前提条件および重要な考慮事項をご覧ください。

このタスクについて

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

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

手順

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環境サービス専用のストレージクラスのプロビジョニングで指定)。

この例では動的プロビジョニングを使用しています。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にバインドします。特定のボリュームが事前に割り当てられている場合や、特別な設定が必要な場合に使用します。

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にマウントされます。このパスに書き込まれたすべてのデータは、ポッドの再起動後も保持されます。

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を作成します。
Dynamic Engine環境のネームスペースにPVCを作成します。
```
kubectl apply -f pvc-custom-claim.yaml
```

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}を環境のバージョンにそれぞれ置き換えます。

実行中のポッドに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でタスクを更新し、Kubernetesクラスターでの再デプロイをトリガーしてください。

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

このページまたはコンテンツにタイポ、ステップの省略、技術的エラーなどの問題が見つかった場合はお知らせください。

こちらにフィードバックをお寄せください