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] : 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
   

   où [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] : 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
   

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

Examples

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
...

Cliquez pour afficher le modèle généré.

apiVersion: v1
kind: UserCluster
# (Required) A unique name for this cluster
name: ""
# (Required) GKE on-prem version (example: 1.3.0-gke.16)
gkeOnPremVersion: ""
# # (Optional) vCenter configuration (default: inherit from the admin cluster)
# vCenter:
#   # Resource pool to use. Specify [VSPHERE_CLUSTER_NAME]/Resources to use the default
#   # resource pool
#   resourcePool: ""
#   datastore: ""
#   # Provide the path to vCenter CA certificate pub key for SSL verification
#   caCertPath: ""
#   # The credentials to connect to vCenter
#   credentials:
#     # reference to external credentials file
#     fileRef:
#       # read credentials from this file
#       path: ""
#       # entry in the credential file
#       entry: ""
# (Required) Network configuration; vCenter section is optional and inherits from
# the admin cluster if not specified
network:
  # # (Optional) This section overrides ipBlockFile values. Use with ipType "static" mode.
  # # Used for seesaw nodes as well
  # hostConfig:
  #   # List of DNS servers
  #   dnsServers:
  #   - ""
  #   # List of NTP servers
  #   ntpServers:
  #   - ""
  #   # # List of DNS search domains
  #   # searchDomainsForDNS:
  #   # - ""
  ipMode:
    # (Required) Define what IP mode to use ("dhcp" or "static")
    type: dhcp
    # # (Required when using "static" mode) The absolute or relative path to the yaml file
    # # to use for static IP allocation. Hostconfig part will be overwritten by network.hostconfig
    # # if specified
    # ipBlockFilePath: ""
  # (Required) The Kubernetes service CIDR range for the cluster. Must not overlap
  # with the pod CIDR range
  serviceCIDR: 10.96.0.0/12
  # (Required) The Kubernetes pod CIDR range for the cluster. Must not overlap with
  # the service CIDR range
  podCIDR: 192.168.0.0/16
  vCenter:
    # vSphere network name
    networkName: ""
# (Required) Load balancer configuration
loadBalancer:
  # (Required) The VIPs to use for load balancing
  vips:
    # Used to connect to the Kubernetes API
    controlPlaneVIP: ""
    # Shared by all services for ingress traffic
    ingressVIP: ""
  # (Required) Which load balancer to use "F5BigIP" "Seesaw" or "ManualLB". Uncomment
  # the corresponding field below to provide the detailed spec
  kind: Seesaw
  # # (Required when using "ManualLB" kind) Specify pre-defined nodeports
  # manualLB:
  #   # NodePort for ingress service's http (only needed for user cluster)
  #   ingressHTTPNodePort: 30243
  #   # NodePort for ingress service's https (only needed for user cluster)
  #   ingressHTTPSNodePort: 30879
  #   # NodePort for control plane service
  #   controlPlaneNodePort: 30562
  #   # NodePort for addon service (only needed for admin cluster)
  #   addonsNodePort: 0
  # # (Required when using "F5BigIP" kind) Specify the already-existing partition and
  # # credentials
  # f5BigIP:
  #   address: ""
  #   credentials:
  #     # reference to external credentials file
  #     fileRef:
  #       # read credentials from this file
  #       path: ""
  #       # entry in the credential file
  #       entry: ""
  #   partition: ""
  #   # # (Optional) Specify a pool name if using SNAT
  #   # snatPoolName: ""
  # (Required when using "Seesaw" kind) Specify the Seesaw configs
  seesaw:
    # (Required) The absolute or relative path to the yaml file to use for IP allocation
    # for LB VMs. Must contain one or two IPs. Hostconfig part will be overwritten
    # by network.hostconfig if specified.
    ipBlockFilePath: ""
    # (Required) The Virtual Router IDentifier of VRRP for the Seesaw group. Must
    # be between 1-255 and unique in a VLAN.
    vrid: 0
    # (Required) The IP announced by the master of Seesaw group
    masterIP: ""
    # (Required) The number CPUs per machine
    cpus: 4
    # (Required) Memory size in MB per machine
    memoryMB: 3072
    # (Optional) Network that the LB interface of Seesaw runs in (default: cluster
    # network)
    vCenter:
      # vSphere network name
      networkName: ""
    # (Optional) Run two LB VMs to achieve high availability (default: false)
    enableHA: false
# # (Optional) Storage specification for the cluster
# storage:
#   # Whether to disable vSphere CSI components deployment. The feature is enabled by
#   # default.
#   vSphereCSIDisabled: false
# (Optional) User cluster master nodes must have either 1 or 3 replicas (default:
# 4 CPUs; 16384 MB memory; 1 replica)
masterNode:
  cpus: 4
  memoryMB: 8192
  # How many machines of this type to deploy
  replicas: 1
# (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
  # How many machines of this type to deploy
  replicas: 3
  # # (Optional) boot disk size; must be at least 40 (default: 40)
  # bootDiskSizeGB: 40
  # # Labels to apply to Kubernetes Node objects
  # labels: {}
  # # Taints to apply to Kubernetes Node objects
  # taints:
  # - key: ""
  #   value: ""
  #   effect: ""
  # vsphere:
  #   # (Optional) vSphere datastore the node pool will be created on (default: vCenter.datastore)
  #   datastore: ""
# Spread nodes across at least three physical hosts (requires at least three hosts)
antiAffinityGroups:
  # Set to false to disable DRS rule creation
  enabled: true
# # (Optional): Configure additional authentication
# authentication:
#   # (Optional) Configure OIDC authentication
#   oidc:
#     # URL for OIDC Provider.
#     issuerURL: ""
#     # (Optional) Default is http://kubectl.redirect.invalid
#     kubectlRedirectURL: ""
#     # ID for OIDC client application.
#     clientID: ""
#     # (Optional) Secret for OIDC client application.
#     clientSecret: ""
#     username: ""
#     # (Optional) Prefix prepended to username claims.
#     usernamePrefix: ""
#     # (Optional) JWT claim to use as group name.
#     group: ""
#     # (Optional) Prefix prepended to group claims.
#     groupPrefix: ""
#     # (Optional) Additional scopes to send to OIDC provider as comma separated list.
#     # Default is "openid".
#     scopes: ""
#     # (Optional) Additional key-value parameters to send to OIDC provider as comma
#     # separated list.
#     extraParams: ""
#     # (Optional) Set value to string "true" or "false". Default is false.
#     deployCloudConsoleProxy: ""
#     # # (Optional) The absolute or relative path to the CA file
#     # caPath: ""
#   # (Optional) Provide an additional serving certificate for the API server
#   sni:
#     certPath: ""
#     keyPath: ""
#   # (Optional/Preview) Configure LDAP authentication
#   ldap:
#     # Name of LDAP provider.
#     name: ""
#     # Hostname or IP of the LDAP provider.
#     host: ""
#     # (Optional) Only support "insecure" for now
#     connectionType: insecure
#     # # (Optional) The absolute or relative path to the CA file
#     # caPath: ""
#     user:
#       # Location in LDAP directory where user entries exist.
#       baseDN: ""
#       # (Optional) Name of the attribute that precedes the username in a DN. Default
#       # is "CN".
#       userAttribute: ""
#       # (Optional) Name of the attribute that records a user's group membership. Default
#       # is "memberOf".
#       memberAttribute: ""
# (Optional) Specify which GCP project to connect your logs and metrics to
stackdriver:
  projectID: ""
  # A GCP region where you would like to store logs and metrics for this cluster.
  clusterLocation: ""
  enableVPC: false
  # The absolute or relative path to the key file for a GCP service account used to
  # send logs and metrics from the cluster
  serviceAccountKeyPath: ""
  # (Optional/Preview) Disable vsphere resource metrics collection from vcenter.
  # True by default during Preview
  disableVsphereResourceMetrics: false
# (Optional) Specify which GCP project to connect your GKE clusters to
gkeConnect:
  projectID: ""
  # The absolute or relative path to the key file for a GCP service account used to
  # register the cluster
  registerServiceAccountKeyPath: ""
  # The absolute or relative path to the key file for a GCP service account used by
  # the GKE connect agent
  agentServiceAccountKeyPath: ""
# (Optional) Specify Cloud Run configuration
cloudRun:
  enabled: false
# # (Optional/Alpha) Configure the GKE usage metering feature
# usageMetering:
#   bigQueryProjectID: ""
#   # The ID of the BigQuery Dataset in which the usage metering data will be stored
#   bigQueryDatasetID: ""
#   # The absolute or relative path to the key file for a GCP service account used by
#   # gke-usage-metering to report to BigQuery
#   bigQueryServiceAccountKeyPath: ""
#   # Whether or not to enable consumption-based metering
#   enableConsumptionMetering: false
# # (Optional/Alpha) Configure kubernetes apiserver audit logging
# cloudAuditLogging:
#   projectid: ""
#   # A GCP region where you would like to store audit logs for this cluster.
#   clusterlocation: ""
#   # The absolute or relative path to the key file for a GCP service account used to
#   # send audit logs from the cluster
#   serviceaccountkeypath: ""
# # (Optional/Preview) Enable auto repair for the cluster
# autoRepair:
#   # Whether to enable auto repair feature. The feature is disabled by default.
#   enabled: false

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.