Lorsque vous mettez à niveau GKE sur des clusters Bare Metal, le processus de mise à niveau implique plusieurs étapes et composants. Pour vous aider à surveiller l'état de la mise à niveau, ou à diagnostiquer et résoudre des problèmes, il est utile de savoir ce qui se passe lorsque vous exécutez la commande bmctl upgrade cluster. Ce document détaille les composants et les étapes d'une mise à niveau d'un cluster.
Présentation
Le processus de mise à niveau déplace votre cluster GKE sur Bare Metal de sa version actuelle vers une version supérieure.
Ces informations de version sont stockées aux emplacements suivants dans le cadre de la ressource personnalisée de cluster du cluster d'administrateur:
status.anthosBareMetalVersion: définit la version actuelle du cluster.spec.anthosBareMetalVersion: définit la version cible et est défini lorsque le processus de mise à niveau commence à s'exécuter.
Une opération de mise à niveau réussie rapproche la version cible spec.anthosBareMetalVersion de status.anthosBareMetalVersion.
Décalage entre les versions
Le décalage de version correspond à la différence de version entre un cluster d'administrateur et ses clusters d'utilisateur gérés. Les clusters GKE sur Bare Metal suivent le même style que Kubernetes: le cluster d'administrateur peut avoir une version mineure au maximum avant ses clusters gérés.
Règles de version pour les mises à niveau
Lorsque vous téléchargez et installez une nouvelle version de bmctl, vous pouvez mettre à jour vos clusters d'administrateur, vos clusters hybrides, vos clusters autonomes et vos clusters d'utilisateur créés ou mis à jour avec une version antérieure de bmctl. Les clusters ne peuvent pas revenir à une version antérieure.
Vous ne pouvez mettre à jour un cluster que vers une version qui correspond à la version de bmctl que vous utilisez. Autrement dit, si vous utilisez la version 1.15.11 de bmctl, vous ne pouvez mettre à niveau un cluster que vers la version 1.15.11.
Mises à niveau de versions de correctif
Pour une version mineure donnée, vous pouvez passer à n'importe quelle version de correctif supérieure. Autrement dit, vous pouvez mettre à jour un cluster de version 1.15.X vers la version 1.15.Y tant que Y est supérieur à X. Par exemple, vous pouvez passer de la version 1.14.0 à la version 1.14.1 et de la version 1.14.1 à la version 1.14.3. Nous vous recommandons, autant que possible, de procéder à la mise à niveau vers la dernière version du correctif, afin de vous assurer que vos clusters disposent des derniers correctifs de sécurité.
Mises à niveau de versions mineures
Vous pouvez mettre à jour les clusters d'une version mineure à la suivante, quelle que soit la version de correctif. Autrement dit, vous pouvez passer de la version 1.N.X à la version 1.N+1.Y, où 1.N.X est la version de votre cluster et N+1 est la prochaine version mineure disponible. Dans ce cas, les versions de correctif, X et Y, n'ont pas d'incidence sur la logique de mise à niveau. Par exemple, vous pouvez passer de la version 1.14.3 à la version 1.15.11.
Vous ne pouvez pas ignorer les versions mineures lors de la mise à niveau des clusters. Si vous essayez de passer à une version mineure qui est supérieure d'au moins deux versions mineures à la version du cluster, bmctl renvoie une erreur. Par exemple, vous ne pouvez pas mettre à jour un cluster de version 1.13.0 vers la version 1.15.0.
Un cluster d'administrateur peut gérer des clusters d'utilisateur qui correspondent à la même version mineure, ou à une version mineure précédente. La version d'un cluster d'utilisateur géré ne peut pas être inférieure de plus d'une version mineure à celle du cluster d'administrateur. Avant de mettre à jour un cluster d'administrateur vers une nouvelle version mineure, assurez-vous donc que tous les clusters d'utilisateur gérés correspondent à la même version mineure que le cluster d'administrateur.
Les exemples des instructions de mise à niveau suivantes illustrent le processus de mise à niveau de la version 1.14.2 vers la version 1.15.11 de GKE sur Bare Metal.
Mettre à niveau les composants
Les composants sont mis à niveau au niveau du nœud et du cluster. Au niveau du cluster, les composants suivants sont mis à niveau:
- Composants de cluster pour la mise en réseau, l'observabilité et le stockage
- Pour les clusters d'administrateur, hybrides et autonomes, les contrôleurs de cycle de vie
gke-connect-agent
Les nœuds d'un cluster s'exécutent avec l'un des rôles suivants. Différents composants sont mis à niveau en fonction du rôle du nœud:
| Rôle du nœud | Fonction | Composants à mettre à niveau |
|---|---|---|
| Nœud de calcul | Exécute des charges de travail de l'utilisateur | Kubelet, environnement d'exécution du conteneur (Docker ou containerd) |
| Plan de contrôle | Exécute le plan de contrôle Kubernetes, les contrôleurs de cycle de vie du cluster et les modules complémentaires de la plate-forme Google Kubernetes Engine (GKE) Enterprise. | Pods statiques du plan de contrôle Kubernetes (kubeapi-server, kube-scheduler, kube-controller-manager, etcd)
Contrôleurs de cycle de vie comme lifecycle-controllers-manager et anthos-cluster-operatorModules complémentaires de la plate-forme Google Kubernetes Engine (GKE) de l'édition Enterprise, tels que stackdriver-log-aggregator et gke-connect-agent |
| Équilibreur de charge du plan de contrôle | Exécute HAProxy et Keepalive, qui diffusent le trafic vers kube-apiserver, et exécute des haut-parleurs MetalLB pour revendiquer des adresses IP virtuelles |
Pods statiques de l'équilibreur de charge du plan de contrôle (HAProxy, KeepaLive) Haut-parleurs MetalLB |
Attente du temps de pause
Le tableau suivant détaille les temps d'arrêt prévus et l'impact potentiel de la mise à niveau des clusters. Dans ce tableau, nous partons du principe que vous disposez de plusieurs nœuds de cluster et d'un plan de contrôle haute disponibilité. Si vous exécutez un cluster autonome ou que vous ne disposez pas d'un plan de contrôle haute disponibilité, attendez-vous à des temps d'arrêt supplémentaires. Sauf indication contraire, ce temps d'arrêt s'applique aux mises à niveau des clusters d'administrateur et d'utilisateur:
| Composants | Attentes en matière de temps de pause | En cas de temps d'arrêt |
|---|---|---|
Serveur d'API du plan de contrôle Kubernetes (kube-apiserver), etcd et programmeur |
Aucun temps d'arrêt | Non disponible |
Contrôleurs de cycle de vie et tâche ansible-runner (cluster d'administrateur uniquement) |
Aucun temps d'arrêt | Non disponible |
Plan de contrôle Kubernetes loadbalancer-haproxy et keepalived |
Temps d'arrêt temporaire (moins de 1 à 2 minutes) lorsque l'équilibreur de charge redirige le trafic. | Début du processus de mise à niveau. |
Observabilité pipeline-stackdriver et metrics-server |
Opérateur drainé et mis à niveau. Le temps de pause doit être inférieur à cinq minutes.
Les DaemonSets continuent de fonctionner sans temps d'arrêt. |
Une fois la mise à niveau des nœuds du plan de contrôle terminée. |
| Container Network Interface (CNI, interface réseau pour conteneurs) | Aucun temps d'arrêt pour les routes réseau existantes. DaemonSet déployé deux par deux sans temps d'arrêt. L'opérateur est drainé et mis à niveau. Temps de pause de moins de 5 minutes. |
Une fois la mise à niveau des nœuds du plan de contrôle terminée. |
| MetalLB (cluster d'utilisateur uniquement) | Opérateur drainé et mis à niveau. Le temps de pause est de moins de cinq minutes.
Aucun temps d'arrêt pour le service existant |
Une fois la mise à niveau des nœuds du plan de contrôle terminée. |
| Autoscaler CoreDNS et DNS (cluster d'utilisateur uniquement) | CoreDNS dispose de plusieurs instances répliquées avec autoscaler. Aucun temps d'arrêt en général. | Une fois la mise à niveau des nœuds du plan de contrôle terminée. |
| Approvisionneur de volume local | Aucun temps d'arrêt pour les volumes persistants provisionnés existants.
L'opérateur peut avoir un temps d'arrêt de cinq minutes. |
Une fois la mise à niveau des nœuds du plan de contrôle terminée. |
| Istio / Entrée | L'opérateur Istio est drainé et mis à niveau. Environ cinq minutes de temps d'arrêt. L'entrée configurée existante continue de fonctionner. |
Une fois la mise à niveau des nœuds du plan de contrôle terminée. |
| Autres opérateurs système | 5 minutes d'arrêt en cas de drainage et de mise à niveau. | Une fois la mise à niveau des nœuds du plan de contrôle terminée. |
| Charges de travail des utilisateurs | Cela dépend de la configuration, par exemple si la disponibilité élevée. Examinez vos propres déploiements de charges de travail pour comprendre l'impact potentiel. |
Lorsque les nœuds de calcul sont mis à niveau. |
Détails de la mise à niveau du cluster d'utilisateur
Cette section détaille l'ordre des mises à niveau des composants et fournit des informations sur l'état de la mise à niveau d'un cluster d'utilisateur. La section suivante détaille les écarts par rapport à ce flux pour les mises à niveau de clusters d'administrateur, hybrides ou autonomes.
Le schéma suivant illustre le processus de vérification préliminaire pour une mise à niveau d'un cluster d'utilisateur:
Le schéma précédent détaille les étapes d'une mise à niveau:
- La commande
bmctl upgrade clustercrée une ressource personnaliséePreflightCheck. - Cette vérification préliminaire exécute des vérifications supplémentaires telles que des vérifications de mise à niveau du cluster, des vérifications d'état du réseau et des vérifications de l'état des nœuds.
- Les résultats de ces vérifications supplémentaires sont combinés pour indiquer la capacité du cluster à passer à la version cible.
Si les vérifications préliminaires aboutissent et qu'il n'y a pas de problème bloquant, les composants du cluster sont mis à niveau dans un ordre spécifié, comme illustré dans le schéma suivant:
Dans le schéma précédent, les composants sont mis à niveau comme suit:
- La mise à niveau commence par la mise à jour du champ
spec.anthosBareMetalVersion. - Les équilibreurs de charge du plan de contrôle sont mis à niveau.
- Le pool de nœuds du plan de contrôle est mis à niveau.
- En parallèle, GKE Connect est mis à niveau, les modules complémentaires du cluster et le pool de nœuds de l'équilibreur de charge.
- Une fois le pool de nœuds de l'équilibreur de charge mis à niveau, les pools de nœuds de calcul sont mis à niveau.
Une fois tous les composants mis à niveau, les vérifications de l'état du cluster sont exécutées.
Les vérifications de l'état continuent de s'exécuter jusqu'à ce qu'elles soient toutes validées.
Une fois toutes les vérifications d'état effectuées, la mise à niveau est terminée.
Chaque composant possède son propre champ d'état dans la ressource personnalisée Cluster. Vous pouvez vérifier l'état dans les champs suivants pour comprendre la progression de la mise à niveau:
| Séquence | Nom du champ | Signification |
|---|---|---|
| 1 | status.controlPlaneNodepoolStatus |
L'état est copié à partir de l'état du pool de nœuds du plan de contrôle. Ce champ inclut les versions des nœuds des pools de nœuds du plan de contrôle |
| 2 | status.anthosBareMetalLifecycleControllersManifestsVersion
|
Version de lifecycles-controllers-manager appliquée au cluster. Ce champ n'est disponible que pour les clusters d'administrateur, autonomes ou hybrides. |
| 2 | status.anthosBareMetalManifestsVersion |
Version du cluster à partir du dernier fichier manifeste appliqué. |
| 2 | status.controlPlaneLoadBalancerNodepoolStatus |
L'état est copié à partir de l'état du pool de nœuds de l'équilibreur de charge du plan de contrôle. Ce champ est vide si aucun équilibreur de charge distinct du plan de contrôle n'est spécifié dans Cluster.Spec. |
| 3 | status.anthosBareMetalVersions |
Mappage de version agrégée entre la version et le nombre de nœuds. |
| 4 | status.anthosBareMetalVersion |
État final de la version mise à niveau. |
Informations sur la mise à niveau des clusters d'administrateur, hybrides et autonomes
À partir de la version 1.15.0 de bmctl, le comportement de mise à niveau par défaut des clusters autogérés (administrateurs, hybrides ou autonomes) est une mise à niveau sur place.
Autrement dit, lorsque vous mettez à niveau un cluster vers la version 1.15.0 ou une version ultérieure, la mise à niveau utilise des contrôleurs de cycle de vie au lieu d'un cluster d'amorçage pour gérer l'ensemble du processus de mise à niveau. Cette modification simplifie le processus et réduit les besoins en ressources, ce qui rend les mises à niveau des clusters plus fiables et évolutives.
Bien que l'utilisation d'un cluster d'amorçage pour la mise à niveau ne soit pas recommandée, cette option reste disponible. Pour utiliser un cluster d'amorçage lors de la mise à niveau, exécutez la commande bmctl upgrade avec l'option --use-bootstrap=true.
Les étapes de la mise à niveau sont différentes selon la méthode que vous utilisez.
Mises à niveau sur place
Le processus de mise à niveau sur place par défaut pour les clusters autogérés est semblable au processus de mise à niveau des clusters d'utilisateur. Toutefois, lorsque vous utilisez le processus de mise à niveau sur place, une nouvelle version de preflightcheck-operator est déployée avant l'exécution de la vérification préliminaire et de l'état du cluster:
Comme pour la mise à niveau du cluster d'utilisateur, le processus de mise à niveau commence par la mise à jour du champ Cluster.spec.anthosBareMetalVersion vers la version cible. Deux étapes supplémentaires s'exécutent avant la mise à jour des composants, comme illustré dans le schéma suivant: lifecycle-controller-manager se met à niveau vers la version cible, puis déploie la version cible de anthos-cluster-operator. Ce anthos-cluster-operator effectue les étapes restantes du processus de mise à niveau:
En cas de réussite, anthos-cluster-operator rapproche la version cible spec.anthosBareMetalVersion de status.anthosBareMetalVersion.
Effectuer une mise à niveau avec un cluster d'amorçage
Le processus de mise à niveau d'un cluster d'administrateur, hybride ou autonome est semblable à celui d'un cluster d'utilisateur décrit dans la section précédente.
La principale différence est que la commande bmctl upgrade cluster démarre un processus pour créer un cluster d'amorçage. Ce cluster d'amorçage est un cluster temporaire qui gère le cluster hybride, d'administrateur ou autonome lors d'une mise à niveau.
Le processus de transfert de la propriété de la gestion du cluster vers le cluster d'amorçage est appelé pivot. Le reste de la mise à niveau suit le même processus que la mise à niveau du cluster d'utilisateur.
Pendant le processus de mise à niveau, les ressources du cluster cible restent obsolètes. La progression de la mise à niveau n'est reflétée que dans les ressources du cluster d'amorçage.
Si nécessaire, vous pouvez accéder au cluster d'amorçage pour surveiller et déboguer le processus de mise à niveau. Le cluster d'amorçage est accessible via bmctl-workspace/.kindkubeconfig.
Pour retransférer la propriété de la gestion du cluster une fois la mise à niveau terminée, le cluster fait pivoter les ressources du cluster d'amorçage vers le cluster mis à niveau. Aucune étape manuelle n'est nécessaire pour faire pivoter le cluster pendant le processus de mise à niveau. Le cluster d'amorçage est supprimé une fois la mise à niveau du cluster effectuée.
Drainage des nœuds
Les mises à niveau des clusters GKE sur Bare Metal peuvent entraîner une interruption de l'application lorsque les nœuds sont drainés. Ce processus de drainage entraîne l'arrêt et le redémarrage de tous les pods exécutés sur un nœud sur les nœuds restants du cluster.
Les déploiements peuvent être utilisés pour tolérer de telles perturbations. Un déploiement peut spécifier plusieurs instances répliquées d'une application ou d'un service à exécuter. Une application comportant plusieurs instances répliquées ne devrait subir que peu ou pas de perturbations pendant les mises à niveau.
Budgets d'interruptions de pods (PDB)
Les budgets d'interruption de pods (PDB) permettent de garantir qu'un nombre défini d'instances répliquées s'exécutent toujours dans le cluster dans des conditions d'exécution normales. Les PDB vous permettent de limiter les interruptions d'une charge de travail lorsque ses pods doivent être reprogrammés.
Toutefois, GKE sur Bare Metal ne respecte pas les PDB lorsque les nœuds se déchargent lors d'une mise à niveau.
Au lieu de cela, le processus de drainage des nœuds est la meilleure solution. Certains pods peuvent rester bloqués à l'état Terminating et refuser de libérer le nœud. La mise à niveau se poursuit, même avec des pods bloqués, lorsque le processus de drainage sur un nœud prend plus de 20 minutes.
Étapes suivantes
- Consultez les bonnes pratiques pour les mises à niveau de GKE sur Bare Metal.
- Mettre à niveau des clusters
- Résoudre les problèmes liés à la mise à niveau du cluster