Ce document explique comment migrer un cluster d'utilisateur version 1.29 ou ultérieure vers le plan de contrôle V2 à l'aide de kubeception.
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 s'exécutait sur un ou plusieurs nœuds d'un cluster d'administrateur. On parle de "kubeception" à ce type de plan de contrôle. Dans la version 1.13, Plan de contrôle V2 a été introduit pour les nouveaux clusters d'utilisateur. Lorsque le plan de contrôle 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 échecs. La défaillance d'un 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 des domaines de défaillance ou des sites géographiques différents. Par exemple, un cluster d'utilisateur dans un emplacement périphérique peut se trouver dans un site géographique différent du cluster d'administrateur.
Conditions requises
Pour migrer un cluster d'utilisateur vers le plan de contrôle V2, celui-ci 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 infé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 de planification des adresses IP et assurez-vous que vous disposez de suffisamment d'adresses IP disponibles pour les nœuds de 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 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 assurer la disponibilité élevée du plan de contrôle pour le cluster d'utilisateur Controlplane V2. Pour passer d'un cluster standard à un cluster à haute disponibilité, faites passer
masterNode.replicas
de 1 à 3.Ajoutez la ou les adresses IP statiques des nœuds du plan de contrôle du cluster d'utilisateur à la section
network.controlPlaneIPBlock.ips
. Supprimez la ou les adresses IP du ou des nœuds du plan de contrôle du cluster d'utilisateur kubeception du fichier de bloc d'adresses IP du cluster d'administrateur.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.Tous les champs précédents sont immuables, sauf lors de la mise à jour du cluster pour la migration. Assurez-vous de bien vérifier 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 vous configurez 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 de plan de contrôle que vous avez spécifiées dans la section network.controlPlaneIPBlock:
- (ingressVIP:80) -> (NOUVELLE_ADRESSE_IP_NODE:ingressHTTPNodePort)
- (ingressVIP:443) -> (NOUVELLE_ADRESSE_IP_NODE:ingressHTTPNodePort)
Mettre à jour le cluster
Exécutez la commande suivante pour migrer le cluster vers le plan de contrôle 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'administrateurUSER_CLUSTER_CONFIG
: chemin d'accès au fichier de configuration du cluster d'utilisateur.