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 :
Ouvrez le fichier hostconfig du cluster d'utilisateur pour le modifier.
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.
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
etgateway
.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 :
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]
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 fichierlogs/gkectl-$(date).log
dans le répertoire local où vous exécutezgkectl
. -
Pour
gkeadm
, le fichier journal par défaut estlogs/gkeadm-$(date).log
dans le répertoire local où vous exécutezgkeadm
.
-
Pour
- 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 valeurfalse
). - 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 :
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
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écutezgkectl 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
kubectl get --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] onpremusercluster
cluster [CLUSTER_NAME] is READY=true