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

Vous pouvez redimensionner un cluster d'utilisateur en modifiant les champs replicas de la configuration MachineDeployment du cluster. Vous pouvez corriger la configuration depuis la ligne de commande en utilisant kubectl patch.

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

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.

Adresses IP statiques

Si le cluster utilise des adresses IP statiques, vérifiez que vous avez alloué suffisamment d'adresses IP au cluster :

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.

Dans le résultat de la commande, recherchez le champ reservedAddresses. Il doit y avoir plus d'adresses IP dans le champ que de nœuds en cours d'exécution dans le cluster d'utilisateur.

Si vous devez ajouter d'autres adresses au champ reservedAddresses, procédez comme suit :

  1. Ouvrez la ressource Cluster du cluster d'utilisateur pour la modifier :

    kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \
-n [USER_CLUSTER_NAME]

    La configuration du cluster s'ouvre dans l'éditeur par défaut de votre interface système.

  2. Ajoutez autant de blocs d'adresses IP statiques supplémentaires que nécessaire. Un bloc d'adresses IP comporte les champs gateway, hostname, ip et netmask.

Voici un exemple de champ reservedAddresses avec ses quatre blocs d'adresses IP statiques mis en surbrillance :

...
networkSpec:
  dns:
  - 172.x.x.x
  ntp: 129.x.x.x
  reservedAddresses:
  - gateway: 100.x.x.x
    hostname: host-1
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-2
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-3
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-4
    ip: 100.x.x.x
    netmask: x
...

Avant de commencer

Exportez une variable d'environnement KUBECONFIG pointant vers le fichier kubeconfig du cluster d'utilisateur que vous souhaitez redimensionner :

export KUBECONFIG=[USER_CLUSTER_KUBECONFIG]

Redimensionner un cluster d'utilisateur

Pour redimensionner un cluster, modifiez la ressource MachineDeployment du cluster d'utilisateur. Pour trouver le nom de la ressource MachineDeployment du cluster d'utilisateur, exécutez la commande suivante :

kubectl get machinedeployments

La ressource MachineDeployment du cluster d'utilisateur inclut le nom du cluster d'utilisateur.

Pour redimensionner le cluster d'utilisateur, vous devez appliquer un correctif à la configuration MachineDeployment du cluster. Vous modifiez la valeur du champ replicas de la configuration, qui indique le nombre de nœuds que le cluster doit exécuter :

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p "{\"spec\": {\"replicas\": [INT] }}" --type=merge

où [INT] correspond au nombre de nœuds à exécuter par le cluster d'utilisateur.

Vérifier le redimensionnement

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

kubectl get nodes
kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME] | grep Replicas

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 Dépannage.

Échec du redimensionnement d'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.

Nouveaux nœuds créés, mais non opérationnels

Symptômes

Les nouveaux nœuds ne s'enregistrent pas eux-mêmes dans le plan de contrôle du cluster d'utilisateur lors de l'utilisation du mode d'équilibrage de charge manuel.

Causes possibles :

La validation Ingress dans les nœuds est peut-être activée, ce qui bloque le processus de démarrage des nœuds.

Solution

Pour désactiver la validation, exécutez la commande suivante :

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

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