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.

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

Créez un fichier de ressources PersistentVolumeClaim (PVC) Kubernetes.
Exemple
Créez un fichier nommé 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
```
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).

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.

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.

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.
Créez le PVC dans l'espace de noms de votre environnement de Dynamic Engine.
```
kubectl apply -f pvc-custom-claim.yaml
```

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.

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 <pod-name> -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 afin de déclencher un nouveau déploiement sur votre cluster Kubernetes.

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – faites-le-nous savoir.

Laissez vos commentaires ici