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

Migrer un cluster d'utilisateurs vers les fonctionnalités recommandées

Présentation

Cette page explique comment migrer les clusters d'utilisateurs de la version 1.30 ou ultérieure vers les fonctionnalités recommandées suivantes:

Migrez vers Dataplane V2 en tant qu'interface réseau de conteneur (CNI).
Migrez les clusters d'utilisateurs à l'aide de kubeception vers Controlplane V2.
Migrez la configuration de l'équilibreur de charge:
- De la configuration de l'équilibreur de charge F5 BIG-IP intégré à ManualLB
  
  ou
- De l'équilibreur de charge Seesaw groupé vers MetalLB.

Cette page s'adresse aux administrateurs et opérateurs informatiques qui gèrent le cycle de vie de l'infrastructure technologique sous-jacente. Pour en savoir plus sur les rôles courants et les exemples de tâches que nous citons dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Bonnes pratiques

Nous vous recommandons de commencer par migrer l'environnement le moins critique, tel que l'environnement de test. Une fois que vous avez vérifié que la migration a réussi, répétez cette procédure pour chaque environnement, en migrant votre environnement de production en dernier. Vous pouvez ainsi valider la réussite de chaque migration et vous assurer que vos charges de travail s'exécutent correctement avant de passer à l'environnement suivant, plus critique.

Nous vous recommandons de créer un cluster d'utilisateurs avec Controlplane V2 activé pour en savoir plus sur les différences d'architecture avec les clusters kubeception. Le nouveau cluster n'affecte pas vos charges de travail. Toutefois, dans le pire des cas, si la migration échoue, vous disposez d'un cluster prêt à accueillir vos charges de travail.

Pour en savoir plus sur la planification de la migration, consultez la section Planifier la migration du cluster vers les fonctionnalités recommandées.

Conditions requises

Pour cette migration:

Le cluster utilisateur doit être à la version 1.30 ou ultérieure.
Tous les pools de nœuds doivent être de la même version que le cluster d'utilisateur.
Si le cluster utilise l'équilibreur de charge Seesaw, assurez-vous de ne pas vous fier à Seesaw pour la conservation de l'adresse IP du client, comme décrit dans la section suivante.

Conservation de l'adresse IP du client Seesaw

Pour vérifier le externalTrafficPolicy, exécutez la commande suivante:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

Si vous rencontrez ce problème, contactez l'assistance Google.

Estimer le temps nécessaire et planifier un intervalle de maintenance

Lorsque vous mettez à jour le cluster, tous les pools de nœuds sont mis à jour en parallèle par défaut. Toutefois, dans chaque pool de nœuds, les nœuds sont mis à jour de manière séquentielle. Par conséquent, la durée totale de la mise à jour dépend du nombre de nœuds dans le plus grand pool de nœuds. Pour calculer une estimation approximative pour chaque mise à jour:

Si vous passez de Seesaw à MetalLB, comptez 15 minutes pour que la mise à jour choisisse un pool de nœuds pour l'équilibreur de charge MetalLB. Pour cette mise à jour, seul le pool de nœuds sélectionné est mis à jour.
Pour toute autre mise à jour du processus de migration, multipliez 15 minutes par le nombre de nœuds du pool de nœuds.

Pour estimer le temps nécessaire, comptez le nombre de fois où vous devez mettre à jour le cluster. Les étapes générales suivantes indiquent quand vous devez exécuter gkectl update cluster pour mettre à jour le cluster:

Si le cluster utilisateur utilise le chiffrement permanent des secrets, désactivez la fonctionnalité et exécutez gkectl update cluster.
Si enableDataplaneV2 n'est pas défini ou est défini sur false dans le cluster d'utilisateurs, effectuez les modifications de configuration, puis exécutez gkectl update cluster pour migrer vers Dataplane V2.
Préparez la migration de l'équilibreur de charge et du plan de contrôle:
1. Si la réparation automatique est activée dans le cluster d'administrateur, désactivez-la. Exécutez ensuite gkectl update admin. Cette mise à jour se termine rapidement, car elle ne recrée pas les nœuds du cluster d'administration.
2. Si le cluster utilisateur utilise Seesaw, choisissez un pool de nœuds à utiliser par l'équilibreur de charge MetalLB, puis exécutez gkectl update cluster. Cette mise à jour ne concerne que les nœuds du pool de nœuds sélectionné.
Apportez toutes les modifications de configuration nécessaires pour mettre à jour votre équilibreur de charge et migrer vers Controlplane V2. Exécutez ensuite gkectl update cluster.
Après la migration, si vous avez désactivé le chiffrement permanent des secrets, réactivez la fonctionnalité et exécutez gkectl update cluster.

La durée totale de la migration dépend du nombre de fois que vous devez exécuter gkectl cluster update, qui dépend de votre configuration. Par exemple, supposons que vous migriez vers Dataplane V2, ControlPlane V2 et MetalLB. Supposons également qu'il y ait 10 nœuds dans le plus grand pool de nœuds et trois nœuds dans le pool de nœuds que MetalLB utilisera. Pour calculer une estimation du temps de migration, ajoutez les éléments suivants:

150 minutes pour la migration vers Dataplane V2, car 15 minutes * 10 nœuds dans le plus grand pool = 150 minutes.
45 minutes pour le pool de nœuds utilisé par MetalLB, car 15 minutes * 3 nœuds dans ce pool de nœuds = 45 minutes.
150 minutes pour la mise à jour de Controlplane V2 et MetalLB, car 15 minutes * 10 nœuds dans le plus grand pool = 150 minutes.

La durée totale de la migration est d'environ 345 minutes, soit 5 heures et 45 minutes.

Si nécessaire, vous pouvez effectuer la migration par étapes. En vous appuyant sur l'exemple précédent, vous pouvez effectuer la migration vers Dataplane V2 en une seule période de maintenance, puis effectuer le reste de la migration en une ou deux périodes de maintenance.

Planifier les temps d'arrêt pendant la migration

Lorsque vous planifiez votre migration, prévoyez ces types d'arrêts:

Temps d'arrêt du plan de contrôle: l'accès au serveur d'API Kubernetes est affecté pendant la migration. Si vous effectuez la migration vers Controlplane V2, le plan de contrôle est indisponible pour les clusters d'utilisateur kubeception pendant la migration de loadBalancer.vips.controlPlaneVIP. Le temps d'arrêt est généralement inférieur à 10 minutes, mais sa durée dépend de votre infrastructure.
Temps d'arrêt de la charge de travail : les adresses IP virtuelles (VIP) utilisées par les services de type LoadBalancer ne sont pas disponibles. Cela ne se produit que lors d'une migration de Seesaw vers MetalLB. Le processus de migration MetalLB interrompt les connexions réseau à toutes les adresses VIP du cluster utilisateur pour les services Kubernetes de type LoadBalancer pendant environ deux à dix minutes. Une fois la migration terminée, les connexions fonctionnent à nouveau.

Le tableau suivant décrit l'impact de la migration:

De	Vers	Accès aux API Kubernetes	Charges de travail de l'utilisateur
Cluster Kubeception utilisant Calico, pour lequel `enableDataplaneV2` n'est pas défini ou est défini sur `false`	Cluster Kubeception avec Dataplane V2	Non affecté	Non affecté
Cluster kubeception, pour lequel `enableControlplaneV2` n'est pas défini ou est défini sur `false` avec `MetalLB` ou `ManualLB`	Cluster Controlplane V2 avec le même type d'équilibreur de charge	Affecté	Non affecté
Cluster Kubeception avec `loadBalancer.kind: "F5BigIP"`	Cluster Controlplane V2 avec configuration de l'équilibreur de charge manuel	Affecté	Non affecté
Cluster Kubeception avec `loadBalancer.kind: "Seesaw"`	Cluster Controlplane V2 avec MetalLB	Affecté	Affecté

Affecté: une interruption de service est perceptible pendant la migration.
Non affecté: il n'y a pas d'interruption de service ou elle est presque imperceptible.

Préparer la migration

Pour garantir la réussite de la migration, suivez les étapes décrites dans les sections suivantes.

Allouer de nouvelles adresses IP

Si vous migrez vers Controlplane V2, allouez de nouvelles adresses IP statiques dans le même VLAN que les nœuds de calcul (les nœuds des pools de nœuds).

Vous avez besoin d'une adresse IP pour le loadBalancer.vips.controlPlaneVIP.
Allouez une adresse IP à chaque nœud du plan de contrôle. Le nombre d'adresses IP que vous devez allouer dépend du fait que le cluster d'utilisateurs sera disponibilité élevée (HA) ou non.
- Non-HA: une adresse IP
- HA: trois adresses IP

Mettre à jour les règles de pare-feu

Si vous migrez vers Controlplane V2, mettez à jour les règles de pare-feu sur vos clusters d'utilisateurs. Assurez-vous que les nouvelles adresses IP allouées aux nœuds du plan de contrôle du cluster d'utilisateur peuvent atteindre toutes les API et autres destinations requises, comme décrit dans la section Règles de pare-feu des nœuds du cluster d'utilisateur.

Vérifier les versions du cluster et du pool de nœuds

Vérifiez que tous les pools de nœuds utilisent la même version que le cluster d'utilisateur, qui doit être en version 1.30 ou ultérieure. Si ce n'est pas le cas, mettez à niveau les pools de nœuds vers la version gkeOnPremVersion dans le fichier de configuration du cluster d'utilisateur avant de poursuivre la migration. Pour vérifier les versions, exécutez la commande suivante:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Remplacez ADMIN_CLUSTER_KUBECONFIG par le chemin d'accès au fichier kubeconfig de votre cluster d'administrateur.

Vérifier l'état du cluster

Vérifiez l'état du cluster et corrigez les problèmes signalés par la commande gkectl diagnose cluster:

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
USER_CLUSTER_NAME : nom du cluster d'utilisateur.

Désactiver la réparation automatique dans le cluster d'administrateur

Si vous migrez le cluster d'utilisateur vers Controlplane V2 et que la réparation automatique est activée dans le cluster d'administrateur, désactivez-la. Vérifiez le champ autoRepair.enabled du fichier de configuration du cluster d'administrateur. Si ce champ n'est pas défini ou est défini sur true, procédez comme suit:

Dans le fichier de configuration du cluster d'administrateur, définissez autoRepair.enabled sur false . Exemple :
```
autoRepair:
  enabled: false
```

Mettez à jour le cluster d'administrateur :

gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG

Remplacez les éléments suivants :

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

Une fois la migration terminée, veillez à réactiver la réparation automatique dans le cluster d'administration.

Rechercher un problème avec le chiffrement des secrets toujours activé

Si vous migrez le cluster d'utilisateur vers Controlplane V2, recherchez un problème lié au chiffrement permanent des secrets.

Si le chiffrement permanent des secrets a déjà été activé sur le cluster utilisateur, vous devez suivre la procédure décrite dans Désactiver le chiffrement permanent des secrets et déchiffrer les secrets avant de commencer la migration. Sinon, le nouveau cluster Controlplane V2 ne pourra pas déchiffrer les secrets.

Avant de commencer la migration, exécutez la commande suivante pour vérifier si le chiffrement permanent des secrets a déjà été activé :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Si le résultat de la commande précédente est vide, le chiffrement permanent des secrets n'a jamais été activé. Vous pouvez lancer la migration.

Si le résultat de la commande précédente n'est pas vide, cela signifie que le chiffrement permanent des secrets était précédemment activé. Avant de procéder à la migration, vous devez suivre les étapes de la section suivante pour vous assurer que le nouveau cluster Control-Plane V2 peut déchiffrer les secrets.

L'exemple suivant montre une sortie non vide :

{"generatedKeyVersions":{"keyVersions":[1]}}

Désactiver le chiffrement permanent des secrets et déchiffrer les secrets si nécessaire

Pour désactiver le chiffrement permanent des secrets et déchiffrer les secrets, procédez comme suit :

Dans le fichier de configuration du cluster d'utilisateur, pour désactiver le chiffrement permanent des secrets, ajoutez un champ disabled: true à la section secretsEncryption :
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Mettez à jour le cluster :
```
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

Effectuez une mise à jour progressive sur un DaemonSet spécifique, comme suit :

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  rollout restart statefulsets kube-apiserver \
  -n USER_CLUSTER_NAME

Obtenez les fichiers manifestes de tous les secrets du cluster utilisateur au format YAML :

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  get secrets -A -o yaml > SECRETS_MANIFEST.yaml

Pour que tous les secrets soient stockés dans etcd en texte brut, réappliquez tous les secrets dans le cluster utilisateur :
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Vous pouvez maintenant commencer la migration vers Control-plane V2. Une fois la migration terminée, vous pouvez réactiver le chiffrement des secrets toujours activé sur le cluster.

Activer un pool de nœuds pour MetalLB

Si vous passez de l'équilibreur de charge Seesaw groupé à MetalLB, suivez la procédure décrite dans cette section. Le cluster utilise Seesaw si loadBalancer.kind: Seesaw figure dans le fichier de configuration du cluster d'utilisateur. Si vous migrez la configuration F5 BIG-IP intégrée, passez à la section suivante, Migrer vers Dataplane V2.

Choisissez un pool de nœuds et activez-le pour l'utiliser avec MetalLB. La migration déploie MetalLB sur les nœuds de ce pool de nœuds.

Dans la section nodePools de votre fichier de configuration du cluster d'utilisateur, choisissez un pool de nœuds ou ajoutez-en un, puis définissez enableLoadBalancer sur true. Exemple :
```
nodePools:
  - name: pool-1
    replicas: 3
    enableLoadBalancer: true
```

Mettez à jour le cluster :

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

Pour en savoir plus sur MetalLB, consultez la section Équilibrage de charge groupé avec MetalLB.

Migrer vers Dataplane V2

Avant de migrer, vérifiez si DataPlane V2 est activé sur le cluster en exécutant la commande suivante:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

Si Dataplane V2 est déjà activé, passez à la section suivante, Préparer la migration de l'équilibreur de charge.

Pour migrer vers Dataplane V2, vous disposez des options suivantes:

Mettez à niveau le cluster vers la version 1.31. Pour en savoir plus, consultez la page Activer Dataplane V2.
Mettez à jour le cluster 1.30.

Dans les deux cas, vous devez supprimer temporairement la spécification NetworkPolicy, comme décrit dans les étapes suivantes.

Pour migrer vers Dataplane V2, procédez comme suit. Si vous avez des questions concernant la suppression temporaire de la spécification NetworkPolicy, contactez l'assistance Google.

Si votre cluster utilise un NetworkPolicy, supprimez temporairement sa spécification du cluster, comme suit:

Vérifiez si des NetworkPolicy non système sont appliqués à votre cluster:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system

Si la sortie de l'étape précédente n'était pas vide, enregistrez chaque spécification NetworkPolicy dans un fichier afin de pouvoir réappliquer la spécification après avoir mis à jour le cluster.
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
```
Remplacez les éléments suivants :
- NETWORK_POLICY_NAME: nom de l'NetworkPolicy que vous enregistrez.
- NETWORK_POLICY_NAMESPACE: espace de noms du NetworkPolicy.

Supprimez NetworkPolicy à l'aide de la commande suivante:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

Pour migrer vers Dataplane V2, procédez comme suit:

Définissez enableDataplaneV2 sur true dans le fichier de configuration de votre cluster d'utilisateur.

Pour activer Dataplane V2, mettez à jour votre cluster:

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

Si vous avez supprimé des spécifications NetworkPolicy autres que système à une étape précédente, réappliquez-les après la fin de la mise à jour à l'aide de cette commande:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Une fois ces étapes terminées, Dataplane V2 est activé. Ensuite, préparez la migration de votre cluster vers l'équilibreur de charge et Controlplane V2 recommandés.

Préparer la migration de l'équilibreur de charge

Si vos clusters d'utilisateurs utilisent l'équilibreur de charge Seesaw ou F5 BIG-IP intégré, suivez les étapes de cette section pour apporter les modifications nécessaires au fichier de configuration du cluster d'utilisateur. Sinon, passez à la section suivante, Préparer la migration vers Controlplane V2.

F5 BIG-IP

Si vos clusters utilisent la configuration F5 BIG-IP intégrée, préparez la migration vers ManualLB en apportant les modifications suivantes au fichier de configuration du cluster utilisateur:

Remplacez loadBalancer.kind par "ManualLB".
Conservez la même valeur pour le champ loadBalancer.vips.ingressVIP.
Si vous passez à Controlplane V2, remplacez la valeur du champ loadBalancer.vips.controlPlaneVIP par l'adresse IP que vous avez allouée. Sinon, vous pouvez conserver la même valeur.
Supprimez l'intégralité de la section loadBalancer.f5BigIP.

L'exemple de fichier de configuration de cluster d'utilisateur suivant présente ces modifications:

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

Si vos clusters d'utilisateurs utilisent l'équilibreur de charge Seesaw, préparez la migration vers MetalLB en suivant les étapes décrites dans les sections suivantes.

Spécifier des pools d'adresses

Le contrôleur MetalLB gère les adresses IP des services. Ainsi, lorsqu'un développeur d'applications crée un service de type LoadBalancer dans un cluster d'utilisateur, il n'a pas besoin de spécifier manuellement une adresse IP pour le service. À la place, le contrôleur MetalLB choisit une adresse IP d'un pool d'adresses que vous spécifiez.

Tenez compte du nombre maximal de services LoadBalancer susceptibles d'être actifs dans votre cluster d'utilisateur. Dans la section loadBalancer.metalLB.addressPools du fichier de configuration de votre cluster d'utilisateur, spécifiez suffisamment d'adresses IP pour ces services.

Lorsque vous spécifiez des pools d'adresses, incluez l'adresse IP virtuelle d'entrée de votre cluster d'utilisateur dans l'un des pools. Cela est dû au fait que le proxy d'entrée est exposé par un service de type LoadBalancer.

Les adresses doivent être au format CIDR ou au format de plage. Si vous souhaitez spécifier une adresse individuelle, utilisez un masque CIDR /32 tel que 198.51.100.10/32.

Mettre à jour le fichier de configuration du cluster

Mettez à jour le fichier de configuration du cluster pour supprimer la section Seesaw et ajouter une section MetalLB, comme suit:

Définissez loadBalancer.kind sur "MetalLB".
Vous pouvez conserver la même valeur pour le champ loadBalancer.vips.ingressVIP.
Ajoutez l'adresse IP virtuelle d'entrée à un pool d'adresses MetalLB.
Si vous passez à Controlplane V2, remplacez la valeur du champ loadBalancer.vips.controlPlaneVIP par l'adresse IP que vous avez allouée. Sinon, vous pouvez conserver la même valeur.
Supprimez la section loadBalancer.seesaw.
Ajoutez une section loadBalancer.metalLB.

La partie suivante d'un fichier de configuration de cluster d'utilisateur présente ces modifications et la configuration MetalLB de:

Un pool d'adresses parmi lequel le contrôleur MetalLB peut choisir et attribuer des services de type LoadBalancer. L'adresse IP virtuelle d'entrée, qui dans cet exemple est 198.51.100.10, se trouve dans ce pool au format de plage, 198.51.100.10/32.
Adresse IP virtuelle désignée pour le serveur d'API Kubernetes du cluster d'utilisateur.
L'adresse IP virtuelle d'entrée que vous avez configurée pour le proxy d'entrée.
d'un pool de nœuds permettant d'utiliser MetalLB. La migration déploie MetalLB sur les nœuds de ce pool de nœuds.

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
      - name: "address-pool-1"
        addresses:
        - "198.51.100.10/32"
        - "198.51.100.80 - 198.51.100.89"

Préparer la migration vers Controlplane V2

Si Controlplane V2 n'est pas activé sur le cluster:

Mettez à jour le fichier de configuration du cluster utilisateur.
Si le cluster utilise l'équilibrage de charge manuel (loadBalancer.kind: "ManualLB"), mettez également à jour la configuration de votre équilibreur de charge.

Ces étapes sont décrites dans les sections suivantes.

Si Controlplane V2 est déjà activé sur le cluster, passez à la section Migrer le cluster d'utilisateur.

Mettre à jour le fichier de configuration du cluster utilisateur

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

Définissez enableControlplaneV2 sur "true".
Vous pouvez également rendre le plan de contrôle du cluster d'utilisateurs Controlplane V2 disponibilité élevée (HA). Pour passer d'un cluster non haute disponibilité à un cluster haute disponibilité, remplacez la valeur 1 par 3 pour masterNode.replicas.
Ajoutez l'adresse IP statique (ou les adresses IP statiques) des nœuds de plan de contrôle du cluster d'utilisateur à la section network.controlPlaneIPBlock.ips. L'adresse IP (ou les adresses) des nœuds du plan de contrôle doit se trouver dans le même VLAN que les nœuds de calcul.
Remplissez netmask et gateway dans la section network.controlPlaneIPBlock.
Si la section network.hostConfig est vide, remplissez-la.
Assurez-vous que le champ loadBalancer.vips.controlPlaneVIP contient la nouvelle adresse IP pour l'adresse IP virtuelle du plan de contrôle. L'adresse IP doit se trouver dans le même VLAN que les adresses IP des nœuds du plan de contrôle.
Si le cluster d'utilisateurs utilise l'équilibrage de charge manuel, définissez loadBalancer.manualLB.controlPlaneNodePort et loadBalancer.manualLB.konnectivityServerNodePort sur 0. Ils ne sont pas obligatoires lorsque Controlplane V2 est activé, mais ils doivent avoir la valeur 0.
Si le cluster d'utilisateurs utilise l'équilibrage de charge manuel, configurez votre équilibreur de charge comme décrit dans la section suivante.

Ajuster les mappages dans votre équilibreur de charge, si nécessaire

Si votre cluster d'utilisateurs utilise déjà l'équilibrage de charge manuel, vous devez configurer des mappages sur votre équilibreur de charge. Si vous passez de la configuration F5 BIG-IP intégrée à l'équilibrage de charge manuel, vous n'avez pas besoin d'apporter de modifications de configuration à votre équilibreur de charge et pouvez passer à la section suivante, Migrer le cluster d'utilisateur.

Pour chaque adresse IP que vous avez spécifiée dans la section network.controlPlaneIPBlock, configurez les mappages suivants dans votre équilibreur de charge pour les nœuds du plan de contrôle:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPSNodePort)

Ces mappages sont nécessaires pour tous les nœuds du cluster d'utilisateur, à la fois les nœuds du plan de contrôle et les nœuds de calcul. Étant donné que les NodePorts sont configurés sur le cluster, Kubernetes ouvre les NodePorts sur tous les nœuds du cluster afin que n'importe quel nœud du cluster puisse gérer le trafic du plan de données.

Une fois que vous avez configuré les mappages, l'équilibreur de charge écoute le trafic sur l'adresse IP que vous avez configurée pour l'entrée VIP du cluster d'utilisateur sur les ports HTTP et HTTPS standards. L'équilibreur de charge achemine les requêtes vers n'importe quel nœud du cluster. Une fois qu'une requête est acheminée vers l'un des nœuds du cluster, la mise en réseau Kubernetes interne l'achemine vers le pod de destination.

Migrer le cluster d'utilisateur

Commencez par examiner attentivement toutes les modifications que vous avez apportées au fichier de configuration du cluster utilisateur. Tous les paramètres de l'équilibreur de charge et de Controlplane V2 sont immuables, sauf lorsque vous mettez à jour le cluster pour la migration.

Pour mettre à jour le cluster, exécutez la commande suivante:

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

Migration vers Controlplane V2

Lors de la migration vers Controlplane V2, la mise à jour effectue les actions suivantes:

Crée le plan de contrôle d'un nouveau cluster avec ControlPlane V2 activé.
Arrête le plan de contrôle Kubernetes du cluster kubeception.
Prend un instantané etcd du cluster kubeception.
Désactive les nœuds du plan de contrôle du cluster d'utilisateur du cluster kubeception. Tant que la migration n'est pas terminée, les nœuds ne sont pas supprimés, car cela permet de récupérer en cas d'échec en revenant à ce cluster kubeception.
Restaure les données du cluster dans le nouveau plan de contrôle à l'aide de l'instantané etcd créé à une étape précédente.
Connecte les nœuds du pool de nœuds du cluster kubeception au nouveau plan de contrôle, accessible avec le nouveau controlPlaneVIP.
Consolide le cluster d'utilisateur restauré pour qu'il corresponde à l'état final du cluster avec ControlPlane V2 activé.

Veuillez noter les points suivants :

Pendant la migration, il n'y a pas d'interruption de service pour les charges de travail du cluster utilisateur.
Le plan de contrôle du cluster d'utilisateur est indisponible pendant quelques minutes pendant la migration. Plus précisément, le plan de contrôle est indisponible entre l'arrêt du plan de contrôle Kubernetes du cluster kubeception et la fin de la connexion des nœuds du pool de nœuds du cluster kubeception au nouveau plan de contrôle. (Lors des tests, ce temps d'arrêt était inférieur à sept minutes, mais la 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 est défini sur "static" dans le cluster d'administration, vous pouvez recycler certaines des adresses IP statiques inutilisées. Vous pouvez lister les objets de nœud du cluster d'administration avec kubectl get nodes -o wide pour voir quelles adresses IP sont utilisées. Pour recycler ces adresses IP, supprimez-les du fichier de configuration du cluster d'administrateur, puis exécutez gkectl update admin.

Après la migration

Une fois la mise à jour terminée, procédez comme suit:

Vérifiez que votre cluster d'utilisateur est en cours d'exécution :

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Le résultat ressemble à ce qui suit :

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

Si vous avez migré vers Controlplane V2, mettez à jour les règles de pare-feu de votre cluster d'administration pour supprimer les nœuds du plan de contrôle du cluster d'utilisateur kubeception.
Si vous avez désactivé le chiffrement permanent des secrets, réactivez la fonctionnalité.
1. Dans le fichier de configuration du cluster d'utilisateur, supprimez le champ disabled: true.
2. Mettez à jour le cluster d'utilisateur :
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Si vous avez désactivé la réparation automatique dans le cluster d'administrateur, réactivez-la.
1. Dans votre fichier de configuration de cluster d'administrateur, définissez autoRepair.enabled sur true.
2. Mettez à jour le cluster :
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG
```

Migration de l'équilibreur de charge

Si vous avez migré l'équilibreur de charge, vérifiez que ses composants s'exécutent correctement.

Migration MetalLB

Si vous avez migré vers MetalLB, vérifiez que les composants MetalLB fonctionnent correctement:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

Le résultat affiche les pods du contrôleur et du speaker MetalLB. Exemple :

metallb-controller-744884bf7b-rznr9   1/1     Running
metallb-speaker-6n8ws                 1/1     Running
metallb-speaker-nb52z                 1/1     Running
metallb-speaker-rq4pp                 1/1     Running

Une fois la migration terminée, supprimez les VM Seesaw éteintes pour le cluster utilisateur. Vous trouverez les noms des VM Seesaw dans la section vmnames du fichier seesaw-for-[USERCLUSTERNAME].yaml dans votre répertoire de configuration.

Migration F5 BIG-IP

Une fois la migration vers l'équilibrage de charge manuel effectuée, le trafic vers vos clusters n'est pas interrompu. En effet, les ressources F5 existantes sont toujours là, comme vous pouvez le voir en exécutant la commande suivante:

kubectl --kubeconfig CLUSTER_KUBECONFIG \
api-resources --verbs=list -o name | xargs -n 1 kubectl --kubeconfig
CLUSTER_KUBECONFIG get --show-kind --ignore-not-found
--selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

Le résultat ressemble à ce qui suit :


Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z