# Monter PersistentVolumeClaims de Kubernetes pour un stockage persistant dans le Dynamic Engine Utilisez PersistentVolumeClaims pour monter les volumes de stockage persistants pour que vos tâches d'intégration de données (y compris Big Data), vos services de données et vos tâches de Routes puissent accéder aux données des états, partager des données dans plusieurs pods et redémarrer le stockage persistant à travers les pods. ## Avant de commencer Pour plus d'informations, consultez [Prérequis et considérations à prendre en compte](https://help.qlik.com/talend/fr-FR/dynamic-engine-configuration-guide/Cloud/custom-kubernetes-resource-mounting). ## Pourquoi et quand exécuter cette tâche Monter PersistentVolumeClaims (PVC) de Kubernetes fournit un stockage persistant indépendant du cycle de vie des pods. Cela est utile dans les cas suivants : * stocker des données nécessitant de persister après les redémarrages des pods, * partager des données entre différents pods, * accéder à des volumes de données préexistants. ## Procédure 1. Créez un fichier de ressources PersistentVolumeClaim (PVC) Kubernetes. ### Exemple Créez un fichier nommé pvc-custom-claim.yaml : ``` cat < 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 ``` Remplacez $DYNAMIC\_ENGINE\_ENVIRONMENT\_ID par l'ID réel et mettez à jour storageClassName pour correspondre à la classe de stockage disponible de votre cluster. Pour conserver une certaine cohérence, utilisez la même classe de stockage que celle configurée pour votre environnement de Dynamic Engine (comme spécifié dans [Provisionner une classe de stockage dédiée aux services d'environnements du Dynamic Engine](https://help.qlik.com/talend/fr-FR/dynamic-engine-configuration-guide/Cloud/deploy-dynamic-engine-with-specific-storageclass "Configurez une classe de stockage spécifique pour les services d'environnement du Dynamic Engine au lieu d'utiliser la classe de stockage Kubernetes par défaut.")). Cet exemple utilise le provisioning dynamique : Le paramètre storageClassName ordonne à Kubernetes de créer automatiquement un PersistentVolume lorsque ce PVC est créé. Utilisez-le lorsque vous souhaitez que Kubernetes provisionne le stockage à la demande. Pour un provisioning statique (lorsqu'un·e administrateur·trice a déjà créé un PersistentVolume), remplacez la section spec entière par : ``` spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi volumeName: my-existing-pv ``` Remplacez my-existing-pv par le nom réel du PersistentVolume créé par votre administrateur·trice. Ne précisez pas storageClassName pour le provisioning statique. Utilisation de chaque type de provisioning : * Provisioning dynamique (avec storageClassName) — le stockage est créé automatiquement en cas de besoin. Utilisable dans la plupart des scénarios. * Provisioning statique (avec volumeName) — liaison avec un PersistentVolume existant. Utilisable lorsque des colonnes spécifiques sont pré-allouées ou nécessitent une configuration spéciale. 2. Créez un fichier de valeurs Helm configurant le montage du PVC. ### Exemple Créez un fichier nommé 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 ``` Cette configuration monte le PVC my-custom-claim-linked-to-a-static-or-dynamic-persistentvolume dans /tmp/data. Toutes les données écrites dans ce chemin persistent malgré les redémarrages des pods. 3. Déployez ou mettez à niveau votre environnement de Dynamic Engine pour créer l'espace de noms requis. ``` 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 ``` Remplacez ${DYNAMIC\_ENGINE\_VERSION} par la version de votre environnement. Cette commande crée l'environnement de Dynamic Engine et son espace de noms associé qlik-processing-env-$DYNAMIC\_ENGINE\_ENVIRONMENT\_ID. 4. Créez le PVC dans l'espace de noms de votre environnement de Dynamic Engine. ``` kubectl apply -f pvc-custom-claim.yaml ``` 5. Mettez à niveau votre environnement de Dynamic Engine avec le montage du PVC. ``` 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 ``` Remplacez $DYNAMIC\_ENGINE\_ENVIRONMENT\_ID par l'ID de votre environnement et ${DYNAMIC\_ENGINE\_VERSION} par la version de votre environnement. 6. Vérifiez que le PVC est monté dans les pods en cours d'exécution. ``` # Check PVC status kubectl get pvc -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID # Verify the mounted volume kubectl get pod -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID \ -o jsonpath='{.spec.volumes[?(@.name=="external-data-storage")]}' | jq . ``` La sortie attendue affiche la référence au PVC : ``` { "name": "external-data-storage", "persistentVolumeClaim": { "claimName": "my-custom-claim-linked-to-a-static-or-dynamic-persistentvolume" } } ``` ## Résultats Vos tâches dans l'environnement de Dynamic Engine ont à présent accès au stockage persistant avec PersistentVolumeClaims. Les données écrites dans le répertoire monté persistent à travers les redémarrages, nouveaux déploiements et mises à niveau des environnements des pods. Si la configuration est faite avec ReadWriteMany, plusieurs pods peuvent accéder au même PVC. Lorsque des volumes persistants sont mis à jour, le comportement de chargement varie en fonction du type de tâche : * Pour les tâches de Jobs d'intégration de données (y compris Big Data), la prochaine exécution de tâche utilisera automatiquement les valeurs mises à jour. * Pour les tâches de Routes et de services de données, qui s'exécutent en continu, les modifications ne sont pas automatiquement chargées dans les conteneurs en cours d'exécution. Pour appliquer la modification des identifiants à ces tâches, [mettez à jour la tâche dans Talend Management Console](https://help.qlik.com/talend/fr-FR/dynamic-engine-configuration-guide/Cloud/updating-data-service-and-route-tasks-in-dee "Vous pouvez mettre à jour la version de vos artefacts ou modifier la configuration d'une tâche de service de données ou de Route déployée dans un environnement de Dynamic Engine sans interrompre vos activités.") afin de déclencher un nouveau déploiement sur votre cluster Kubernetes.