Accéder au contenu principal Passer au contenu complémentaire

Configurer les règles affinity et nodeSelector pour Dynamic Engine

Utilisez les règles nodeSelector et affinity dans les charts Helm du Dynamic Engine afin de contrôler les planifications des pods à travers les différents groupes de nœuds dans votre cluster Kubernetes.

À partir de la version 1.1.0 de Dynamic Engine, vous pouvez configurer des règles d'affinité spécifiques pour isoler des services sur des nœuds spécifiques à des fins de sécurité, performance ou optimisation des ressources. Par exemple, vous pouvez attribuer un grand groupe de nœuds pour les exécutions intensives de pods.

La version 1.1.0 de Dynamic Engine supporte les règles nodeSelector (sélection simple basée sur des libellés) et affinity (logique de planification complexe) dans les fichiers de valeurs Helm.

Note InformationsImportant : Cette personnalisation peut être appliquée 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 graphique 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.

  • Votre cluster Kubernetes doit être configuré avec plusieurs groupes de nœuds (pools de nœuds) et les libellés appropriés. Consultez la documentation associée de votre fournisseur de Cloud pour définir cette configuration. Par exemple, si vous utilisez Kubernetes avec GKE, consultez la documentation Create and manage cluster and node pool labels (en anglais).
  • Vous devez avoir des connaissances de base des règles d'affinité de Kubernetes (affinity rules) (en anglais).

Pourquoi et quand exécuter cette tâche

Par défaut, les pods du Dynamic Engine sont planifiés sur les nœuds disponibles de votre cluster. Avec les règles d'affinité (affinity) et de sélecteur de nœuds (node selector), vous pouvez contrôler le placement des pods pour parvenir à vos objectifs, par exemple :

  • Isoler des services de manière permanente pour les nœuds dédiés les plus petits.
  • Exécuter des workloads (charges de travail) comme des Jobs, Routes ou services de données sur des nœuds plus volumineux ayant des types d'instances particuliers.
Les libellés des nœuds d'exemple à utiliser sont :
  • instanceType=large
  • instanceType=medium
  • qlik-dynamic-engine-tasks=true

Procédure

  1. Sur la machine de Kubernetes, décompressez le fichier ZIP de déploiement Helm précédemment téléchargé.
  2. Créez un fichier de valeurs personnalisées utilisant nodeSelector pour les règles de planification globales.

    Exemple

    Dans cet exemple, une règle globale est définie pour exécuter des services permanents pour l'infrastructure sur des nœuds medium. Cette règle planifie tous les Dynamic Engine et les pods d'environnement sur des nœuds dont le libellé est instanceType=medium :
    cat <<EOF > custom-medium-instance-for-infrastructure-values.yaml
    global:
      nodeSelector:
        instanceType: medium
    EOF
    La règle nodeSelector convient pour une correspondance exacte simple. Elle ne supporte pas les expressions logiques.
  3. Vous pouvez également créer un fichier de valeurs personnalisées utilisant les règles affinity pour obtenir le même résultat, avec une logique de planification plus avancée.

    Exemple

    Cet exemple produit le même résultat que l'approche avec nodeSelector, mais utilise nodeAffinity :
    cat <<EOF > custom-medium-instance-for-infrastructure-values.yaml
    global:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: instanceType
                    operator: In
                    values: medium
    EOF
    Note InformationsConseil : Les règles nodeSelector et affinity peuvent être combinées. Si vous spécifiez les deux, un nœud doit répondre aux deux règles pour le pod sur lequel effectuer la planification.
  4. Déployez un Dynamic Engine et l'environnement du Dynamic Engine avec les règles de planification globales.
    helm upgrade --install dynamic-engine-$DYNAMIC_ENGINE_ID -f $DYNAMIC_ENGINE_ID-values.yaml  \
     -f custom-medium-instance-for-infrastructure-values.yaml \
     oci://myregistry.example.com/docker-ghcr-io-remote/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-medium-instance-for-infrastructure-values.yaml \
     oci://myregistry.example.com/docker-ghcr-io-remote/talend/helm/dynamic-engine-environment \
     --version $DYNAMIC_ENGINE_VERSION
  5. Pour une planification spécifique à la charge de travail, créez un autre fichier de valeurs personnalisées restreignant les exécutions de pods à un groupe de nœuds volumineux.

    Exemple

    Dans cet exemple, une règle spécifique est définie pour restreindre des tâches d'intégration de données et des tâches de services de données et de Routes aux nœuds volumineux (large) ayant le libellé qlik-dynamic-engine-tasks=true :
    cat <<EOF > custom-jobDeployment-dataServiceRouteDeployment-nodeSelector-values.yaml
    configuration:
      jobDeployment:
        nodeSelector:
          instanceType: large
          qlik-dynamic-engine-tasks: "true"
      dataServiceRouteDeployment:
        nodeSelector:
          instanceType: large
          qlik-dynamic-engine-tasks: "true"
    EOF
  6. Déployez l'environnement du Dynamic Engine avec des règles de planification spécifiques à la charge de travail (workload).

    Exemple

    Cette règle de workload est spécifique aux services de traitement de tâches et s'applique uniquement à un environnement de Dynamic Engine.
    helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
     -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml  \
     -f custom-jobDeployment-dataServiceRouteDeployment-nodeSelector-values.yaml \
     oci://myregistry.example.com/docker-ghcr-io-remote/talend/helm/dynamic-engine-environment \
     --version $DYNAMIC_ENGINE_VERSION

Résultats

Une fois correctement déployés, les Dynamic Engine et les pods d'environnement sont planifiés en fonction des règles affinity et nodeSelector personnalisées. Les services permanents pour l'infrastructure s'exécutent sur leurs nœuds désignés et les workloads clients s'exécutent sur des nœuds optimisés pour leurs prérequis en ressources.

Résolution de problèmes :

Si un pod (ou plusieurs pods) ne peuvent être planifiés sur un nœud, utilisez les étapes suivantes pour diagnostiquer et résoudre le problème.

  1. Identifier l'échec de la planification :

    Utilisez la commande kubectl describe pod pour obtenir des informations détaillées concernant l'erreur de planification :

    kubectl describe pod <pod-name> -n <namespace>

    Consultez la section Events (Événements), qui fournit des indices concernant l'échec de la planification. Les raisons les plus fréquentes peuvent être :

    • Les règles ne correspondent à aucun nœud
    • Processeur insuffisant ou ressources en mémoire insuffisantes sur les nœuds disponibles
    • Problèmes de marques (taints) et tolérance (toleration) sur les nœuds, empêchant la planification des pods
  2. Vérifier les règles :

    Assurez-vous que les nœuds ont bien les libellés requis spécifiés dans vos règles :

    kubectl get nodes --show-labels

    Comparez les libellés de vos nœuds et les libellés de vos fichiers de valeurs.

  3. Vérifier les contraintes des ressources :

    L'une des causes d'échec de planification les plus répandues est l'insuffisance des ressources (processeur, mémoire). Vérifiez les demandes et les limites des ressources dans vos pods :

    kubectl describe nodes

    Si votre cluster n'a pas suffisamment de nœuds pour répondre aux demandes de ressources, mettez-le à l'échelle en ajoutant des nœuds.

  4. Vérifiez les spécifications des marques et tolérances sur les nœuds désignés.

    Les marques peuvent empêcher les nœuds de planifier certains pods. Si vos nœuds ont des marques et que vos pods n'ont pas de tolérance correspondante, les pods ne peuvent être planifiés. Pour plus d'informations concernant les marques et tolérances Kubernetes, consultez Taints and Tolerations (en anglais).

    Dynamic Engine ne supporte ni les marques, ni les tolérances dans les charts Helm. Si vos nœuds comportent des marques, vous pouvez supprimer ces marques ou utiliser un groupe de nœuds différent pour le déploiement du Dynamic Engine.

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.