Planifier la migration du cluster vers les fonctionnalités recommandées

Présentation

Google Distributed Cloud est basé sur Kubernetes et de nombreuses autres technologies associées, qui sont continuellement mises à jour et améliorées pour offrir une meilleure évolutivité, des performances, une sécurité et des capacités d'intégration améliorées. Par conséquent, Google Distributed Cloud s'adapte et s'améliore constamment.

Dans la version 1.30, les modifications et les mises à jour ont atteint un point où nous vous recommandons vivement de migrer les anciens déploiements pour profiter d'améliorations importantes. Cette page décrit les avantages de la migration des fonctionnalités obsolètes vers les dernières fonctionnalités recommandées.

Vous disposez des options suivantes pour chaque fonctionnalité :

Zone de la fonctionnalité Options recommandées Options d'origine
CNI (Container Network Interface)
  • Dataplane V2
    (enableDataplaneV2: true)
  • Dataplane V1 (Calico)
    (enableDataplaneV2: false)
Équilibreur de charge
  • ManualLB (fonctionne avec les agents F5 Big IP)
    (loadBalancer.kind: "ManualLB")
  • MetalLB
    (loadBalancer.kind: "MetalLB")
  • F5 Big IP intégré1
    (loadBalancer.kind: "F5BigIP")
  • Seesaw
    (loadBalancer.kind: "Seesaw")
Plan de contrôle du cluster d'administrateur
  • Cluster d'administrateur haute disponibilité
    (adminMaster.replicas: 3)
  • Cluster d'administrateur standard
    (adminMaster.replicas: 1)
Plan de contrôle du cluster d'utilisateur
  • Plan de contrôle V2
    (enableControlplaneV2: true)
  • Cluster d'utilisateur Kubeception
    (enableControlplaneV2: false)

1 F5 Big IP intégré fait référence à loadBalancer.kind: "F5BigIP" et aux paramètres associés dans la section loadBalancer.f5BigIP du fichier de configuration de votre cluster.

Les tableaux suivants présentent la matrice de compatibilité de ces fonctionnalités dans les clusters d'administrateurs et d'utilisateurs :

Type de cluster Fonctionnalité obsolète Ajouter pour un nouveau cluster Autoriser pour la mise à niveau du cluster Migration vers une nouvelle fonctionnalité
Version 1.30
Admin Standard Non Oui Oui
Seesaw Non Oui Oui
F5 Big IP intégré Non Oui Oui
Utilisateur Kubeception Non Oui Oui
Seesaw Non Oui Oui
F5 Big IP intégré Non Oui Oui
Dataplane V1 Non Oui Oui
Version 1.29
Admin Standard Non Oui Oui (Bêta)
Seesaw Non Oui Oui
F5 Big IP intégré Oui Oui Oui (Bêta)
Utilisateur Kubeception Oui Oui Oui (Bêta)
Seesaw Oui Oui Oui
F5 Big IP intégré Oui Oui Oui (Bêta)
Dataplane V1 Oui Oui Non
Version 1.28
Admin Standard Non Oui Non
Seesaw Non Oui Oui
F5 Big IP intégré Oui Oui Non
Utilisateur Kubeception Oui Oui Non
Seesaw Oui Oui Oui
F5 Big IP intégré Oui Oui Non
Dataplane V1 Oui Oui Non

Points essentiels :

  • À partir de la version 1.30, toutes les solutions de migration sont disponibles pour migrer les clusters vers les alternatives recommandées.

  • Lors de la création de clusters, voici les versions dans lesquelles les fonctionnalités d'origine ne sont pas autorisées :

    • Clusters d'administrateur :

      • Plan de contrôle standard : version 1.28 ou ultérieure
      • Équilibrage de charge Seesaw : version 1.28 ou ultérieure
      • F5 Big IP intégré : version 1.30 ou ultérieure

    • Clusters d'utilisateur :

      • Kubeception : version 1.30 ou ultérieure
      • Seesaw : version 1.30 ou ultérieure
      • F5 Big IP intégré : version 1.30 ou ultérieure
      • Dataplane V1 : version 1.30 ou ultérieure

  • Vous pouvez toujours mettre à niveau les clusters existants avec les fonctionnalités d'origine.

Migrer des clusters d'utilisateurs vers Dataplane V2

Vous pouvez choisir une interface réseau de conteneur (CNI) qui offre des fonctionnalités de mise en réseau de conteneurs, soit Calico, soit Dataplane V2. Dataplane V2, l'implémentation CNI de Google, est basée sur Cilium et est utilisée à la fois dans Google Kubernetes Engine (GKE) et Google Distributed Cloud.

Dataplane V2 offre une conception optimisée et une utilisation efficace des ressources, ce qui améliore les performances et l'évolutivité du réseau, en particulier pour les grands clusters ou les environnements avec des besoins de trafic réseau élevés. Nous vous recommandons vivement de migrer vos clusters vers Dataplane V2 pour bénéficier des dernières fonctionnalités, innovations réseau et capacités.

À partir de la version 1.30, Dataplane V2 est la seule option CNI permettant de créer des clusters.

La transition de Calico vers Dataplane V2 nécessite une planification et une coordination, mais elle est conçue pour ne pas entraîner d'interruption de service pour les charges de travail existantes. En migrant de manière proactive vers Dataplane V2, vous pouvez bénéficier des avantages suivants :

  • Performances et évolutivité améliorées : la conception optimisée de Dataplane V2 et l'utilisation efficace des ressources peuvent améliorer les performances du réseau et l'évolutivité, en particulier dans les grands clusters ou les environnements avec des besoins en trafic réseau élevés. Cela est dû à l'utilisation d'EBPF au lieu d'IPTables, qui permet au cluster de s'adapter à l'aide de mappages BPF.

  • Gestion et assistance simplifiées : la standardisation de Dataplane V2 sur Google Distributed Cloud et GKE peut simplifier la gestion et le dépannage des clusters, car vous pouvez vous appuyer sur un ensemble cohérent d'outils et de documentation.

  • Fonctionnalités de mise en réseau avancées : EgressNAT et d'autres fonctionnalités de mise en réseau avancées ne sont compatibles qu'avec Dataplane V2. Toutes les futures requêtes réseau seront implémentées dans la couche Dataplane V2.

Avant la migration Après la migration
kube-proxy Obligatoire et déployé automatiquement Non obligatoire et non déployé
Routage kube-proxy + iptables eBPF

Migrer le type d'équilibreur de charge

Les types d'équilibreurs de charge recommandés (loadBalancer.kind) sont "ManualLB" et "MetalLB". Utilisez "ManualLB" si vous disposez d'un équilibreur de charge tiers tel que F5 BIG-IP ou Citrix. Utilisez "MetalLB" pour notre solution d'équilibrage de charge groupé à l'aide de l'équilibreur de charge MetalLB.

À partir de la version 1.30, ce sont les seules options pour créer des clusters. Pour les clusters existants qui utilisent l'équilibreur de charge F5 Big IP intégré ou l'équilibreur de charge Seesaw fourni, nous fournissons des guides de migration pour transférer les paramètres de configuration "F5BigIP" vers "ManualLB" et pour transférer l'équilibreur de charge fourni de Seesaw vers MetalLB.

Migrer les paramètres de configuration de votre équilibreur de charge F5 BIG-IP

Prévoyez de migrer vers ManualLB tous les clusters qui utilisent l'équilibreur de charge F5 Big IP intégré. F5 Big IP intégré utilise F5 BIG-IP avec des agents d'équilibrage de charge, qui se composent des deux contrôleurs suivants :

Le F5 Big IP intégré d'origine présente les limites suivantes :

  • Expression limitée : le F5 Big IP intégré limite le potentiel du F5 BIG-IP en limitant l'expression de l'API de service. Cela peut vous empêcher de configurer le contrôleur BIG-IP en fonction de vos besoins spécifiques ou d'exploiter les fonctionnalités F5 avancées qui peuvent être essentielles pour votre application.
  • Composant obsolète : l'implémentation actuelle repose sur des technologies plus anciennes, telles que l'API ConfigMap CCCL et la version 1.x de CIS. Ces anciens composants peuvent ne pas être compatibles avec les dernières avancées des offres F5, ce qui peut entraîner des opportunités manquées d'amélioration des performances et de la sécurité.

Les modifications apportées après la migration de F5 BIG-IP intégré vers ManualLB sont les suivantes :

Avant la migration Après la migration
Composants des agents F5
  • Contrôleur F5
  • Contrôleur OSS CIS
  • Contrôleur F5 (pas de changement)
  • Contrôleur OSS CIS (pas de changement)
Mise à niveau de la version du composant F5 Vous devez mettre à niveau les clusters pour mettre à niveau les composants F5. Les versions de composants disponibles sont limitées, comme expliqué précédemment. Vous pouvez mettre à niveau les versions des composants F5 si nécessaire.
Création du service Géré par les agents F5 Géré par les agents F5 (pas de changement)

Effectuer une migration de Seesaw vers MetalLB

MetalLB offre les avantages suivants par rapport à Seesaw :

  • Gestion simplifiée et ressources réduites : contrairement à Seesaw, MetalLB s'exécute directement sur les nœuds du cluster, ce qui permet d'utiliser de manière dynamique les ressources du cluster pour l'équilibrage de charge.
  • Attribution automatique d'adresses IP : le contrôleur MetalLB gère les adresses IP des services. Vous n'avez donc pas besoin de choisir manuellement une adresse IP pour chaque service.
  • Distribution de la charge entre les nœuds d'équilibrage de charge : les instances actives de MetalLB pour différents services peuvent s'exécuter sur différents nœuds.
  • Fonctionnalités améliorées et pérennité : le développement actif de MetalLB et son intégration à l'écosystème Kubernetes plus large en font une solution plus pérenne que Seesaw. L'utilisation de MetalLB vous permet de profiter des dernières avancées en matière d'équilibrage de charge.
Avant la migration Après la migration
Nœuds d'équilibrage de charge VM Seesaw supplémentaires (en dehors du cluster) Nœuds d'équilibrage de charge dans le cluster avec choix du client
Conservation de l'adresse IP du client Peut être obtenu via externalTrafficPolicy: Local Peut être obtenu via le mode DSR DataplaneV2
Création du service Adresse IP du service spécifiée manuellement Adresse IP de service attribuée automatiquement à partir du pool d'adresses

Migrer les clusters d'utilisateur vers Controlplane V2 et les clusters d'administrateur vers la haute disponibilité

Le plan de contrôle recommandé pour les clusters d'utilisateurs est Controlplane V2. Avec Controlplane V2, le plan de contrôle s'exécute sur un ou plusieurs nœuds du cluster d'utilisateurs lui-même. Avec l'ancien plan de contrôle, appelé kubeception, le plan de contrôle d'un cluster d'utilisateurs s'exécute dans un cluster d'administrateur. Pour créer un cluster d'administrateur à haute disponibilité, vous devez activer Controlplane V2 sur vos clusters d'utilisateurs.

À partir de la version 1.30, Controlplane V2 doit être activé pour les nouveaux clusters d'utilisateurs, et les nouveaux clusters d'administrateur seront à haute disponibilité. Les mises à niveau des clusters d'utilisateurs avec l'ancien plan de contrôle sont toujours prises en charge, tout comme les mises à niveau des clusters d'administrateur sans haute disponibilité.

Migrer des clusters d'utilisateurs vers Controlplane V2

Historiquement, les clusters d'utilisateurs utilisaient kubeception. La version 1.13 a introduit Controlplane V2 en tant que fonctionnalité en preview, qui est devenue disponible en version 1.14. Depuis la version 1.15, Controlplane V2 est l'option par défaut pour la création de clusters d'utilisateurs. Il s'agit également de la seule option dans la version 1.30.

Par rapport à kubeception, Controlplane V2 présente les avantages suivants :

  • Cohérence architecturale : les clusters d'administrateur et les clusters d'utilisateur utilisent la même architecture.
  • Isolation des défaillances : une défaillance du cluster d'administrateur n'affecte pas les clusters d'utilisateurs.
  • Séparation opérationnelle : la mise à niveau d'un cluster d'administrateur n'entraîne pas d'arrêt pour les clusters d'utilisateurs.
  • Séparation des déploiements : vous pouvez placer les clusters d'administrateur et d'utilisateur dans différents domaines de topologie ou à plusieurs emplacements. Par exemple, dans un modèle de déploiement de edge computing, un cluster d'utilisateurs peut se trouver dans un emplacement différent de celui du cluster d'administrateur.

Pendant la migration, il n'y a aucune interruption de service pour les charges de travail du cluster d'utilisateurs existant. En fonction de votre environnement vSphere sous-jacent, le plan de contrôle subira un temps d'arrêt minimal lors du passage à Controlplane V2. Le processus de migration effectue les opérations suivantes :

  • Crée un plan de contrôle dans le cluster d'utilisateurs.
  • Copie les données etcd de l'ancien plan de contrôle.
  • Transfère les nœuds de pool de nœuds existants (également appelés nœuds de calcul) vers le nouveau plan de contrôle.
Avant la migration Après la migration
Objets de nœuds Kubernetes du plan de contrôle Nœud du cluster d'administration Nœud du cluster d'utilisateur
Pods du plan de contrôle Kubernetes Statefulsets/Déploiements du cluster d'administrateur (espace de noms du cluster d'utilisateurs) Pods statiques du cluster d'utilisateurs (espace de noms kube-system)
Autres pods du plan de contrôle Statefulsets/Déploiements du cluster d'administrateur (espace de noms du cluster d'utilisateurs) Statefulsets/déploiements de cluster d'utilisateurs (espace de noms kube-system)
Adresse IP virtuelle du plan de contrôle Service d'équilibrage de charge du cluster d'administrateur keepalived + haproxy (pods statiques du cluster d'utilisateurs)
Données Etcd Volume persistant du cluster d'administrateur Disque de données
Gestion des adresses IP des machines du plan de contrôle IPAM ou DHCP IPAM
Réseau du plan de contrôle VLAN du cluster d'administrateur VLAN du cluster d'utilisateurs

Migrer vers un cluster d'administrateur HD

Historiquement, le cluster d'administrateur ne pouvait exécuter qu'un seul nœud de plan de contrôle, ce qui créait un risque inhérent de point de défaillance unique. En plus du nœud de plan de contrôle, les clusters d'administrateur non HD comportent également deux nœuds supplémentaires. Un cluster d'administrateur HD comporte trois nœuds de plan de contrôle sans nœuds complémentaires. Le nombre de VM requis par un nouveau cluster d'administrateur n'a donc pas changé, mais la disponibilité est considérablement améliorée. À partir de la version 1.16, vous pouvez utiliser un cluster d'administrateur haute disponibilité (HD), qui est devenu la seule option pour la création de clusters dans la version 1.28.

La migration vers un cluster d'administrateur HD offre les avantages suivants :

  • Fiabilité et disponibilité améliorées : la configuration HD élimine le point de défaillance unique, ce qui permet au cluster d'administrateur de rester opérationnel même si l'un des nœuds du plan de contrôle rencontre un problème.
  • Mise à niveau et mise à jour améliorées : toutes les étapes nécessaires pour mettre à niveau et mettre à jour un cluster d'administrateur sont désormais exécutées dans le cluster, et non dans une VM d'administration distincte. Cela permet de s'assurer que les mises à niveau et les mises à jour se poursuivent même si la session initiale de la VM d'administration peut être interrompue.
  • Source fiable pour les états de cluster : les clusters d'administrateur non HD s'appuient sur un "fichier de point de contrôle" hors bande pour stocker l'état du cluster d'administrateur. En revanche, le cluster d'administrateur HD stocke l'état à jour du cluster dans le cluster d'administrateur lui-même, ce qui fournit une source d'informations plus fiable sur l'état du cluster.

Vous pouvez choisir de migrer votre cluster d'administrateur standard vers un cluster d'administrateur à haute disponibilité, ce qui n'entraîne aucun temps d'arrêt pour les charges de travail utilisateur. Ce processus entraîne un temps d'arrêt et une perturbation minimes des clusters d'utilisateurs existants, principalement associés au changement de plan de contrôle. Le processus de migration effectue les opérations suivantes :

  • Crée un plan de contrôle HD.
  • Restaure les données etcd à partir du cluster non HD existant.
  • Transfère les clusters d'utilisateurs vers le nouveau cluster d'administrateur HD.
Avant la migration Après la migration
Instances dupliquées du nœud du plan de contrôle 1 3
Nœuds complémentaires 2 0
Taille du disque de données 100Go * 1 25Go * 3
Chemin d'accès aux disques de données Défini par vCenter.dataDisk dans le fichier de configuration du cluster d'administrateur Généré automatiquement dans le répertoire : /anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk
Adresse IP virtuelle du plan de contrôle Défini par loadBalancer.kind dans le fichier de configuration du cluster d'administrateur keepalived + haproxy
Allocation d'adresses IP pour les nœuds du plan de contrôle du cluster d'administrateur DHCP ou statique, en fonction de network.ipMode.type 3 adresses IP statiques

Migrations de groupes d'équilibreurs de charge et de plans de contrôle

En règle générale, lorsque vous mettez à jour des clusters, nous vous recommandons de mettre à jour une seule fonctionnalité ou un seul paramètre à la fois. Toutefois, dans la version 1.30 et les versions ultérieures, vous pouvez regrouper les modifications de configuration de la migration pour votre équilibreur de charge et votre plan de contrôle, puis mettre à jour le cluster une seule fois pour effectuer les deux modifications.

Si vos clusters d'utilisateurs utilisent une ancienne CNI, vous devez d'abord migrer vers Dataplane V2. Vous pouvez ensuite regrouper la migration de l'équilibreur de charge et du plan de contrôle. Le regroupement de la migration présente les avantages suivants :

  • Un processus plus simple : si vous devez migrer un plan de contrôle et un équilibreur de charge, vous ne mettez généralement à jour le cluster qu'une seule fois. Vous n'avez pas besoin de décider quelles fonctionnalités migrer en premier.
  • Réduire les temps d'arrêt globaux : certaines migrations impliquent des temps d'arrêt du plan de contrôle. Le regroupement de ces migrations dans une seule opération de mise à jour réduit les temps d'arrêt globaux par rapport à des mises à jour individuelles séquentielles.

La procédure varie en fonction des configurations de cluster. En général, effectuez la migration pour chaque cluster dans l'ordre suivant :

  1. Migrez chaque cluster d'utilisateurs pour utiliser le CNI recommandé, Dataplane V2.

    1. Modifiez la configuration et mettez à jour le cluster d'utilisateurs pour déclencher une migration du cluster d'utilisateurs de Calico vers Dataplane V2.

  2. Migrez chaque cluster d'utilisateur pour utiliser l'équilibreur de charge et Controlplane V2 recommandés.

    1. Modifiez la configuration pour utiliser l'équilibreur de charge recommandé (MetalLB ou ManualLB).
    2. Modifiez la configuration pour activer Controlplane V2.
    3. Mettez à jour le cluster d'utilisateurs pour migrer l'équilibreur de charge et le plan de contrôle.

  3. Migrez le cluster d'administrateur pour utiliser l'équilibreur de charge recommandé et rendre le plan de contrôle hautement disponible.

    1. Modifiez la configuration pour utiliser l'équilibreur de charge recommandé (MetalLB ou ManualLB).
    2. Modifiez la configuration pour migrer le plan de contrôle du cluster d'administrateur d'un cluster standard vers un cluster haute disponibilité.
    3. Mettez à jour le cluster d'administrateur pour migrer l'équilibreur de charge et le plan de contrôle.

  4. Effectuez les étapes de nettoyage facultatives, comme le nettoyage de la VM du plan de contrôle standard.

Si votre cluster d'administrateur et tous vos clusters d'utilisateurs sont à la version 1.30 ou supérieure, vous pouvez utiliser le processus de migration de groupe. Pour connaître la procédure détaillée, consultez les pages suivantes :