Contrôler la planification à l'aide des tolérances et des rejets de nœuds

Cette page présente les rejets et tolérances sur les clusters Anthos sur VMware (GKE On-Prem). Lorsque vous programmez le déploiement de charges de travail sur votre cluster, les rejets de nœuds vous aident à contrôler les nœuds sur lesquels vos charges de travail sont autorisées à s'exécuter.

Présentation

Lorsque vous soumettez l'exécution d'une charge de travail dans un cluster, le programmeur détermine l'emplacement des pods associés à la charge de travail. Le programmeur peut placer un pod sur n'importe quel nœud répondant aux exigences du pod en termes de processeur, de mémoire et de ressources personnalisées.

Si votre cluster exécute différentes charges de travail, vous pouvez choisir de contrôler quelles charges de travail peuvent s'exécuter sur un pool de nœuds particulier.

Un rejet de nœud vous permet de marquer un nœud afin que le programmeur l'ignore ou empêche son utilisation pour certains pods. Les tolérances forment une fonctionnalité complémentaire qui vous permet de désigner les pods pouvant être utilisés sur des nœuds "rejetés".

Les rejets et les tolérances fonctionnent conjointement pour s'assurer que les pods ne sont pas programmés sur des nœuds inappropriés.

Les rejets de nœuds sont des paires clé-valeur associées à un effet. Le tableau suivant répertorie les effets disponibles :

Effet Description
NoSchedule Les pods qui ne tolèrent pas ce rejet ne sont pas programmés sur le nœud ; les pods existants ne sont pas expulsés du nœud.
PreferNoSchedule Kubernetes évite de programmer les pods qui ne tolèrent pas ce rejet sur le nœud.
NoExecute Si le pod est déjà en cours d'exécution sur le nœud, il est expulsé de celui-ci. Dans le cas contraire, il n'est pas programmé sur le nœud.

Avantages de la définition de rejets de nœuds dans les clusters Anthos sur VMware

Bien que vous puissiez définir des rejets de nœuds à l'aide de la commande kubectl taint, l'utilisation de gkectl ou de la console Google Cloud pour définir un rejet de nœud présente les avantages suivants par rapport à kubectl:

  • Les rejets sont conservés lorsqu'un nœud est redémarré ou remplacé.
  • Les rejets sont créés automatiquement lorsqu'un nœud est ajouté à un pool de nœuds.
  • Lorsque vous utilisez gkectl pour ajouter des rejets, ceux-ci sont créés automatiquement lors de l'autoscaling du cluster. (L'autoscaling des pools de nœuds créés dans la console Google Cloud n'est pas disponible actuellement.)

Définir des rejets de nœuds

Vous pouvez définir des rejets de nœuds dans un pool de nœuds lorsque vous créez un cluster d'utilisateur ou après la création du cluster. Cette section montre l'ajout de rejets aux clusters déjà créés, mais le processus est le même lors de la création de clusters.

Vous pouvez ajouter un pool de nœuds et définir un rejet, ou mettre à jour un pool de nœuds existant et définir un rejet. Avant d'ajouter un autre pool de nœuds, vérifiez qu'il y a suffisamment d'adresses IP disponibles sur le cluster.

Si vous avez créé le cluster dans Google Cloud Console, vous pouvez utiliser la console Google Cloud pour ajouter ou mettre à jour un pool de nœuds.

Définir des rejets dans un nouveau pool de nœuds

Console

  1. Dans la console Google Cloud, accédez à la page Clusters d'Anthos.

    Accéder à la page "Clusters Anthos"

  2. Sélectionnez le projet Google Cloud dans lequel se trouve le cluster d'utilisateur.

  3. Dans la liste des clusters, cliquez sur le nom du cluster puis sur Afficher les détails dans le panneau Détails.

  4. Cliquez sur Ajouter un pool de nœuds.

  5. Configurez le pool de nœuds :

    1. Saisissez le nom du pool de nœuds.
    2. Saisissez le nombre de processeurs virtuels pour chaque nœud du pool (au moins quatre par nœud de calcul de cluster d'utilisateur).
    3. Saisissez la taille de la mémoire en mébioctets (Mio) pour chaque nœud du pool (8192 Mio au minimum par nœud de nœud de calcul de cluster d'utilisateur, doit être un multiple de 4).
    4. Dans le champ Instances dupliquées, saisissez le nombre de nœuds du pool (minimum 3).
    5. Sélectionnez le type d'image d'OS : Ubuntu Containerd ou COS.

    6. Saisissez la taille du disque de démarrage en gibioctets (Gio) (la valeur par défaut est 40 Gio).

  6. Dans la section Métadonnées du pool de nœuds (facultatif), cliquez sur + Ajouter un rejet. Saisissez la clé, la valeur et l'effet pour le rejet. Répétez l'opération autant de fois que nécessaire.

  7. Vous pouvez également cliquer sur + Ajouter des libellés Kubernetes. Saisissez la clé et la valeur du libellé. Répétez l'opération autant de fois que nécessaire.

  8. Cliquez sur Créer.

  9. La console Google Cloud affiche État du cluster : modifications en cours. Cliquez sur Afficher les détails pour afficher la Condition d'état de la ressource et les Messages d'état.

Ligne de commande

  1. Dans votre fichier de configuration de cluster d'utilisateur, remplissez la section nodePools.

    Vous devez spécifier les champs suivants :

    • nodePools.[i].name
    • nodePools[i].cpus
    • nodePools.[i].memoryMB
    • nodePools.[i].replicas

    Les champs suivants sont facultatifs. Si vous n'incluez pas nodePools[i].bootDiskSizeGB ou nodePools[i].osImageType, les valeurs par défaut sont utilisées.

  2. Remplissez la section nodePools[i].taints. Exemple :

    nodePools:
    - name: "my-node-pool"
      taints:
      - key: "staging"
        value: "true"
        effect: "NoSchedule"
    
  3. Vous pouvez également renseigner les sections suivantes :

    • nodePools[i].labels
    • nodePools[i].bootDiskSizeGB
    • nodePools[i].osImageType
    • nodePools[i].vsphere.datastore
    • nodePools[i].vsphere.tags
  4. Exécutez la commande suivante :

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
    

    Remplacez les éléments suivants :

    • [ADMIN_CLUSTER_KUBECONFIG] par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

    • [USER_CLUSTER_CONFIG] par le chemin d'accès au fichier de configuration du cluster d'utilisateur.

Définir des rejets dans un pool de nœuds existant

Console

  1. Dans la console Google Cloud, accédez à la page Clusters d'Anthos.

    Accéder à la page "Clusters Anthos"

  2. Sélectionnez le projet Google Cloud dans lequel se trouve le cluster d'utilisateur.

  3. Dans la liste des clusters, cliquez sur le nom du cluster puis sur Afficher les détails dans le panneau Détails.

  4. Cliquez sur l'onglet Nœuds.

  5. Cliquez sur le nom du pool de nœuds que vous souhaitez modifier.

  6. Cliquez sur Modifier à côté de la section Métadonnées du pool de nœuds (facultatif), puis sur + Ajouter un rejet. Saisissez la clé, la valeur et l'effet pour le rejet. Répétez l'opération autant de fois que nécessaire.

  7. Cliquez sur OK.

  8. Cliquez sur pour revenir à la page précédente.

  9. La console Google Cloud affiche État du cluster : modifications en cours. Cliquez sur Afficher les détails pour afficher la Condition d'état de la ressource et les Messages d'état.

Ligne de commande

  1. Dans le fichier de configuration du cluster d'utilisateur, accédez à la section nodePools du pool de nœuds que vous souhaitez mettre à jour.

  2. Renseignez le champ nodePools[i].taints. Exemple :

    nodePools:
    - name: "my-node-pool"
      taints:
      - key: "staging"
        value: "true"
        effect: "NoSchedule"
    
  3. Exécutez la commande suivante :

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG
    

    Remplacez les éléments suivants :

    • [ADMIN_CLUSTER_KUBECONFIG] par le chemin d'accès au fichier kubeconfig du cluster d'administrateur.

    • [USER_CLUSTER_CONFIG] par le chemin d'accès au fichier de configuration du cluster d'utilisateur.

Configurer des pods pour tolérer un rejet

Vous pouvez configurer les pods de sorte qu'ils tolèrent un rejet en incluant le champ tolerations dans leur spécification. Dans l'exemple suivant, le pod peut être planifié sur un nœud ayant le rejet dedicated=experimental:NoSchedule :

tolerations:
- key: dedicated
  operator: Equal
  value: experimental
  effect: NoSchedule

Pour obtenir d'autres exemples, consultez la section Rejets et tolérances.