Lorsque vous mettez à niveau GKE sur une solution Bare Metal, le processus de mise à niveau implique plusieurs étapes et composants. Pour surveiller l'état de la mise à niveau, ou diagnostiquer et résoudre les 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 de la mise à niveau d'un cluster.
Présentation
Le processus de mise à niveau fait passer GKE sur Bare Metal de la version actuelle à une version supérieure.
Ces informations de version sont stockées aux emplacements suivants en tant que ressource personnalisée du cluster dans le cluster d'administrateur:
status.anthosBareMetalVersion: définit la version actuelle du cluster.spec.anthosBareMetalVersion: définit la version souhaitée 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 souhaitée de spec.anthosBareMetalVersion de status.anthosBareMetalVersion.
Décalage entre les versions
Le décalage de version correspond à la différence de versions entre un cluster d'administrateur et ses clusters d'utilisateur gérés. GKE sur Bare Metal suit le même style que Kubernetes : le cluster d'administrateur peut avoir au maximum une version mineure d'avance sur 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.14.11 de bmctl, vous ne pouvez mettre à niveau un cluster que vers la version 1.14.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.14.X vers la version 1.14.Y tant que Y est supérieur à X. Par exemple, vous pouvez passer de la version 1.13.0 à la version 1.13.1 et de la version 1.13.1 à la version 1.13.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.13.3 à la version 1.14.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.12.0 vers la version 1.14.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.13.2 vers GKE sur une solution Bare Metal 1.14.11.
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, avec différents composants 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 les 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 Anthos | Pods statiques du plan de contrôle Kubernetes (kubeapi-server, kube-scheduler, kube-controller-manager, etcd)
Contrôleurs de cycle de vie tels que lifecycle-controllers-manager et anthos-cluster-operatorModules complémentaires de la plate-forme Anthos tels que stackdriver-log-aggregator et gke-connect-agent |
| Équilibreur de charge du plan de contrôle | Exécute HAProxy et Keeparied pour diffuser le trafic vers kube-apiserver, et exécution de haut-parleurs MetalLB pour revendiquer des adresses IP virtuelles |
Pods statiques de l'équilibreur de charge du plan de contrôle (HAProxy, Keeparied) Haut-parleurs MetalLB |
Temps de pause attendu
Le tableau suivant détaille les temps d'arrêt attendus 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 si 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. |
| Interface réseau de conteneurs (CNI) | Aucun temps d'arrêt pour les routes réseau existantes. Le DaemonSet a été déployé deux par deux sans temps d'arrêt. L'opérateur est drainé et mis à niveau. Temps de pause inférieur à 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 inférieur à 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. Habituellement, aucun temps d'arrêt. | 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.
Un temps d'arrêt de cinq minutes peut être nécessaire pour l'opérateur. |
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. Temps d'arrêt d'environ 5 minutes. 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 de temps d'arrêt lorsque l'appareil est vidé et mis à niveau. | Une fois la mise à niveau des nœuds du plan de contrôle terminée. |
| Charges de travail des utilisateurs | Dépend de la configuration, par exemple de 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 les informations d'état pour la mise à niveau d'un cluster d'utilisateur. La section suivante détaille les écarts par rapport à ce flux pour les mises à niveau de cluster 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 qui ont lieu lors 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 la mise à niveau du cluster, des vérifications de l'é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 aucun 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 sont mis à niveau.
- 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, celle-ci est terminée.
Chaque composant possède son propre champ d'état dans la ressource personnalisée du cluster. Vous pouvez vérifier l'état dans les champs suivants pour comprendre la progression de la mise à niveau:
| Séquence | Field name | 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 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 pour le plan de contrôle n'est spécifié dans Cluster.Spec. |
| 3 | status.anthosBareMetalVersions |
Mappage des versions agrégées 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 administrateur, hybrides et autonomes
La mise à niveau d'un cluster d'administrateur, hybride et autonome utilise généralement un cluster d'amorçage pour gérer le processus. À partir de la version 1.13.0 de GKE sur Bare Metal, vous pouvez exécuter la mise à niveau sans cluster d'amorçage. Seuls les clusters de la version 1.13.0 ou ultérieure peuvent être mis à niveau sans cluster d'amorçage. Les étapes de la mise à niveau diffèrent selon la méthode que vous utilisez.
Pour plus d'informations sur les mises à niveau sur place, consultez la page Mises à niveau sur place pour les clusters autogérés.
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 lance 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, administrateur ou autonome lors d'une mise à niveau.
Le processus de transfert de la propriété du cluster vers le cluster d'amorçage s'appelle un pivot. Le reste de la mise à niveau suit le même processus que la mise à niveau du cluster d'utilisateur.
Au cours du 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 transférer la propriété de gestion du cluster une fois la mise à niveau terminée, le cluster croise les ressources du cluster d'amorçage vers le cluster mis à niveau. Aucune étape manuelle n'est nécessaire pour faire pivoter le cluster lors du processus de mise à niveau. Le cluster d'amorçage est supprimé une fois sa mise à niveau réussie.
Sans cluster d'amorçage
GKE sur Bare Metal 1.13.0 ou version ultérieure peut mettre à niveau un cluster administrateur, hybride ou autonome sans cluster d'amorçage. Sans cluster d'amorçage, la mise à niveau est semblable à celle du cluster d'utilisateur.
Le schéma suivant montre les différences avec l'expérience des clusters d'utilisateur.
Sans cluster d'amorçage, une nouvelle version de preflightcheck-operator est déployée avant l'exécution des vérifications préliminaires et de l'état du cluster:
Comme pour la mise à niveau du cluster d'utilisateur, le processus commence par mettre à jour le champ Cluster.Spec.AnthosBareMetalVersion avec la version souhaitée.
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 souhaitée, puis déploie la version souhaitée de anthos-cluster-operator. Cette anthos-cluster-operator sera rapprochée ultérieurement dans le processus de mise à niveau:
Drainage des nœuds
Les mises à niveau de 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 aucune interruption ou presque pendant les mises à niveau.
Budgets d'interruption de pod (PDB)
Les budgets d'interruption de pod (PDB) permettent de garantir qu'un nombre défini d'instances répliquées s'exécutent toujours dans le cluster dans des conditions normales d'exécution. Les PDB vous permettent de limiter les perturbations 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 concernant les mises à niveau des clusters Anthos sur bare metal.
- Mettre à niveau des clusters Anthos sur bare metal
- Résoudre les problèmes liés à la mise à niveau du cluster