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

Présentation

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

• La configuration de l'équilibreur de charge:

  • La configuration de l'équilibreur de charge F5 BIG-IP intégré à ManualLB.

    ou

  • Équilibreur de charge Seesaw groupé à MetalLB.

• Migrer vers un cluster d'administrateur haute disponibilité (HD) à partir d'un cluster d'administrateur standard La disponibilité est considérablement améliorée avec un cluster d'administrateur HD tout en utilisant le même nombre de VM. Un cluster d'administrateur standard comporte un nœud de plan de contrôle et deux nœuds complémentaires. Les trois nœuds d'un cluster d'administrateur HD sont tous des nœuds de plan de contrôle sans nœuds de module complémentaire.

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.

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

Bonnes pratiques

Si vous disposez de plusieurs environnements (test, développement et production, par exemple), nous vous recommandons de commencer par migrer l'environnement le moins critique, comme 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.

Conditions requises

• Le cluster d'administrateur doit être à la version 1.30 ou ultérieure.
• Tous les clusters d'utilisateurs gérés par le cluster d'administrateur doivent déjà avoir été migrés vers les fonctionnalités recommandées, comme décrit dans la section Migrer un cluster d'utilisateurs vers les fonctionnalités recommandées.

Planifier les temps d'arrêt pendant la migration

Pour la migration, prévoyez un temps d'arrêt limité du plan de contrôle. L'accès à l'API Kubernetes est indisponible pendant environ 20 minutes pour les clusters d'administrateur non HD, mais le plan de contrôle Kubernetes reste disponible pour les clusters d'administrateur HD avec F5. Lors des migrations, le plan de données Kubernetes continue de fonctionner dans un état stable.

Remarque : Les charges de travail utilisateur ne doivent s'exécuter que dans les clusters d'utilisateur, qui ne sont pas affectés par la migration des clusters d'administrateur.

De	Vers	Accès aux API Kubernetes	Charges de travail de l'utilisateur
Clusters d'administrateurs HD avec F5 BIG-IP	Clusters d'administrateurs HD avec ManualLB	Non affecté	Non affecté
Clusters d'administrateurs non HD avec MetalLB ou ManualLB	Clusters d'administrateurs HD avec le même type d'équilibreur de charge	Affecté	Non affecté
Clusters d'administrateurs non HD avec F5 BIG-IP	Clusters d'administrateurs HD avec ManualLB	Affecté	Non affecté
Clusters d'administrateurs sans HD avec Seesaw	Clusters d'administrateurs HD avec MetalLB	Affecté	Non 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

Si votre cluster d'administrateur n'est pas haute disponibilité, préparez-vous à migrer vers un cluster d'administrateur haute disponibilité en suivant les étapes décrites dans cette section. Si votre cluster d'administrateur est déjà hautement disponible, passez à la section suivante, Préparer la migration de l'équilibreur de charge.

Allouer des adresses IP supplémentaires

Lorsque vous migrez le cluster d'administrateur d'un état non HD à un état HD, allouez quatre adresses IP supplémentaires. Assurez-vous que ces adresses IP se trouvent dans le même VLAN que les nœuds du cluster d'administrateur existants et qu'elles ne sont pas déjà utilisées par des nœuds existants:

• Attribuez une adresse IP à la nouvelle adresse IP virtuelle du plan de contrôle, pour le champ loadBalancer.vips.controlPlaneVIP dans le fichier de configuration du cluster d'administrateur.
• Attribuez une nouvelle adresse IP à chacun des trois nœuds du plan de contrôle, pour la section network.controlPlaneIPBlock du fichier de configuration du cluster d'administrateur.

Mettre à jour les règles de pare-feu

Lorsque vous migrez le cluster d'administrateur d'un état non HD à un état HD, mettez à jour les règles de pare-feu sur votre cluster d'administrateur. Cela garantit que les nouvelles adresses IP attribuées aux nœuds du plan de contrôle peuvent atteindre toutes les API et autres destinations requises, comme décrit dans la section Règles de pare-feu pour les clusters d'administrateur.

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

Si votre cluster d'administrateur utilise la configuration F5 BIG-IP intégrée ou l'équilibreur de charge Seesaw fourni, suivez les étapes de cette section pour apporter les modifications nécessaires au fichier de configuration du cluster d'administrateur. Sinon, passez à la section suivante, Préparer la migration d'un environnement non HD vers un environnement HD.

F5 BIG-IP

Si votre cluster d'administrateur utilise la configuration F5 BIG-IP intégrée, apportez les modifications suivantes au fichier de configuration du cluster d'administrateur :

1. Définissez le champ loadBalancer.kind sur "ManualLB".
2. Définissez ou conservez la valeur du champ loadBalancer.vips.controlPlaneVIP. Si votre cluster d'administrateur est déjà hautement disponible, conservez la même valeur. Si vous passez d'un cluster d'administrateur non haute disponibilité à un cluster d'administrateur haute disponibilité, remplacez la valeur du champ loadBalancer.vips.controlPlaneVIP par l'adresse IP que vous avez allouée.
3. Supprimez l'intégralité de la section loadBalancer.f5BigIP.

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

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "F5BigIP" "ManualLB"
f5BigIP:
    address: "203.0.113.20"
  credentials:
    fileRef:
      path: ""my-config-folder/user-creds.yaml"
      entry: "f5-creds"
  partition: "my-f5-user-partition"
  

Seesaw

Si votre cluster d'administrateur utilise l'équilibreur de charge Seesaw, apportez les modifications suivantes au fichier de configuration du cluster d'administrateur :

1. Définissez le champ loadBalancer.kind sur "MetalLB".
2. Conservez la section network.hostConfig.
3. Définissez ou conservez la valeur du champ loadBalancer.vips.controlPlaneVIP]5. Si votre cluster d'administrateur est déjà hautement disponible, vous pouvez conserver la même valeur. Si vous passez d'un cluster d'administrateur non HD à un cluster d'administrateur HD, remplacez la valeur du champ loadBalancer.vips.controlPlaneVIP par l'adresse IP que vous avez allouée.
4. Supprimez la section loadBalancer.seesaw.

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

network:
hostConfig:
  dnsServers:
  - "203.0.113.1"
  - "203.0.113.2"
  ntpServers:
  - "203.0.113.3"
loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
kind: "MetalLB" "Seesaw"
seesaw:
  ipBlockFilePath: "user-cluster-1-ipblock.yaml"
  vrid: 1
  masterIP: ""
  cpus: 4
  memoryMB: 3072

Préparer la migration d'un environnement non HD vers un environnement HD

Si votre cluster d'administrateur n'est pas haute disponibilité, préparez-vous à migrer vers la haute disponibilité en suivant les étapes de cette section.

Si votre cluster d'administrateur est déjà haute disponibilité, passez à la section suivante, Migrer le cluster d'administrateur.

Si la version de votre cluster d'administrateur est 1.29.0-1.29.600 ou 1.30.0-1.30.100, et si le chiffrement permanent des secrets était activé dans le cluster d'administrateur à la version 1.14 ou antérieure, vous devez changer la clé de chiffrement avant de commencer la migration. Sinon, le nouveau cluster d'administrateur HD ne pourra pas déchiffrer les secrets.

Pour vérifier si le cluster utilise une ancienne clé de chiffrement:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

Si la sortie affiche une clé vide, comme dans l'exemple suivant, vous devez effectuer une rotation de la clé de chiffrement en suivant les étapes de cet problème connu.

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Avertissement :Si vous avez commencé la migration sans effectuer de rotation de la clé de chiffrement, contactez l'assistance Google.

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

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

1. Remplacez network.controlPlaneIPBlock par les trois adresses IP que vous avez allouées aux nœuds du plan de contrôle.
2. Assurez-vous d'avoir rempli la section network.hostConfig. Cette section contient des informations sur les serveurs NTP, les serveurs DNS et les domaines de recherche DNS utilisés par les VM qui sont vos nœuds de cluster.
3. Assurez-vous d'avoir remplacé la valeur de loadBalancer.vips.controlPlaneVIP par l'adresse IP que vous avez attribuée.
4. Définissez adminMaster.replicas sur 3.
5. Supprimez le champ vCenter.dataDisk. Pour un cluster d'administration HD, les chemins d'accès aux trois disques de données utilisés par les nœuds du plan de contrôle sont générés automatiquement sous le répertoire racine anthos dans le datastore.
6. Si loadBalancer.kind est défini sur "ManualLB", définissez loadBalancer.manualLB.controlPlaneNodePort sur 0.

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

vCenter:
  address: "my-vcenter-server.my-domain.example"
  datacenter: "my-data-center"
  dataDisk: "xxxx.vmdk"
...
network:
  hostConfig:
    dnsServers:
    - 203.0.113.1
    - 203.0.113.2
    ntpServers:
    - 203.0.113.3
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "198.51.100.1"
    ips:
    - ip: "192.0.2.1"
      hostname: "admin-cp-hostname-1"
    - ip: "192.0.2.2"
      hostname: "admin-cp-hostname-2"
    - ip: "192.0.2.3"
      hostname: "admin-cp-hostname-3"
...

...
loadBalancer:
  vips:
    controlPlaneVIP: 192.0.2.6 192.0.2.50
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 30003 0

...
adminMaster:
  replicas: 3
  cpus: 4
  memoryMB: 8192
...

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

Si votre cluster d'administrateur utilise l'équilibrage de charge manuel, suivez la procédure décrite dans cette section.

Si vous passez de l'équilibrage de charge F5 BIG-IP intégré à l'équilibrage de charge manuel ou si vous passez à MetalLB, passez à la section suivante, Migrer le cluster d'administrateur.

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, configurez ce mappage dans votre équilibreur de charge externe (tel que F5 BIG-IP ou Citrix):

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)

Cela garantit que l'ancienne adresse IP virtuelle du plan de contrôle continue de fonctionner pendant la migration.

Migrer le cluster d'administrateur

Examinez attentivement toutes les modifications que vous avez apportées au fichier de configuration du cluster d'administrateur. Tous les paramètres sont immuables, sauf lors de la mise à jour du cluster pour la migration.

Mettez à jour le cluster :

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

Replace the following:

• 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

La commande affiche la progression de la migration.

Lorsque vous y êtes invité, saisissez Y pour continuer.

Lors de la migration d'un cluster standard vers un cluster à haute disponibilité, l'ancienne adresse IP virtuelle du plan de contrôle continue de fonctionner et peut être utilisé pour accéder au nouveau cluster d'administrateur à haute disponibilité. Une fois la migration terminée, le fichier kubeconfig du cluster administrateur est automatiquement mis à jour pour utiliser la nouvelle adresse IP virtuelle du plan de contrôle.

Après la migration

Une fois la mise à jour terminée, vérifiez que le cluster d'administrateur est en cours d'exécution :

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Le résultat ressemble à ce qui suit :

Migration de l'équilibreur de charge

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

MetalLB

Si vous avez migré vers MetalLB, vérifiez que les composants MetalLB s'exécutent correctement à l'aide de la commande suivante:

kubectl --kubeconfig ADMIN_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 d'administrateur. Vous trouverez les noms des VM Seesaw dans la section vmnames du fichier seesaw-for-gke-admin.yaml dans votre répertoire de configuration.

ManualLB

Une fois que vous avez mis à jour vos clusters pour utiliser l'équilibrage de charge manuel, 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 ADMIN_CLUSTER_KUBECONFIG \

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-xt697x   Opaque   4      13h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         13h
kube-system   serviceaccount/load-balancer-f5   0         13h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           13h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           13h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   13h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T04:37:34Z