Redimensionner un cluster d'utilisateur

Cette page explique comment redimensionner un cluster d'utilisateur GKE On-Prem. Le redimensionnement d'un cluster d'utilisateur implique l'ajout ou la suppression de nœuds dans ce cluster. La suppression de nœuds d'un cluster doit libérer les adresses IP de ce cluster et les rendre disponibles pour d'autres nœuds. L'ajout de nœuds nécessite que des adresses IP soient disponibles pour ces nœuds.

Pour redimensionner un cluster d'utilisateur, modifiez les champs replicas dans la section nodePools de votre fichier de configuration, puis déployez ces modifications sur votre cluster existant à l'aide de la commande gkectl update cluster.

Pour en savoir plus sur les limites maximales et minimales des clusters d'utilisateur, consultez la page Quotas et limites.

Pour en savoir plus sur la gestion des pools de nœuds avec gkectl update cluster, consultez la page Créer et gérer des pools de nœuds.

Vérifier que suffisamment d'adresses IP sont disponibles

Si vous ajoutez des nœuds supplémentaires à un cluster, assurez-vous que celui-ci possède suffisamment d'adresses IP. La vérification du nombre d'adresses IP dépend du fait que le cluster utilise un serveur DHCP ou des adresses IP statiques.

DHCP

Si le cluster utilise le protocole DHCP, vérifiez que le serveur DHCP du réseau dans lequel les nœuds sont créés possède suffisamment d'adresses IP. Il doit y avoir plus d'adresses IP que de nœuds s'exécutant dans le cluster d'utilisateur.

IP statiques

Si le cluster utilise des adresses IP statiques, l'exécution de gkectl update cluster vérifie d'abord si vous avez alloué suffisamment d'adresses IP au cluster. Si ce n'est pas le cas, vous pouvez trouver le nombre d'adresses IP supplémentaires nécessaires à l'opération de mise à jour dans le message d'erreur.

Si vous devez ajouter d'autres adresses IP au cluster d'utilisateur, procédez comme suit :

  1. Ouvrez le fichier hostconfig du cluster d'utilisateur pour le modifier.

  2. Pour afficher les adresses réservées pour un cluster d'utilisateur : 

    kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] 
    
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

où :

  • [ADMIN_CLUSTER_KUBECONFIG] indique à kubectl d'utiliser le fichier kubeconfig du cluster d'administrateur, qui permet d'afficher et/ou de modifier les configurations de cluster d'utilisateur.
  • -n [USER_CLUSTER_NAME] indique à kubectl d'examiner un espace de noms portant le même nom que le cluster d'utilisateur.
  • [USER_CLUSTER_NAME] -o yaml indique à kubectl le cluster d'utilisateur sur lequel vous exécutez la commande. -o yaml affiche la configuration du cluster d'utilisateur.

  1. Si des adresses réservées à un cluster d'utilisateur sont incluses dans le fichier hostconfig, ajoutez-les au bloc correspondant en fonction de netmask et gateway.

  2. Ajoutez au bloc correspondant autant d'adresses IP statiques supplémentaires que nécessaire, puis exécutez la commande gkectl update cluster.

Vous trouverez ci-dessous un exemple de fichier hostconfig avec ses quatre blocs d'adresses IP statiques en surbrillance :

hostconfig:
  dns: 172.16.255.1
  tod: 216.239.35.0
blocks:
- netmask: 255.255.248.0
  gateway: 21.0.135.254
  ips:
    - ip: 21.0.133.41
      hostname: user-node-1
    - ip: 21.0.133.50
      hostname: user-node-2
    - ip: 21.0.133.56
      hostname: user-node-3
    - ip: 21.0.133.47
      hostname: user-node-4

Redimensionner un cluster d'utilisateur

À partir de la version 1.5.0, pour redimensionner un cluster, modifiez les champs replicas dans la section nodePools de votre fichier de configuration, puis déployez ces modifications sur votre cluster existant à l'aide de la commande gkectl update cluster.

Vérifier le redimensionnement

Pour vérifier que le redimensionnement a bien été effectué, exécutez la commande suivante :

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] describe machinedeployments [NODE_POOL_NAME] | grep Replicas

où [USER_CLUSTER_KUBECONFIG] est le fichier kubeconfig de votre cluster d'utilisateur. Le nombre de nœuds que vous avez choisi doit s'afficher dans le résultat de ces commandes.

Dépannage

Pour en savoir plus, consultez la section Dépannage.

Impossible de redimensionner un cluster d'utilisateur

Symptômes

Échec d'une opération de redimensionnement sur un cluster d'utilisateur.

Causes probables

Plusieurs facteurs peuvent entraîner l'échec des opérations de redimensionnement.

Solution

Si un redimensionnement échoue, procédez comme suit :

  1. Examinez l'état MachineDeployment du cluster pour vérifier s'il y a des événements ou des messages d'erreur :

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]

  2. Déterminez s'il existe des erreurs sur les machines nouvellement créées :

    kubectl describe machine [MACHINE_NAME]

Erreur : "aucune adresse ne peut être allouée"

Symptômes

Après avoir redimensionné un cluster d'utilisateur, kubectl describe machine [MACHINE_NAME] affiche l'erreur suivante :

Events:
   Type     Reason  Age                From                    Message
   ----     ------  ----               ----                    -------
   Warning  Failed  9s (x13 over 56s)  machineipam-controller  ipam: no addresses can be allocated
Causes probables

Il n'y a pas suffisamment d'adresses IP disponibles pour le cluster d'utilisateur.

Solution

Attribuez des adresses IP supplémentaires au cluster. Supprimez ensuite la machine concernée :

kubectl delete machine [MACHINE_NAME]

Si le cluster est correctement configuré, une machine de remplacement est créée avec une adresse IP.

Un nombre suffisant d'adresses IP est alloué, mais la machine ne parvient pas à s'enregistrer auprès du cluster.

Symptômes

Le réseau dispose de suffisamment d'adresses allouées, mais la machine ne parvient toujours pas à s'enregistrer auprès du cluster d'utilisateur.

Causes possibles :

Il y a peut-être un conflit d'adresses IP. L'adresse IP peut être utilisée par une autre machine ou par votre équilibreur de charge.

Solution

Vérifiez que l'adresse IP de la machine concernée est disponible. En cas de conflit, vous devez le résoudre dans votre environnement.

Diagnostiquer des problèmes de cluster à l'aide de gkectl

Utilisez les commandes gkectl diagnose pour identifier les problèmes de cluster et partager des informations de cluster avec Google. Consultez la page Diagnostiquer les problèmes de cluster.

Comportement de journalisation par défaut

Pour gkectl et gkeadm, l'utilisation des paramètres de journalisation par défaut est suffisante :

  • Par défaut, les entrées de journal sont enregistrées comme suit :

    • Pour gkectl, le fichier journal par défaut est /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log, et le fichier est lié symboliquement au fichier logs/gkectl-$(date).log dans le répertoire local où vous exécutez gkectl.
    • Pour gkeadm, le fichier journal par défaut est logs/gkeadm-$(date).log dans le répertoire local où vous exécutez gkeadm.
  • Toutes les entrées de journal sont enregistrées dans le fichier journal, même si elles ne sont pas affichées sur le terminal (lorsque --alsologtostderr a la valeur false).
  • Le niveau de verbosité -v5 (par défaut) couvre toutes les entrées de journal requises par l'équipe d'assistance.
  • Le fichier journal contient également la commande exécutée et le message d'échec.

Nous vous recommandons d'envoyer le fichier journal à l'équipe d'assistance lorsque vous avez besoin d'aide.

Spécifier un emplacement autre que celui par défaut pour le fichier journal

Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkectl, utilisez l'option --log_file. Le fichier journal que vous spécifiez ne sera pas lié symboliquement au répertoire local.

Pour spécifier un emplacement autre que celui par défaut pour le fichier journal gkeadm, utilisez l'option --log_file.

Localiser des journaux de l'API Cluster dans le cluster d'administrateur

Si une VM ne démarre pas après le démarrage du plan de contrôle d'administrateur, vous pouvez essayer de la déboguer en inspectant les journaux des contrôleurs de l'API Cluster dans le cluster d'administrateur :

  1. Recherchez le nom du pod des contrôleurs d'API Cluster dans l'espace de noms kube-system, où [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig du cluster d'administrateur :

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers

  2. Ouvrez les journaux du pod, où [POD_NAME] correspond au nom du pod. Vous pouvez éventuellement utiliser grep ou un outil similaire pour rechercher les erreurs :

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager

Échec de la commande Update

Lorsque vous exécutez gkectl update pour mettre à jour un cluster, le message d'erreur suivant peut s'afficher :
Failed to update the cluster: failed to begin updating user cluster "CLUSTER_NAME": timed out waiting for the condition
Pour examiner plus en détail ce message d'erreur, exécutez la commande suivante :
kubectl get --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] onpremusercluster
Si vous obtenez le résultat suivant et que la mise à jour a pris effet, le message d'erreur peut être ignoré :
cluster [CLUSTER_NAME] is READY=true