Créer et gérer des pools de nœuds

À partir de la version 1.3 de GKE On-Prem, vous pouvez créer dans votre cluster d'utilisateur un groupe de nœuds ayant tous la même configuration, : pour cela, vous définissez un pool de nœuds dans le fichier de configuration de ce cluster. Vous pouvez ensuite gérer ce pool de nœuds séparément sans affecter les autres nœuds du cluster. En savoir plus sur les pools de nœuds.

Vous pouvez définir un ou plusieurs pools de nœuds dans le fichier de configuration de tout cluster d'utilisateur. La création d'un pool de nœuds provoque la création de nœuds supplémentaires dans le cluster d'utilisateur. La gestion des pools de nœuds, y compris leur création, leur mise à jour et leur suppression au sein d'un cluster d'utilisateur, consiste à modifier la section nodePools de votre fichier de configuration et à déployer ces modifications sur votre cluster existant à l'aide de la commande gkectl update cluster. Notez que la suppression des pools de nœuds entraîne la suppression immédiate des nœuds associés, même si ceux-ci sont en train d'exécuter une charge de travail.

Exemple de pool de nœuds :

nodePools:
  - name: pool-1
    cpus: 4
    memoryMB: 8192
    replicas: 5

Conseil pour les nouvelles installations : Créez un premier cluster d'utilisateur et définissez les pools de nœuds dans ce cluster. Utilisez ensuite le fichier de configuration de ce cluster pour créer des clusters d'utilisateur supplémentaires avec les mêmes paramètres de pool de nœuds.

Avant de commencer

  • Limites de prise en charge :

    • Seuls les clusters d'utilisateur version 1.3.0 ou ultérieure sont compatibles.

    • Les pools de nœuds dans les clusters d'administrateur ne sont pas acceptés.

    • La commande gkectl update cluster est actuellement entièrement compatible avec la mise à jour des pools de nœuds et l'ajout d'adresses IP statiques. Elle permet également d'activer Cloud Audit Logging, et d'activer ou de désactiver la réparation automatique. Toutes les autres modifications du fichier de configuration sont ignorées.

    • Bien que les nœuds d'un pool de nœuds puissent être gérés séparément des autres nœuds, les nœuds d'un cluster ne peuvent pas être mis à jour séparément. Tous les nœuds sont mis à niveau lorsque vous mettez à niveau le cluster.

  • Ressources :

    • Le changement de la valeur replicas d'un pool de nœuds est la seule modification que vous pouvez déployer sans interrompre les charges de travail en cours d'exécution.

      Important : Si vous déployez une autre modification dans la configuration d'un pool de nœuds, les nœuds de ce pool seront recréés. Il faut donc vous assurer au préalable que ce pool de nœuds n'exécute pas de charge de travail ne devant pas être interrompue.

    • Lorsque vous déployez vos modifications de pool de nœuds, les nœuds indésirables sont supprimés après la création ou la mise à jour des nœuds souhaités. L'une des conséquences de cette stratégie est que même si le nombre total de nœuds reste le même avant et après une mise à jour, l'opération de mise à jour proprement dite peut nécessiter davantage de ressources (par exemple, des adresses IP). Vous devez vérifier qu'il y a suffisamment d'adresses IP disponibles lors des pics d'activité.

Créer et mettre à jour des pools de nœuds

Vous pouvez gérer un pool de nœuds en modifiant puis en déployant le fichier de configuration d'un cluster d'utilisateur. Vous pouvez créer et déployer un ou plusieurs pools de nœuds dans un cluster d'utilisateur.

Pour créer ou mettre à jour des pools de nœuds :

  1. Dans un éditeur, ouvrez le fichier de configuration du cluster d'utilisateur dans lequel vous souhaitez créer ou mettre à jour des pools de nœuds.

  2. Définissez un ou plusieurs pools de nœuds dans la section nodePools du fichier de configuration du cluster d'utilisateur :

    1. Configurez les attributs de pool de nœuds minimaux requis. Vous devez spécifier les attributs suivants pour chaque pool de nœuds :

      • nodePools.name : nom unique du pool de nœuds. La mise à jour de cet attribut provoque la recréation des nœuds. Exemple : - name: pool-1

      • nodePools.cpus : indique le nombre de processeurs alloués à chaque nœud de calcul du pool. La mise à jour de cet attribut provoque la recréation des nœuds. Exemple : cpus: 4

      • nodePools.memoryMB : quantité de mémoire, en mégaoctets, allouée à chaque nœud de calcul du cluster d'utilisateur. La mise à jour de cet attribut provoque la recréation des nœuds. Exemple : memoryMB: 8192

      • nodePools.replicas : indique le nombre total de nœuds de calcul dans le pool. Le cluster d'utilisateur exploite des nœuds dans l'ensemble des pools pour exécuter des charges de travail. Vous pouvez mettre à jour cet attribut sans perturber les nœuds ni les charges de travail en cours d'exécution. Exemple : replicas: 5

      Notez que même si certains des attributs nodePools sont identiques à workernode (DHCP | adresse IP statique) dans l'ancien fichier de configuration, la section workernode reste obligatoire dans les anciens fichiers de configuration de chaque cluster d'utilisateur. Vous ne pouvez pas supprimer la section workernode ni la remplacer par une section nodepools. La section workernode n'existe plus dans le nouveau fichier de configuration du cluster d'utilisateur. Vous devez définir au moins un pool de nœuds pour un cluster d'utilisateur et vous assurer qu'il y a suffisamment de nœuds non rejetés en remplacement du pool workernode par défaut dans les anciens fichiers de configuration.

      Exemple :

      nodePools:
      - name: pool-1
        cpus: 4
        memoryMB: 8192
        replicas: 5
      

      Consultez la section Exemples pour obtenir un exemple de fichier de configuration pour un cluster d'utilisateur avec plusieurs pools de nœuds.

    2. Configurez les attributs de pool de nœuds facultatifs. Vous pouvez ajouter des libellés et des rejets à la configuration de votre pool de nœuds pour orienter les charges de travail des nœuds. Vous pouvez également définir quel datastore vSphere est utilisé par votre pool de nœuds.

      • nodePools.labels : une ou plusieurs paires clé/valeur (au format key : value) pour identifier de manière unique vos pools de nœuds. La key et la value doivent commencer par une lettre ou un chiffre. Elles peuvent contenir des lettres, des chiffres, des traits d'union, des points et des traits de soulignement (jusqu'à 63 caractères chacune).

        Pour obtenir des informations détaillées sur la configuration, consultez la section sur les libellés.

        Important : Vous ne pouvez pas spécifier les clés de libellé suivantes, car elles sont réservées pour GKE On-Prem : kubernetes.io, k8s.io et googleapis.com.

        Exemple :

        labels:
          key1: value1
          key2: value2
        
      • nodePools.taints : ensemble(s) key (clé), value (valeur) et effect (effet) définissant des taints (rejets) pour les pools de nœuds. Ces taints (rejets) correspondent aux tolerations (tolérances) que vous configurez sur les pods.

        La key est obligatoire alors que la value est facultative. Elles doivent toutes deux commencer par une lettre ou un chiffre, et peuvent contenir des lettres, des chiffres, des tirets, des points et des traits de soulignement, jusqu'à 253 caractères. Vous pouvez éventuellement préfixer la key avec un sous-domaine DNS suivi d'une barre oblique /. Exemple : example.com/my-app.

        Les valeurs valides pour l'effect sont : NoSchedule, PreferNoSchedule et NoExecute.

        Pour obtenir des informations détaillées sur la configuration, consultez la section sur les rejets.

        Exemple :

        taints:
          - key: key1
            value: value1
            effect: NoSchedule
        
      • nodePools.bootDiskSizeGB : indique la taille (en gigaoctets) de disque de démarrage allouée à chaque nœud de calcul du pool. Cette configuration est disponible à partir de la version 1.5.0 de GKE On-Prem.

        Exemple :

        bootDiskSizeGB: 40
        
      • nodePools.vsphere.datastore : spécifie le datastore vSphere sur lequel chaque nœud du pool sera créé. Cette valeur remplace le datastore vSphere par défaut du cluster d'utilisateur.

        Exemple :

        vsphere:
          datastore: datastore_name
        

    Consultez la section Exemples pour voir un exemple de configuration avec plusieurs pools de nœuds.

  3. Utilisez la commande gkectl update cluster pour déployer vos modifications sur le cluster d'utilisateur.

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG_FILE] --dry-run --yes
    
    où :
    • [ADMIN_CLUSTER_KUBECONFIG] : spécifie le fichier kubeconfig de votre cluster d'administrateur.
    • [USER_CLUSTER_CONFIG_FILE] : spécifie le fichier configuration de votre cluster d'utilisateur.
    • --dry-run : option facultative. Ajoutez cette option pour afficher uniquement la modification. Aucune modification n'est déployée dans le cluster d'utilisateur.
    • --yes : option facultative. Ajoutez cette option pour exécuter la commande silencieusement. L'invite permettant de confirmer que vous souhaitez continuer est alors désactivée.

    Si vous avez annulé la commande prématurément, vous pouvez exécuter à nouveau la même commande pour terminer l'opération et déployer vos modifications sur le cluster d'utilisateur.

    Si vous devez revenir en arrière, faites les modifications inverses dans le fichier de configuration, puis déployez à nouveau les modifications dans votre cluster d'utilisateur.

  4. Vérifiez que les modifications sont bien prises en compte en inspectant tous les nœuds. Exécutez la commande suivante pour répertorier tous les nœuds du cluster d'utilisateur :

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes -o wide
    

    [USER_CLUSTER_KUBECONFIG] est le fichier kubeconfig de votre cluster d'utilisateur.

Supprimer un pool de nœuds

Pour supprimer un pool de nœuds d'un cluster d'utilisateur, procédez comme suit :

  1. Supprimez sa définition de la section nodePools du fichier de configuration du cluster d'utilisateur.

  2. Assurez-vous qu'aucune charge de travail n'est en cours d'exécution sur les nœuds concernés.

  3. Déployez vos modifications en exécutant la commande gkectl update cluster :

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG_FILE] --dry-run --yes
    
    où :
    • [ADMIN_CLUSTER_KUBECONFIG] : spécifie le fichier kubeconfig de votre cluster d'administrateur.
    • [USER_CLUSTER_CONFIG_FILE] : spécifie le fichier configuration de votre cluster d'utilisateur.
    • --dry-run : option facultative. Ajoutez cette option pour afficher uniquement la modification. Aucune modification n'est déployée dans le cluster d'utilisateur.
    • --yes : option facultative. Ajoutez cette option pour exécuter la commande silencieusement. L'invite permettant de confirmer que vous souhaitez continuer est alors désactivée.
  4. Vérifiez que les modifications sont bien prises en compte en inspectant tous les nœuds. Exécutez la commande suivante pour répertorier tous les nœuds du cluster d'utilisateur :

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes -o wide
    

    [USER_CLUSTER_KUBECONFIG] est le fichier kubeconfig de votre cluster d'utilisateur.

Exemples

Il y a quatre pools de nœuds dans l'exemple de configuration suivant, avec des attributs différents pour chacun :

  • pool-1 : seuls les attributs minimaux requis sont spécifiés.
  • pool-2 : le datastore vSphere est spécifié.
  • pool-3 : bootDiskSizeGB est spécifié.
  • pool-4 : des rejets et des libellés sont spécifiés.
  • pool-5 : tous les attributs sont spécifiés.
apiVersion: v1
kind: UserCluster
...
# (Required) List of node pools. The total un-tainted replicas across all node pools
# must be greater than or equal to 3
nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 5
- name: pool-2
  cpus: 8
  memoryMB: 16384
  replicas: 3
  vsphere:
    datastore: my_datastore
- name: pool-3
  cpus: 8
  memoryMB: 8192
  replicas: 3
  bootDiskSizeGB: 40
- name: pool-4
  cpus: 4
  memoryMB: 8192
  replicas: 5
  taints:
    - key: "example-key"
      effect: NoSchedule
  labels:
    environment: production
    app: nginx
- name: pool-5
  cpus: 8
  memoryMB: 16384
  replicas: 3
  taints:
    - key: "my_key"
      value: my_value1
      effect: NoExecute
  labels:
    environment: test
  vsphere:
    datastore: my_datastore
  bootDiskSizeGB: 60
...

Dépannage

  • En général, la commande gkectl update cluster fournit des détails en cas d'échec. Si la commande aboutit et que vous ne voyez pas les nœuds, suivez le guide Diagnostiquer les problèmes de cluster pour résoudre le problème.

  • Il est possible que les ressources du cluster soient insuffisantes. Par exemple, il peut arriver qu'il n'y ait plus d'adresse IP disponible lors de la création ou de la mise à jour du pool de nœuds. Consultez la page Redimensionner un cluster d'utilisateur pour savoir comment vérifier que des adresses IP sont disponibles.

  • Vous pouvez également consulter le guide général de dépannage.

  • Symptôme : Plus rien ne se passe après le message Creating node MachineDeployment(s) in user cluster….

    La création ou la mise à jour des pools de nœuds dans votre cluster d'utilisateur peut prendre un certain temps. Cependant, si le temps d'attente est extrêmement long et que vous soupçonnez un échec, vous pouvez exécuter les commandes suivantes :

    1. Exécutez la commande kubectl get nodes pour connaître l'état des nœuds.
    2. Pour tous les nœuds qui ne sont pas "Ready" (prêts), exécutez la commande kubectl describe node [node_name] pour obtenir plus de détails.