Cette page explique comment mettre à niveau Anthos clusters on VMware (GKE On-Prem).
Versions cibles
À partir de la version 1.3.2 d'Anthos clusters on VMware, vous pouvez effectuer une mise à niveau directement vers toute version de la même version mineure ou vers la prochaine version mineure. Par exemple, vous pouvez passer de la version 1.3.2 à la version 1.3.5, ou de la version 1.5.2 à la version 1.6.1.
Si la version actuelle est antérieure à la version 1.3.2, vous devez d'abord effectuer des mises à niveau séquentielles pour atteindre la version 1.3.2. Par exemple, pour passer de la version 1.3.0 à la version 1.3.2, vous devez d'abord passer de la version 1.3.0 à la version 1.3.1, puis de la version 1.3.1 à la version 1.3.2.
Si vous passez de la version 1.3.2 ou ultérieure à une version qui ne fait pas partie de la prochaine version mineure, vous devez effectuer une mise à niveau via une version de chaque version mineure entre votre version actuelle et la version souhaitée. Par exemple, il n'est pas possible de procéder à une mise à niveau directe pour passer de la version 1.3.2 à la version 1.6.1. Vous devez d'abord mettre à niveau la version 1.3.2 vers la version 1.4.x, où x représente une version de correctif antérieure à cette version mineure. Vous pouvez ensuite passer à la version 1.5.x, et enfin à la version 1.6.1.
Présentation du processus de mise à niveau
Téléchargez l'outil
gkeadm. La version degkeadmdoit être identique à la version cible de la mise à niveau.Mettez à niveau votre poste de travail administrateur à l'aide de
gkeadm.Mettez à niveau votre cluster d'administrateur à partir de votre poste de travail administrateur.
Mettez à niveau vos clusters d'utilisateurs depuis votre poste de travail administrateur.
Règles de mise à niveau
Après avoir mis à niveau votre cluster d'administrateur :
Tous les clusters d'utilisateur que vous créez doivent disposer de la même version que votre cluster d'administrateur.
Si vous mettez à niveau un cluster d'utilisateur existant, vous devez passer à la même version que votre cluster d'administrateur.
Avant de mettre à niveau votre cluster d'administrateur, vous devez mettre à niveau tous vos clusters d'utilisateur vers la même version que votre cluster d'administrateur actuel.
Localiser les fichiers de configuration et d'informations
Lorsque vous avez créé votre poste de travail administrateur actuel, vous avez rempli un fichier de configuration généré par gkeadm create config pour ce poste de travail.
Le nom par défaut de ce fichier est admin-ws-config.yaml.
Lorsque vous avez créé votre poste de travail administrateur actuel, gkeadm a créé automatiquement un fichier d'informations. Le nom par défaut de ce fichier est identique à celui de votre poste de travail administrateur actuel.
Localisez le fichier de configuration de votre poste de travail administrateur et le fichier d'informations. Vous en aurez besoin pour suivre la procédure décrite dans ce guide. Si ces fichiers se trouvent dans votre répertoire actuel et qu'ils possèdent un nom par défaut, vous n'aurez pas besoin de les spécifier lors de l'exécution de gkeadm upgrade admin-workstation. Si ces fichiers se trouvent dans un autre répertoire ou si vous avez modifié les noms de fichiers, spécifiez-les à l'aide des options --config et --info-file.
Mettre à niveau le poste de travail administrateur
Pour mettre à niveau votre poste de travail administrateur, commencez par télécharger une nouvelle version de l'outil gkeadm, puis utilisez-la pour mettre à niveau la configuration de votre poste de travail administrateur.
La version de gkeadm doit correspondre à la version cible de votre mise à niveau.
Télécharger gkeadm
Pour télécharger la version appropriée de gkeadm, suivez les instructions de la page Téléchargements.
Mettre à niveau le poste de travail administrateur
gkeadm upgrade admin-workstation --config [AW_CONFIG_FILE] --info-file [INFO_FILE]
où :
[AW_CONFIG_FILE] est le chemin d'accès au fichier de configuration de votre poste de travail administrateur. Vous pouvez omettre cette option si le fichier se trouve dans votre répertoire actuel sous le nom
admin-ws-config.yaml.[INFO_FILE] est le chemin d'accès au fichier d'informations. Vous pouvez omettre cette option si le fichier se trouve dans votre répertoire actuel. Le nom par défaut de ce fichier est identique à celui de votre poste de travail administrateur actuel.
La commande précédente exécute les tâches suivantes :
Elle sauvegarde tous les fichiers du répertoire d'accueil de votre poste de travail administrateur actuel. y compris :
Votre fichier de configuration Anthos clusters on VMware. Le nom par défaut de ce fichier est
config.yaml.Les fichiers kubeconfig du cluster d'administrateur et des clusters d'utilisateur.
le certificat racine du serveur vCenter. Notez que ce fichier doit disposer des autorisations de propriétaire en lecture et en écriture ;
Le fichier de clé JSON pour votre compte de service d'accès au composant. Notez que ce fichier doit disposer des autorisations de propriétaire en lecture et en écriture ;
les fichiers de clé JSON des comptes de service connect-register, connect-agent et logging-monitoring.
Elle crée un poste de travail administrateur et copie tous les fichiers sauvegardés sur le nouveau poste de travail administrateur.
Elle supprime l'ancien poste de travail administrateur.
Mettre à jour l'image d'OS et les images Docker du nœud
Sur votre nouveau poste de travail administrateur, exécutez la commande suivante :
gkectl prepare --config [ADMIN_CONFIG] [FLAGS]
où :
[ADMIN_CONFIG] est le chemin d'accès au fichier de configuration du cluster d'administrateur.
[FLAGS] est un ensemble facultatif d'options. Par exemple, vous pouvez inclure l'option
--skip-validation-infrapour ignorer la vérification de votre infrastructure vSphere.
La commande précédente exécute les tâches suivantes :
Si nécessaire, copiez une nouvelle image d'OS de nœud dans votre environnement vSphere et marquez-la comme modèle.
Si vous avez configuré un registre Docker privé, elle transfère les images Docker mises à jour à ce registre.
Vérifier que suffisamment d'adresses IP sont disponibles
Suivez les étapes décrites dans cette section sur votre nouveau poste de travail administrateur.
Avant de procéder à la mise à niveau, assurez-vous que vous disposez de suffisamment d'adresses IP pour vos clusters.
DHCP
Lorsque vous mettez à niveau le cluster administrateur, Anthos Clusters on VMware crée un nœud temporaire dans le cluster administrateur. Lorsque vous mettez à niveau un cluster d'utilisateur, Anthos Clusters on VMware crée un nœud temporaire dans ce cluster d'utilisateur. Le nœud temporaire a pour but de garantir une disponibilité ininterrompue. Avant de mettre à niveau un cluster, assurez-vous que votre serveur DHCP peut fournir suffisamment d'adresses IP pour le nœud temporaire. Pour en savoir plus, consultez la section Adresses IP requises pour les clusters d'administrateur et d'utilisateur.
IP statiques
Lorsque vous mettez à niveau le cluster administrateur, Anthos Clusters on VMware crée un nœud temporaire dans le cluster administrateur. Lorsque vous mettez à niveau un cluster d'utilisateur, Anthos Clusters on VMware crée un nœud temporaire dans ce cluster d'utilisateur. Le nœud temporaire a pour but de garantir une disponibilité ininterrompue. Avant de mettre à jour un cluster, vérifiez que vous avez réservé suffisamment d'adresses IP. Pour chaque cluster, vous devez réserver au moins une adresse IP supplémentaire par rapport au nombre de nœuds du cluster. Pour en savoir plus, consultez la section Configurer des adresses IP statiques.
Déterminez le nombre de nœuds dans votre cluster d'administrateur :
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes
où [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.
Ensuite, affichez les adresses réservées pour votre cluster d'administrateur :
kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml
Dans le résultat, dans le champ reservedAddresses, vous pouvez voir le nombre d'adresses IP réservées pour les nœuds du cluster d'administrateur. Par exemple, le résultat suivant indique que cinq adresses IP sont réservées aux nœuds du cluster d'administrateur :
...
reservedAddresses:
- gateway: 21.0.135.254
hostname: admin-node-1
ip: 21.0.133.41
netmask: 21
- gateway: 21.0.135.254
hostname: admin-node-2
ip: 21.0.133.50
netmask: 21
- gateway: 21.0.135.254
hostname: admin-node-3
ip: 21.0.133.56
netmask: 21
- gateway: 21.0.135.254
hostname: admin-node-4
ip: 21.0.133.47
netmask: 21
- gateway: 21.0.135.254
hostname: admin-node-5
ip: 21.0.133.44
netmask: 21
Le nombre d'adresses IP réservées doit être supérieur (au minimum +1) au nombre de nœuds du cluster d'administrateur. Si ce n'est pas le cas, vous pouvez réserver une adresse supplémentaire en modifiant l'objet Cluster.
Ouvrez l'objet Cluster pour le modifier :
kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]
Sous reservedAddresses, ajoutez un bloc supplémentaire comportant gateway, hostname, ip et netmask.
Pour déterminer le nombre de nœuds dans un cluster d'utilisateur :
kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes
où [USER_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster d'utilisateur.
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] est le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.
[USER_CLUSTER_NAME] est le nom du cluster d'utilisateur.
Le nombre d'adresses IP réservées doit être supérieur (au minimum +1) au nombre de nœuds du cluster d'utilisateur. Si ce n'est pas le cas, procédez comme suit :
Ouvrez le fichier de bloc d'adresses IP du cluster d'utilisateur à modifier.
Ajoutez des adresses IP supplémentaires au bloc, puis fermez le fichier.
Mettez à jour le cluster d'utilisateur :
gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONIFG] \ --config [USER_CLUSTER_CONFIG]
(Facultatif) Désactiver les nouvelles fonctionnalités vSphere
Une nouvelle version d'Anthos clusters on VMware peut inclure de nouvelles fonctionnalités ou la compatibilité avec des fonctionnalités spécifiques de VMware vSphere. Parfois, la mise à niveau vers une version d'Anthos clusters on VMware active automatiquement ces fonctionnalités. Pour en savoir plus sur les nouvelles fonctionnalités, consultez les notes de version d'Anthos clusters on VMware. De nouvelles fonctionnalités sont parfois introduites dans le fichier de configuration Anthos clusters on VMware.
Si vous devez désactiver une nouvelle fonctionnalité qui a été automatiquement activée dans une nouvelle version de Anthos clusters on VMware et qui est pilotée par le fichier de configuration, effectuez la procédure ci-après avant de mettre à niveau votre cluster :
Depuis votre poste de travail administrateur mis à niveau, créez un fichier de configuration ayant un nom différent de celui de votre fichier de configuration actuel :
gkectl create-config --config [CONFIG_NAME]
Ouvrez le nouveau fichier de configuration et notez le champ de la fonctionnalité. Fermez le fichier.
Ouvrez le fichier de configuration actuel et ajoutez le champ de la nouvelle fonctionnalité. Définissez la valeur du champ sur
falseou une valeur équivalente.Enregistrez le fichier de configuration.
Consultez les notes de version avant de mettre à niveau vos clusters. Vous ne pouvez pas modifier de manière déclarative la configuration d'un cluster existant après sa mise à niveau.
Mettre à niveau votre cluster d'administrateur
Suivez les étapes décrites dans cette section sur votre nouveau poste de travail administrateur.
Rappelez-vous que la version cible de la mise à niveau doit être identique à la version gkeadm.
Exécutez la commande suivante :
gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [ADMIN_CLUSTER_CONFIG_FILE] \
[FLAGS]
où :
[ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.
[ADMIN_CLUSTER_CONFIG_FILE] est le chemin d'accès au fichier de configuration de votre cluster d'administrateur.
[FLAGS] est un ensemble facultatif d'options. Par exemple, vous pouvez inclure l'option
--skip-validation-infrapour ignorer la vérification de votre infrastructure vSphere.
Mettre à niveau un cluster d'utilisateur
Suivez les étapes décrites dans cette section sur votre nouveau poste de travail administrateur.
Rappelez-vous que la version cible de la mise à niveau doit être identique à la version gkeadm.
gkectl
gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [USER_CLUSTER_CONFIG_FILE] \
[FLAGS]
où :
[ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès au fichier kubeconfig du cluster d'administrateur.
[USER_CLUSTER_CONFIG_FILE] est le chemin d'accès au fichier de configuration du cluster d'utilisateur.
[FLAGS] est un ensemble facultatif d'options. Par exemple, vous pouvez inclure l'option
--skip-validation-infrapour ignorer la vérification de votre infrastructure vSphere.
Console
Vous pouvez choisir d'enregistrer vos clusters d'utilisateur avec lq console Google Cloud lors de l'installation ou après les avoir créés. Dans la console Google Cloud, vous pouvez afficher vos clusters Anthos enregistrés et vos clusters GKE, et vous y connecter.
Lorsqu'une mise à niveau devient disponible pour un cluster d'utilisateur, une notification s'affiche dans la console Google Cloud. Cliquer sur cette notification permet d'afficher la liste des versions disponibles et une commande gkectl que vous pouvez exécuter pour mettre à niveau le cluster :
Accédez à la page "Google Kubernetes Engine" dans la console Google Cloud.
Dans la colonne Notifications du cluster d'utilisateur, cliquez sur Mise à niveau disponible, si cette option est disponible.
Copiez la commande
gkectl upgrade cluster.Sur votre poste de travail administrateur, exécutez la commande
gkectl upgrade cluster, où [ADMIN_CLUSTER_KUBECONFIG] est le chemin d'accès du fichier kubeconfig du cluster d'administrateur, [CLUSTER_NAME] est le nom du cluster d'utilisateur que vous mettez à niveau et [USER_CLUSTER_CONFIG_FILE] est le chemin d'accès du fichier de configuration de cluster d'utilisateur.
Reprendre une mise à niveau
Si une mise à niveau du cluster d'utilisateur est interrompue, vous pouvez reprendre la mise à niveau en exécutant la même commande de mise à niveau avec l'option --skip-validation-all :
gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [USER_CLUSTER_CONFIG_FILE] \
--cluster-name [CLUSTER_NAME] \
--skip-validation-all
Reprendre une mise à niveau d'un cluster d'administrateur
Vous ne devez pas interrompre une mise à niveau du cluster d'administrateur. Il n'est pas toujours possible de reprendre les mises à niveau du cluster d'administrateur. Si une mise à niveau du cluster d'administrateur est interrompue pour quelque raison que ce soit, contactez l'assistance pour obtenir de l'aide.
Créer un cluster d'utilisateur après une mise à niveau
Après avoir mis à niveau votre poste de travail et votre cluster d'administrateur, tous les clusters d'utilisateur que vous créez doivent disposer de la même version que la version cible de la mise à niveau.
Règles VMware DRS
Anthos clusters on VMware crée automatiquement des règles anti-affinités VMware Distributed Resource Scheduler (DRS) pour les nœuds de votre cluster d'utilisateur. Ceux-ci sont ainsi répartis sur au moins trois hôtes physiques dans votre centre de données. Cette fonctionnalité est automatiquement activée pour les nouveaux clusters et les clusters existants.
Avant de procéder à la mise à niveau, assurez-vous que votre environnement vSphere remplit les conditions suivantes :
- La fonctionnalité VMware DRS est activée. VMware DRS nécessite l'édition de licence vSphere Enterprise Plus. Pour en savoir plus sur l'activation de DRS, consultez la page Enabling VMware DRS in a cluster (Activer VMware DRS dans un cluster).
- Le compte utilisateur vSphere fourni dans le champ
vcenterdispose de l'autorisationHost.Inventory.EditCluster. - Au moins trois hôtes physiques sont disponibles.
Si votre environnement vSphere ne remplit pas les conditions précédentes, vous pouvez toujours mettre à niveau un cluster d'utilisateur de la version 1.3.x à la version 1.4.x, mais vous devez désactiver les groupes d'anti-affinité. Pour en savoir plus, consultez les notes de version pour la version 1.4.0.
Temps d'arrêt
À propos des temps d'arrêt pendant les mises à jour
| Ressource | Description |
|---|---|
| Cluster d'administrateur | En cas de panne d'un cluster d'administrateur, les plans de contrôle et les charges de travail des clusters d'utilisateur continuent de s'exécuter, sauf s'ils sont affectés par une panne ayant provoqué le temps d'arrêt. |
| Plan de contrôle du cluster d'utilisateur | En règle générale, les plans de contrôle des clusters d'utilisateur ne font pas l'objet de temps d'arrêt significatifs. Cependant, les connexions de longue durée au serveur d'API Kubernetes peuvent être interrompues et doivent être rétablies. Dans ce cas, l'appelant de l'API doit effectuer de nouvelles tentatives jusqu'à ce qu'il établisse une connexion. Dans le pire des cas, le temps d'arrêt peut durer jusqu'à une minute pendant une mise à niveau. |
| Nœuds de cluster d'utilisateur | Si une mise à niveau nécessite une modification des nœuds du cluster d'utilisateur, Anthos clusters on VMware recrée les nœuds de manière progressive et replanifie les pods exécutés sur ces nœuds. Vous pouvez éviter l'impact sur vos charges de travail en configurant des règles PodDisruptionBudgets et d'anti-affinité appropriées. |
Problèmes connus
Consultez la page Problèmes connus.
Dépannage
Consultez la page Résoudre les problèmes liés à la création et à la mise à niveau d'un cluster.