# Mounten von Kubernetes PersistentVolumeClaims für persistenten Speicher in Dynamic Engine

Verwenden Sie PersistentVolumeClaims, um persistente Speicher-Volumes in Ihre Container zu mounten, damit für Ihre Datenintegrations-Tasks (einschließlich Big Data), Datenservices und Routen-Tasks statusbehafteter Datenzugriff, Datenfreigabe über mehrere Pods hinweg und persistenter Speicher über Pod-Neustarts hinweg möglich sind.

## Vorbereitungen

Weitere Informationen finden Sie unter „[Voraussetzungen und wichtige Überlegungen](https://help.qlik.com/talend/de-DE/dynamic-engine-configuration-guide/Cloud/custom-kubernetes-resource-mounting)“.

## Warum und wann dieser Vorgang ausgeführt wird

Das Mounten von Kubernetes PersistentVolumeClaims (PVCs) stellt persistenten Speicher unabhängig vom Pod-Lebenszyklus bereit. Dies ist nützlich für:

* Speichern von Daten, die über Pod-Neustarts hinweg persistent sein müssen
* Freigeben von Daten zwischen mehreren Pods
* Zugreifen auf vorbestehende Daten-Volumes

## Prozedur

1. Erstellen Sie eine Kubernetes PersistentVolumeClaim (PVC)-Ressourcendatei.
   ### Example

   Erstellen Sie eine Datei mit dem Namen 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
   ```

   Ersetzen Sie $DYNAMIC\_ENGINE\_ENVIRONMENT\_ID mit der tatsächlichen ID und aktualisieren Sie storageClassName auf die verfügbare Speicherklasse des Clusters. Verwenden Sie aus Konsistenzgründen die gleiche Speicherklasse, die für Ihre Dynamic Engine-Umgebung konfiguriert wurde (wie in [Bereitstellen einer Speicherklasse, die auf Dynamic Engine-Umgebungsdienste spezialisiert ist](https://help.qlik.com/talend/de-DE/dynamic-engine-configuration-guide/Cloud/deploy-dynamic-engine-with-specific-storageclass "Konfigurieren Sie eine spezifische Speicherklasse für Dynamic Engine-Umgebungsdienste, anstatt die Standard-Kubernetes-Speicherklasse zu verwenden.") angegeben).

   In diesem Beispiel wird dynamische Bereitstellung verwendet: Der storageClassName weist Kubernetes an, automatisch ein PersistentVolume zu erstellen, wenn dieser PVC erstellt wird. Verwenden Sie diese Option, wenn Kubernetes Speicher bei Bedarf bereitstellen soll.

   Wenn statische Bereitstellung eingerichtet werden soll (wenn ein Administrator bereits ein PersistentVolume erstellt hat), ersetzen Sie den ganzen Abschnitt spec mit:
   ```
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 10Gi
     volumeName: my-existing-pv
   ```

   Ersetzen Sie my-existing-pv mit dem tatsächlichen PersistentVolume-Namen, der von Ihrem Administrator erstellt wurde. Lassen Sie bei statischer Bereitstellung storageClassName aus.

   Einsatzbereiche:
   * Dynamische Bereitstellung (mit storageClassName) – Speicher wird bei Bedarf automatisch erstellt. Für die meisten Szenarios zu verwenden.
   * Statische Bereitstellung (mit volumeName) — Sie binden an ein vorhandenes PersistentVolume. Zu verwenden, wenn spezifische Volumes vorab zugewiesen sind oder eine spezielle Konfiguration erfordern.
2. Erstellen Sie eine Helm-Wertedatei, welche PVC-Mounten konfiguriert.
   ### Example

   Erstellen Sie eine Datei mit dem Namen 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
   ```

   Mit dieser Konfiguration wird dieser PVC my-custom-claim-linked-to-a-static-or-dynamic-persistentvolume unter /tmp/data gemountet. Alle in diesen Pfad geschriebenen Daten bleiben über Pod-Neustarts hinweg persistent.
3. Implementieren oder aktualisieren Sie Ihre Dynamic Engine-Umgebung, um den erforderlichen Namespace zu erstellen.
   ```
   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
   ```

   Ersetzen Sie ${DYNAMIC\_ENGINE\_VERSION} mit der Version Ihrer Umgebung.

   Mit diesem Befehl werden die Dynamic Engine-Umgebung und ihr zugeordneter Namespace qlik-processing-env-$DYNAMIC\_ENGINE\_ENVIRONMENT\_ID erstellt.
4. Erstellen Sie den PVC im Namespace Ihrer Dynamic Engine-Umgebung.
   ```
   kubectl apply -f pvc-custom-claim.yaml
   ```
5. Aktualisieren Sie Ihre Dynamic Engine-Umgebung mit PVC-Mounting.
   ```
   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
   ```

   Ersetzen Sie $DYNAMIC\_ENGINE\_ENVIRONMENT\_ID mit Ihrer Umgebungs-ID und ${DYNAMIC\_ENGINE\_VERSION} mit der Version Ihrer Umgebung.
6. Überprüfen Sie, ob der PVC in laufenden Pods gemountet ist.
   ```
   # 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 .
   ```

   Die erwartete Ausgabe zeigt die PVC-Referenz:
   ```
   {
     "name": "external-data-storage",
     "persistentVolumeClaim": {
       "claimName": "my-custom-claim-linked-to-a-static-or-dynamic-persistentvolume"
     }
   }
   ```

## Ergebnisse

Ihre Tasks in der Dynamic Engine-Umgebung haben jetzt Zugriff auf persistenten Speicher mit PersistentVolumeClaims. Daten, die in das gemountete Verzeichnis geschrieben werden, bleiben über Pod-Neustarts, erneute Implementierungen und Umgebungs-Upgrades hinweg persistiert. Wenn ReadWriteMany konfiguriert ist, können mehrere Pods auf den gleichen PVC zugreifen.

Wenn persistente Volumes aktualisiert werden, unterscheidet sich das Ladeverhalten je nach Task-Typ:

* Für Datenintegrations-Job-Tasks (einschließlich Big Data) verwendet die nächste Task-Ausführung automatisch die aktualisierten Werte.
* Für Routen- und Datenservices-Tasks, die fortlaufend ausgeführt werden, werden Änderungen nicht automatisch in laufende Container geladen. Um Änderungen an Anmeldedaten auf diese Tasks anzuwenden, [aktualisieren Sie die Task in Talend Management Console](https://help.qlik.com/talend/de-DE/dynamic-engine-configuration-guide/Cloud/updating-data-service-and-route-tasks-in-dee "Sie können ohne Ausfallzeit die Artefakt-Version einer in einer Dynamic Engine-Umgebung implementierten Datenservices- oder Routen-Task aktualisieren oder deren Konfiguration ändern."), um eine erneute Implementierung auf Ihrem Kubernetes-Cluster auszulösen.