Vous consultez la documentation d'une version précédente de GKE On-Prem. Consultez la documentation la plus récente.

Redimensionner un cluster d'utilisateur

Cette page explique comment redimensionner un cluster d'utilisateurs Anthos 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 à partir de la ligne de commande en utilisant kubectl patch.

Pour en savoir plus sur les limites maximales et minimales pour les 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.

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 utilisateur.
  • -n [USER_CLUSTER_NAME] indique à kubectl d'examiner un espace de noms nommé d'après 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

Vous redimensionnez un cluster en modifiant 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

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

Vérifier le redimensionnement

Pour vérifier que le redimensionnement a réussi, 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 apparaître dans le résultat de ces commandes.

Dépannage

Pour en savoir plus, consultez la page 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. Vérifiez l'état MachineDeployment du cluster pour voir s'il y a des événements ou des messages d'erreur :

    kubectl describe machinedeployments [MACHINE_DEPLOYMENT_NAME]
  2. Vérifiez 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 prise 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 sains

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 section Diagnostiquer des problèmes de cluster.

Exécuter des commandes gkectl de manière détaillée

-v5

Consigner des erreurs gkectl dans stderr

--alsologtostderr

Localiser les journaux gkectl sur le poste de travail d'administrateur

Même si vous ne transmettez pas ses indicateurs de débogage, vous pouvez afficher les journaux gkectl dans le répertoire suivant du poste de travail d'administrateur :

/home/ubuntu/.config/syllogi/logs

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