Ce document explique comment migrer de l'équilibreur de charge Seesaw à 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
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
surMetalLB
. - 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: MetalLBSeesawseesaw: ipBlockFilePath: "user-cluster-1-ipblock.yaml" vrid: 1 masterIP: "" cpus: 4 memoryMB: 3072metalLB: 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
surMetalLB
. - 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: MetalLBSeesawseesaw: ipBlockFilePath: "user-cluster-2-ipblock.yaml" vrid: 1 masterIP: "" cpus: 4 memoryMB: 3072metalLB: 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
surMetalLB
. - 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: MetalLBSeesawseesaw: ipBlockFilePath: "user-cluster-2-ipblock.yaml" vrid: 1 masterIP: "" cpus: 4 memoryMB: 3072metalLB: 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
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
surMetalLB
. - 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: MetalLBSeesawseesaw: 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
surMetalLB
. - 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: MetalLBSeesawseesaw: 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.