Migrer de l'équilibreur de charge Seesaw vers MetalLB

Ce document explique comment migrer de l'équilibreur de charge Seesaw vers l'équilibreur de charge MetalLB.

L'utilisation de MetalLB présente plusieurs avantages par rapport aux autres options d'équilibrage de charge.

Migration du cluster d'utilisateur

Dans le fichier de configuration de votre cluster d'utilisateur, choisissez un pool de nœuds et définissez enableLoadBalancer sur true:

nodePools:
- name: pool-1
  replicas: 3
  enableLoadBalancer: 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 du fichier kubeconfig du cluster d'administrateur

• USER_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'utilisateur

Supprimez ensuite les sections Seesaw du fichier et ajoutez une section MetalLB.

Ensuite, mettez à nouveau le cluster à jour:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Vérifiez que les composants Metallb s'exécutent correctement:

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

La sortie affiche les pods du contrôleur et du haut-parleur 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

Important :Le processus de migration interrompt pendant deux à dix minutes les connexions réseau à toutes les adresses IP virtuelles du cluster d'utilisateur pour les services Kubernetes de type LoadBalancer. Une fois la migration terminée, les connexions fonctionneront de nouveau.

Après une migration réussie, supprimez manuellement les VM Seesaw, qui sont déjà éteintes, pour le cluster d'utilisateur. Vous trouverez les noms des VM Seesaw dans la section vmnames du fichier seesaw-for-[USERCLUSTERNAME].yaml de votre répertoire de configuration.

Exemple: cluster d'utilisateur, adresses IP statiques

Supposons que vous ayez un cluster d'utilisateur qui utilise des adresses IP statiques pour ses nœuds de cluster. Supposons également que le cluster comporte deux services de type LoadBalancer, et que les adresses externes de ces services sont 172.16.21.41 et 172.16.21.45.

Ajustez le fichier de configuration du cluster d'utilisateur comme suit:

• Conservez la section network.hostConfig.
• Définissez loadBalancer.kind sur MetalLB.
• Supprimez la section loadBalancer.seesaw.
• Ajoutez une section loadBalancer.metalLB.

Exemple :

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
    ingressVIP: "172.16.20.31"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.31/32"
      - "172.16.20.40 - 172.16.21.49"
  

Points clés de l'exemple précédent:

• Même si le cluster n'utilise plus l'équilibreur de charge Seesaw, la section network.hostConfig est nécessaire, car les nœuds du cluster utilisent des adresses IP statiques.

• La valeur de ingressVIP apparaît dans le pool d'adresses MetalLB.

• Les adresses IP externes, 172.16.21.41 et 172.16.21.45, des services existants de type LoadBalancer sont incluses dans le pool d'adresses MetalLB.

Exemple: cluster d'utilisateur kubeception, DHCP

Supposons que vous ayez un cluster d'utilisateur qui utilise DHCP pour ses nœuds de cluster. Supposons également que le cluster comporte deux services de type LoadBalancer, et que les adresses externes de ces services soient 172.16.21.61 et 172.16.21.65.

Ajustez le fichier de configuration du cluster d'utilisateur comme suit:

• Supprimez la section network.hostConfig.
• Définissez loadBalancer.kind sur MetalLB.
• Supprimez la section loadBalancer.seesaw.
• Ajoutez une section loadBalancer.metalLB.

Exemple :

enableControlplaneV2: false
network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.50"
    ingressVIP: "172.16.20.51"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.51/32"
      - "172.16.20.60 - 172.16.21.69"
  

Points clés de l'exemple précédent:

• Le cluster n'utilise plus l'équilibreur de charge Seesaw et n'utilise plus d'adresses IP statiques pour ses nœuds. La section network.hostConfig n'est donc pas nécessaire.

• La valeur de ingressVIP apparaît dans le pool d'adresses MetalLB.

• Les adresses IP externes, 172.16.21.61 et 172.16.21.65, des services existants de type LoadBalancer sont incluses dans le pool d'adresses MetalLB.

Exemple: cluster d'utilisateur du plan de contrôle V2, DHCP

Supposons que vous ayez un cluster d'utilisateur sur lequel Controlplane V2 est activé et sur lequel ses nœuds de calcul utilisent DHCP. Supposons également que le cluster comporte deux services de type LoadBalancer, et que les adresses externes de ces services sont 172.16.21.81 et 172.16.21.85.

Ajustez le fichier de configuration du cluster d'utilisateur comme suit:

• Conservez la section network.hostconfig.
• Définissez loadBalancer.kind sur MetalLB.
• Supprimez la section loadBalancer.seesaw.
• Ajoutez une section loadBalancer.metalLB.

Exemple :

enableControlplaneV2: true
network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.70"
    ingressVIP: "172.16.20.71"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
      - "172.16.20.71/32"
      - "172.16.20.80 - 172.16.21.89"
  

Points clés de l'exemple précédent:

• Le cluster n'utilisera plus d'adresses IP statiques pour les nœuds de calcul, mais pour les nœuds du plan de contrôle. La section network.hostConfig est donc nécessaire.

• La valeur de ingressVIP apparaît dans le pool d'adresses MetalLB.

• Les adresses IP externes, 172.16.21.81 et 172.16.21.85, des services existants de type LoadBalancer sont incluses dans le pool d'adresses MetalLB.

Migration du cluster d'administrateur

Dans le fichier de configuration de votre cluster d'administrateur, définissez loadBalancer.kind sur MetalLB, puis supprimez la section loadBalancer.seesaw.

Mettez à jour le cluster :

gkectl update admin --kubeconfig  ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Remplacez les éléments suivants :

• ADMIN_CLUSTER_KUBECONFIG : chemin d'accès du fichier kubeconfig du cluster d'administrateur

• ADMIN_CLUSTER_CONFIG : chemin d'accès au fichier de configuration du cluster d'administrateur

Vérifiez que les composants Metallb s'exécutent correctement:

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

La sortie affiche les pods du contrôleur et du haut-parleur 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

Important :Le processus de migration arrêtera les connexions réseau à toutes les adresses IP virtuelles dans le cluster d'administrateur pour les services Kubernetes de type LoadBalancer pendant deux à dix minutes. Une fois la migration terminée, les connexions fonctionneront de nouveau.

Après une migration réussie, supprimez manuellement les VM Seesaw, qui sont déjà éteintes, du cluster d'administrateur. Vous trouverez les noms des VM Seesaw dans la section vmnames du fichier seesaw-for-gke-admin.yaml de votre répertoire de configuration.

Exemple: cluster d'administrateur, adresses IP statiques

Supposons que vous ayez un cluster d'administrateur qui utilise des adresses IP statiques pour ses nœuds de cluster.

Ajustez le fichier de configuration du cluster d'administrateur comme suit:

• Conservez la section network.hostConfig.
• Définissez loadBalancer.kind sur MetalLB.
• Supprimez la section loadBalancer.seesaw.

Exemple :

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  

Point clé de l'exemple précédent:

• Même si le cluster n'utilise plus l'équilibreur de charge Seesaw, la section network.hostConfig est nécessaire, car les nœuds du cluster utilisent des adresses IP statiques.

Exemple: cluster d'administrateur, DHCP

Supposons que vous ayez un cluster d'administrateur qui utilise DHCP pour ses nœuds de cluster.

Ajustez le fichier de configuration du cluster d'administrateur comme suit:

• Supprimez la section network.hostConfig.
• Définissez loadBalancer.kind sur MetalLB.
• Supprimez la section loadBalancer.seesaw.

Exemple :

network:
  hostConfig:
    dnsServers:
    - "172.16.255.1"
    - "172.16.255.2"
    ntpServers:
    - "216.239.35.0"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.20.30"
  kind: MetalLB Seesaw
  seesaw:
    ipBlockFilePath: "user-cluster-1-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  

Point clé de l'exemple précédent:

• Le cluster n'utilise plus l'équilibreur de charge Seesaw et n'utilise plus d'adresses IP statiques pour ses nœuds. La section network.hostConfig n'est donc pas nécessaire.

Dépannage

Si gkectl update échoue lors de la migration du cluster d'utilisateur et que les pods Metallb ne s'exécutent pas dans le cluster d'utilisateur, mettez manuellement les VM Seesaw du cluster sous tension. Le trafic sera rétabli vers les adresses IP virtuelles actuellement utilisées. Toutefois, les adresses IP virtuelles nouvellement créées peuvent ne pas être diffusées par les VM Seesaw si le pod load-balancer-seesaw n'est pas en cours d'exécution. Dans ce cas, créez une demande d'assistance.

Si gkectl update échoue lors de la migration du cluster d'administrateur et que les pods Metallb ne s'exécutent pas dans le cluster d'administrateur, mettez manuellement les VM Seesaw du cluster sous tension. Cela peut permettre au trafic vers les adresses IP virtuelles du plan de contrôle actuellement utilisées pour que les clusters d'utilisateur fonctionnent à nouveau. Toutefois, l'adresse IP virtuelle du plan de contrôle du cluster d'administrateur lui-même peut ne pas fonctionner. Dans ce cas, modifiez le fichier kubeconfig du cluster d'administrateur pour utiliser directement l'adresse IP du nœud de plan de contrôle du cluster d'administrateur.

Toujours dans l'espace de noms kube-system, modifiez le type de service kube-apiserver en remplaçant ClusterIP par LoadBalancer. Si nécessaire, créez une demande d'assistance.