Configurer des règles de tolerations (tolérances) pour Dynamic Engine

Utilisez des tolerations (tolérances) dans les charts Helm Dynamic Engine pour permettre la planification des pods sur des nœuds Kubernetes marqués.

À partir de Dynamic Engine v1.4.0, vous pouvez définir les règles de tolerations (tolérances) dans les fichiers de valeurs Helm pour contrôler quels nœuds marqués sont éligibles pour la planification des pods. Appliquez une règle uniforme à l'ensemble des pods ou configurez des règles distinctes pour les pods de service d'infrastructure et les pods de workload client tels que les Jobs d'intégration de données, les Jobs de service de données et les Routes.

Remarque : Vous pouvez appliquer cette personnalisation lors de l'installation initiale des charts ou au cours d'une mise à niveau.

Avant de commencer

Les définitions des ressources personnalisées dynamic-engine-crd doivent avoir été installées à l'aide du chart Helm oci://ghcr.io/talend/helm/dynamic-engine-crd. Si ce n'est pas le cas, exécutez les commandes suivantes pour l'installation :
1. Trouvez la version du chart à utiliser :
  - Exécutez la commande Helm suivante :
    helm show chart oci://ghcr.io/talend/helm/dynamic-engine-crd --version <engine_version>
  - Visualisez la version directement depuis Talend Management Console ou consultez le Dynamic Engine journal de modification de la version du chart dans votre version de Dynamic Engine.
  - Utilisez un appel d'API pour l'endpoint de version de Dynamic Engine (en anglais).
2. Exécutez la commande suivante pour installer le chart Helm dans une version donnée :
```
helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
```
  Remplacez <helm_chart_version> par la version du chart supportée par votre version du Dynamic Engine.
  Si vous ne spécifiez pas la version, vous installez la dernière version disponible du chart dynamic-engine-crd.
Vos nœuds Kubernetes doivent être marqués à l'aide des valeurs que vous souhaitez tolérer.
Vous devez avoir des connaissances de base des marques et tolerations (tolérances) Kubernetes (en anglais).

Pourquoi et quand exécuter cette tâche

Par défaut, les pods Dynamic Engine ne sont pas planifiés sur les noeuds marqués, sauf si vous configurez une règle de toleration (tolérance) correspondante. Une marque sur un nœud empêche l'ordonnanceur de placer des pods auxquels il manque une toleration (tolérance) correspondante. Lorsque tous les pods peuvent partager le même pool de nœuds marqués, utilisez une règle globale uniforme. Configurez des règles spécifiques au workload distinctes lorsque les pods de service d'infrastructure et les pods de workload client doivent être planifiés sur des nœuds marqués différents.

Procédure

Sur la machine de Kubernetes, décompressez le fichier ZIP de déploiement Helm précédemment téléchargé.
Créez un fichier de valeurs personnalisées avec global.tolerations pour autoriser la planification de tous les pods sur des nœuds portant la marque cible.
Exemple
Dans cet exemple, les nœuds sont marqués à l'aide de dedicated=dynamic-engine:NoSchedule. Le fichier de valeurs suivant crée une toleration (tolérance) qui correspond à cette marque :
```
cat <<EOF > custom-tolerations-values.yaml
global:
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "dynamic-engine"
      effect: "NoSchedule"
EOF
```

Déployez Dynamic Engine et l'environnement Dynamic Engine avec la règle de toleration (tolérance) globale.

Exemple

helm upgrade --install dynamic-engine-$DYNAMIC_ENGINE_ID \
  -f $DYNAMIC_ENGINE_ID-values.yaml \
  -f custom-tolerations-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine \
  --version $DYNAMIC_ENGINE_VERSION

helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
  -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \
  -f custom-tolerations-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine-environment \
  --version $DYNAMIC_ENGINE_VERSION

Après le déploiement, les pods figurant dans les espaces de noms qlik-dynamic-engine et qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID peuvent être planifiés sur des nœuds marqués à l'aide de dedicated=dynamic-engine:NoSchedule.

Pour configurer des règles de tolerations (tolérances) distinctes pour les pods de service d'infrastructure et les pods de workload client, suivez les étapes 4 et 5 au lieu des étapes 2 et 3.

Créez des règles de tolerations (tolérances) distinctes pour les pods de service d'infrastructure et les pods de workload client.
Les règles de tolerations (tolérances) définies sur global.tolerations s'appliquent à tous les pods créés par le chart. Les règles définies sur configuration.jobDeployment.tolerations et sur configuration.dataServiceRouteDeployment.tolerations s'appliquent uniquement aux pods de workload client. Cela inclut les Jobs d'intégration de données, les Jobs de service de données et les Routes. Si vous définissez des règles spécifiques au workload, elles remplacent les règles globales pour ces types de pods uniquement. Si vous ne définissez pas de règles spécifiques au workload, tous les pods utilisent les règles de tolerations (tolérances) globales.

Exemple
Dans cet exemple, les pods de service d'infrastructure tolérent dedicated=dynamic-engine:NoSchedule et les pods de workload client tolèrent dedicated=dynamic-engine-jobs-and-routes:NoSchedule. Créez deux fichiers de valeurs personnalisées :
```
cat <<EOF > custom-tolerations-values.yaml
global:
  tolerations:
    - key: "dedicated"
      operator: "Equal"
      value: "dynamic-engine"
      effect: "NoSchedule"
EOF

cat <<EOF > custom-jobDeployment-dataServiceRouteDeployment-tolerations-values.yaml
configuration:
  jobDeployment:
    tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "dynamic-engine-jobs-and-routes"
        effect: "NoSchedule"
  dataServiceRouteDeployment:
    tolerations:
      - key: "dedicated"
        operator: "Equal"
        value: "dynamic-engine-jobs-and-routes"
        effect: "NoSchedule"
EOF
```
Déployez les charts avec les règles de tolerations (tolérances) divisées.
Exemple
Appliquez le fichier de tolerations (tolérances) global aux deux charts. Appliquez le fichier spécifique au workload uniquement au chart d'environnement :
```
helm upgrade --install dynamic-engine-$DYNAMIC_ENGINE_ID \
  -f $DYNAMIC_ENGINE_ID-values.yaml \
  -f custom-tolerations-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine \
  --version $DYNAMIC_ENGINE_VERSION

helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
  -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \
  -f custom-tolerations-values.yaml \
  -f custom-jobDeployment-dataServiceRouteDeployment-tolerations-values.yaml \
  oci://ghcr.io/talend/helm/dynamic-engine-environment \
  --version $DYNAMIC_ENGINE_VERSION
```
Après le déploiement, les pods de service d'infrastructure figurant dans les espaces de noms qlik-dynamic-engine et qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID peuvent être planifiés sur des nœuds marqués à l'aide de dedicated=dynamic-engine:NoSchedule. Les pods de workload client figurant dans l'espace de noms qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID peuvent être planifiés sur des nœuds marqués à l'aide de dedicated=dynamic-engine-jobs-and-routes:NoSchedule.

Résultats

Après le déploiement correct des charts :

Les services Dynamic Engine figurant dans l'espace de noms qlik-dynamic-engine peuvent être planifiés sur des nœuds marqués à l'aide de dedicated=dynamic-engine:NoSchedule.
Les services d'environnement Dynamic Engine figurant dans l'espace de noms qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID peuvent être planifiés sur des nœuds marqués à l'aide de dedicated=dynamic-engine:NoSchedule.
Lors de l'utilisation de règles de tolerations (tolérances) distinctes, les pods de workload client (Jobs d'intégration de données, Jobs de service de données et pods de Route) figurant dans l'espace de noms qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID peuvent être planifiés sur des nœuds marqués à l'aide de dedicated=dynamic-engine-jobs-and-routes:NoSchedule.

Remarque : Vous pouvez combiner des tolerations (tolérances) avec des règles nodeSelector et affinity (affinité) pour contrôler le placement des pods via des libellés et des marques de nœud. Consultez Configurer les règles affinity (affinité) et nodeSelector pour Dynamic Engine.

Résolution de problèmes :

Si les pods restent à l'état Pending (En attente) après l'ajout de tolerations (tolérances), vérifiez qu'il n'existe pas d'incohérence entre les marques des nœuds et les tolerations (tolérances) des pods.

Les situations les plus fréquentes peuvent être :

Le nœud est marqué à l'aide de dedicated=dynamic-engine:NoSchedule, mais le pod n'a pas de toleration (tolérance) pour la clé dedicated.
La toleration (tolérance) de pod utilise le mauvais élément value, operator ou effect, si bien qu'elle ne correspond pas exactement à la marque.
Le nœud utilise NoExecute et le pod tolère uniquement NoSchedule, si bien que l'ordonnanceur peut tout de même rejeter ou expulser le pod.

Pour inspecter le problème, utilisez les commandes suivantes :

Dans le pod, recherchez les détails de l'échec de planification :
```
kubectl describe pod <pod-name> -n <namespace>
```
Recherchez les sections Events (Événements) et Tolerations (Tolérances). Un événement de planification en échec nomme la marque spécifique qui n'a pas été tolérée.
Accédez aux événements d'échec de planification triés par heure :
```
kubectl get events -n <namespace> --sort-by=.lastTimestamp
```
Recherchez les messages FailedScheduling qui référencent des marques sans toleration (tolérance) correspondante.
Comparez les marques des nœuds et les tolerations (tolérances) des pods :
```
kubectl describe node <node-name>
```
Vérifiez la section Taints (Marques). Les éléments key, value, operator et effect de la marque doivent tous parfaitement correspondre à la toleration (tolérance) du pod.
Identifiez sur quel nœud un pod est arrivé :
```
kubectl get pods -n <namespace> -o wide
```
Utilisez cette commande pour voir l'attribution du nœud, puis inspectez ce nœud à l'aide de kubectl describe node.

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