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 pour les versions 1.16 à 1.29. Si vos clusters sont à la version 1.30 ou supérieure, nous vous recommandons de suivre les instructions de la section Planifier la migration du cluster vers les fonctionnalités recommandées.

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

1.28 et 1.29: version GA
1.16: version preview

Avertissement : Ne migrez pas vers MetalLB si vous utilisez Seesaw pour la conservation des adresses IP des clients. Plus précisément, ne migrez pas vers MetalLB si le cluster contient des services dont la valeur de spec.externalTrafficPolicy est définie sur Local.

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

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

Contactez l'assistance Google pour obtenir de l'aide.

Remarques sur les temps d'arrêt

La charge de travail est interrompue pendant la migration. Les remarques suivantes ne s'appliquent qu'aux clusters d'administrateur standard, car l'équilibreur de charge SeeSaw n'est pas compatible avec les clusters d'administrateur HA.

• Lors de la migration d'un cluster d'administrateur:

  • Le plan de contrôle est indisponible pour les clusters d'utilisateur kubeception pendant la migration de controlPlaneVIP. L'indisponibilité devrait être inférieure à 10 minutes, mais sa durée dépend de votre infrastructure.

  • Le plan de contrôle du cluster d'administrateur est indisponible, car le nœud principal d'administration doit être recréé avec le controlPlaneVIP directement associé à la VM. L'indisponibilité devrait être inférieure à 20 minutes, mais sa durée dépend de votre infrastructure.

• Lors de la migration d'un cluster d'utilisateur, les adresses IP virtuelles sont interrompues après l'arrêt de l'équilibreur de charge Seesaw et avant l'activation des pods MetalLB. Ce processus prend généralement une minute.

Migration des clusters d'utilisateurs

Vous devez choisir un pool de nœuds et l'activer pour l'utiliser avec MetalLB. MetalLB sera déployé sur les nœuds de ce pool de nœuds.

Avertissement : Assurez-vous que le pool de nœuds que vous activez pour MetalLB n'inclut pas l'adresse IP d'un service avec un volume d'entrée NAT (traduction d'adresse réseau) élevé. Cela pourrait entraîner une pénurie de mémoire pour vos charges de travail. Utilisez plutôt un autre pool de nœuds existant ou créez un pool de nœuds à utiliser pour MetalLB.

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

Ensuite, supprimez les sections Seesaw du fichier et ajoutez une section MetalLB.

Mettez ensuite à 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 pour le contrôleur et l'orateur 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 VIP du cluster utilisateur pour les services Kubernetes de type LoadBalancer pendant deux à dix minutes. Une fois la migration terminée, les connexions fonctionneront à nouveau.

Une fois la migration terminée, supprimez manuellement les VM Seesaw, qui sont déjà éteintes, pour le cluster d'utilisateurs. 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'utilisateurs, adresses IP statiques

Supposons que vous disposiez d'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 utilisateur comme suit:

• Conservez la section network.hostConfig.
• Définissez loadBalancer.kind sur MetalLB.
• Supprimez la section loadBalancer.seesaw.
• Ajouter 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'utilisera plus l'équilibreur de charge Seesaw, la section network.hostConfig est nécessaire, car les nœuds de 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 disposiez d'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 sont 172.16.21.61 et 172.16.21.65.

Ajustez le fichier de configuration du cluster utilisateur comme suit:

• Supprimez la section network.hostConfig.
• Définissez loadBalancer.kind sur MetalLB.
• Supprimez la section loadBalancer.seesaw.
• Ajouter 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'utilisera plus l'équilibreur de charge Seesaw, et n'utilisera pas 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, pour les services existants de type LoadBalancer, sont incluses dans le pool d'adresses MetalLB.

Exemple: cluster d'utilisateur Controlplane V2, DHCP

Supposons que vous disposiez d'un cluster d'utilisateur pour lequel Controlplane V2 est activé et qui utilise DHCP pour ses nœuds de calcul. Supposons également que le cluster dispose de 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 utilisateur comme suit:

• Conservez la section network.hostconfig.
• Définissez loadBalancer.kind sur MetalLB.
• Supprimez la section loadBalancer.seesaw.
• Ajouter 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 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 votre fichier de configuration de 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 pour le contrôleur et l'orateur 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 interrompra les connexions réseau à toutes les adresses IP virtuelles du cluster d'administration pour les services Kubernetes de type LoadBalancer pendant deux à dix minutes. Une fois la migration terminée, les connexions fonctionneront à nouveau.

Une fois la migration terminée, supprimez manuellement les VM Seesaw, qui sont 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'utilisera plus l'équilibreur de charge Seesaw, la section network.hostConfig est nécessaire, car les nœuds de cluster utilisent des adresses IP statiques.

Exemple: cluster d'administrateur, DHCP

Supposons que vous disposiez d'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'utilisera plus l'équilibreur de charge Seesaw, et n'utilisera pas 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 VIP actuellement utilisés. Toutefois, les VIP nouvellement créés peuvent ne pas être diffusés par les VM Seesaw si le pod load-balancer-seesaw n'est pas en cours d'exécution. Si c'est le 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 VIP du plan de contrôle actuellement utilisés pour les clusters d'utilisateur de fonctionner à nouveau. Toutefois, l'adresse IP virtuelle du plan de contrôle du cluster d'administrateur 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 de ClusterIP par LoadBalancer. Si nécessaire, créez une demande d'assistance.