Clusters Anthos sur VMware devient Google Distributed Cloud (logiciel uniquement) pour VMware. Pour en savoir plus, consultez la présentation du produit.

Cette page a été traduite par l'API Cloud Translation.

Migrer un cluster d'utilisateur vers Controlplane V2

Ce document explique comment migrer un cluster d'utilisateur version 1.29 ou ultérieure à l'aide de kubeception vers Controlplane V2.

1.29: Aperçu
1.28: Non disponible
1.16: Non disponible

À propos des plans de contrôle de cluster d'utilisateur

Avant la version 1.13 de Google Distributed Cloud, le plan de contrôle d'un cluster d'utilisateur était exécuté sur un ou plusieurs nœuds dans un cluster d'administrateur. Ce type de plan de contrôle est appelé "kubeception". Dans la version 1.13, Controlplane V2 a été introduite pour les nouveaux clusters d'utilisateur. Lorsque Controlplane V2 est activé, le plan de contrôle du cluster d'utilisateur s'exécute dans le cluster d'utilisateur lui-même.

Voici les avantages de Controlplane V2:

Isolation des défaillances. Une défaillance du cluster d'administrateur n'affecte pas les clusters d'utilisateur.
Séparation opérationnelle La mise à niveau d'un cluster d'administrateur n'entraîne pas de temps d'arrêt pour les clusters d'utilisateur.
Séparation des déploiements Vous pouvez placer les clusters d'administrateur et d'utilisateur dans différents domaines de défaillance ou sites géographiques. Par exemple, un cluster d'utilisateur situé dans un emplacement périphérique peut se trouver dans un site géographique différent de celui du cluster d'administrateur.

Conditions requises

Pour migrer un cluster d'utilisateur vers Controlplane V2, le cluster d'utilisateur doit répondre aux exigences suivantes:

Le cluster d'utilisateur doit être de version 1.29 ou ultérieure. Le cluster d'administrateur et les pools de nœuds peuvent être antérieurs d'une ou deux versions mineures au cluster d'utilisateur. Si nécessaire, mettez à niveau le cluster.
Dataplane V2 doit être activé sur le cluster d'utilisateur. Ce champ est immuable. Par conséquent, si Dataplane V2 n'est pas activé sur le cluster, vous ne pouvez pas le migrer vers Controlplane V2.
Le cluster d'utilisateur doit être configuré pour utiliser MetalLB ou un équilibreur de charge manuel. Si le cluster d'utilisateur utilise l'équilibreur de charge SeeSaw, vous pouvez le migrer vers MetalLB.
Consultez le document sur la planification des adresses IP et assurez-vous que vous disposez de suffisamment d'adresses IP disponibles pour les nœuds du plan de contrôle du cluster d'utilisateur. Les nœuds du plan de contrôle nécessitent des adresses IP statiques et vous aurez besoin d'une adresse IP supplémentaire pour une nouvelle adresse IP virtuelle (VIP) de plan de contrôle.

Mettre à jour le fichier de configuration du cluster d'utilisateur

Apportez les modifications suivantes au fichier de configuration du cluster d'utilisateur existant:

Définissez enableControlplaneV2 sur "true".
Vous pouvez également rendre le plan de contrôle pour le cluster d'utilisateur Controlplane V2 disponibilité élevée. Pour passer d'un cluster standard à un cluster à haute disponibilité, faites passer masterNode.replicas de 1 à 3.
Ajoutez la ou les adresses IP statiques du ou des nœuds du plan de contrôle du cluster d'utilisateur à la section network.controlPlaneIPBlock.ips.
Renseignez le masque de réseau et la passerelle dans la section network.controlPlaneIPBlock.
Si la section network.hostConfig est vide, remplissez-la.
Si le cluster d'utilisateur utilise l'équilibrage de charge manuel, configurez votre équilibreur de charge pour inclure les adresses IP des nœuds du plan de contrôle pour le trafic du plan de données:
- (ingressVIP:80) -> (CP_NODE_IP_ADDRESSES:ingressHTTPNodePort)
- (ingressVIP:443) -> (CP_NODE_IP_ADDRESSES:ingressHTTPSNodePort)
Mettez à jour le champ loadBalancer.vips.controlPlaneVIP avec la nouvelle adresse IP de l'adresse IP virtuelle du plan de contrôle. Notez qu'il doit se trouver sur le même VLAN que les adresses IP des nœuds du plan de contrôle.
Tous les champs précédents sont immuables, sauf lors de la mise à jour du cluster pour la migration. Vérifiez bien tous les paramètres.
Exécutez gkectl diagnose cluster et corrigez les problèmes détectés par la commande.
```
gkectl diagnose cluster --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name=USER_CLUSTER_NAME
```
Remplacez les éléments suivants :
- ADMIN_CLUSTER_KUBECONFIG: chemin d'accès au fichier kubeconfig du cluster d'administrateur.
- CLUSTER_NAME : nom du cluster d'utilisateur.

Ajuster la configuration manuelle de l'équilibreur de charge

Si votre cluster d'utilisateur utilise l'équilibrage de charge manuel, effectuez l'étape décrite dans cette section. Sinon, ignorez cette section.

De la même manière que pour configurer votre équilibreur de charge pour un cluster d'utilisateur CPv2, configurez les mappages dans votre équilibreur de charge pour chacune des trois nouvelles adresses IP de nœud du plan de contrôle que vous avez spécifiées dans la section network.controlPlaneIPBlock:

(ingressVIP:80) -> (NOUVEAU_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NOUVELLE_ADRESSE_IP_NODE:ingressHTTPNodePort)

Mettre à jour le cluster

Exécutez la commande suivante pour migrer le cluster vers Controlplane V2:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Remplacez les éléments suivants :

ADMIN_CLUSTER_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur
USER_CLUSTER_CONFIG: chemin d'accès au fichier de configuration du cluster d'utilisateur.

La commande :

Créez le plan de contrôle d'un nouveau cluster sur lequel ControlPlane V2 est activé.
Arrêtez le plan de contrôle Kubernetes du cluster kubeception.
Prenez un instantané etcd du cluster kubeception.
Éteignez les nœuds du plan de contrôle du cluster d'utilisateur du cluster kubeception. Notez que, pour la reprise après échec, c'est-à-dire pour revenir au cluster kubeception, les nœuds ne sont pas supprimés avant la fin de la migration.
Restaurez les données du cluster dans le nouveau plan de contrôle avec l'instantané etcd mentionné précédemment.
Connectez les nœuds du pool de nœuds du cluster kubeception au nouveau plan de contrôle, qui est accessible avec le nouveau controlPlaneVIP.
Rapprochez le cluster d'utilisateur restauré pour qu'il atteigne son état final lorsque ControlPlane V2 est activé.

Remarques

La migration n'entraîne aucun temps d'arrêt pour les charges de travail des clusters d'utilisateur.
Pendant la migration, le plan de contrôle du cluster d'utilisateur subit un temps d'arrêt. Plus précisément, le plan de contrôle n'est pas disponible entre l'étape 2 et la fin de l'étape 6. D'après nos tests, le temps d'arrêt est inférieur à sept minutes, mais sa durée réelle dépend de votre infrastructure.
À la fin de la migration, les nœuds du plan de contrôle du cluster d'utilisateur des clusters kubeception sont supprimés. Si network.ipMode.type du cluster d'administrateur est défini sur "static", vous pouvez recycler certaines des adresses IP statiques inutilisées en les supprimant du fichier de configuration du cluster d'administrateur et en exécutant gkectl update admin. Vous pouvez répertorier les objets de nœud de cluster d'administrateur avec kubectl get nodes -o wide pour voir les adresses IP utilisées.