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 à d'autres options d'équilibrage de charge.

Migration des clusters 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 à jour le cluster:

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 les connexions réseau à toutes les adresses IP virtuelles du cluster d'utilisateur pour les services Kubernetes de type LoadBalancer pendant deux à dix minutes. Une fois la migration terminée, les connexions sont à nouveau fonctionnelles.

Après une migration réussie, supprimez manuellement les VM Seesaw, 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 soient 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, pour les 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 pas d'adresses IP statiques pour ses nœuds de cluster. 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, pour les 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 disposiez d'un cluster d'utilisateur sur lequel le plan de contrôle V2 est activé et qui utilise le protocole DHCP pour ses nœuds de calcul. Supposons également que le cluster comporte deux services de type LoadBalancer et que les adresses externes de ces services soient 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 il utilisera des adresses IP statiques 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, pour les 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 et 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 interrompt les connexions réseau à toutes les adresses IP virtuelles dans le cluster d'administrateur des services Kubernetes de type LoadBalancer pendant deux à dix minutes. Une fois la migration terminée, les connexions sont à nouveau fonctionnelles.

Après une migration réussie, supprimez manuellement les VM Seesaw, déjà éteintes, pour le 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 disposiez d'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 pas d'adresses IP statiques pour ses nœuds de cluster. 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 sous tension les VM Seesaw du cluster d'utilisateur. Le trafic vers les adresses IP virtuelles actuellement utilisées sera rétabli. 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 d'administrateur sous tension. Cela peut permettre au trafic vers les adresses IP virtuelles du plan de contrôle actuellement utilisées pour les clusters d'utilisateur de fonctionner à 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 du plan de contrôle du cluster d'administrateur.

Dans l'espace de noms kube-system, remplacez également le type de service kube-apiserver ClusterIP par LoadBalancer. Si nécessaire, créez une demande d'assistance.