Effectuer une migration de l'équilibreur de charge Seesaw vers MetalLB

Version 1.28 

• Dernière version
• Version 1.16
• Versions antérieures (non compatibles)

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 du cluster d'utilisateur

Dans le fichier de configuration de votre cluster d'utilisateur, choisissez un pool de nœuds, puis 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, puis 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 fonctionnent 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, 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 votre cluster d'utilisateur 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, DHCP

Supposons que votre cluster d'utilisateur utilise le protocole DHCP pour ses nœuds. Supposons également que le cluster comporte deux services de type LoadBalancer et que les adresses externes de ces services sont 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 :

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 il 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.

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 fonctionnent 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 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'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 disposez 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 disposez d'un cluster d'administrateur qui utilise le protocole 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 il 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, allumez manuellement les VM Seesaw du cluster d'utilisateur. 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, allumez manuellement les VM Seesaw du cluster d'administrateur. Cela peut permettre au trafic vers les adresses IP virtuelles du plan de contrôle actuellement utilisées pour que les clusters d'utilisateur puissent à nouveau fonctionner. 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.

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