Migrar do balanceador de carga do Seesaw para o MetalLB

Neste documento, mostramos como migrar do balanceador de carga do Seesaw para o do MetalLB.

O MetalLB oferece vários benefícios em comparação com outras opções de balanceamento de carga.

Migração de cluster de usuário

No arquivo de configuração do cluster de usuário, escolha um pool de nós e defina enableLoadBalancer como true:

nodePools:
- name: pool-1
  replicas: 3
  enableLoadBalancer: true

Atualize o cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Substitua:

  • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador

  • USER_CLUSTER_CONFIG: é o caminho do arquivo de configuração do cluster de usuário

Depois, remova as seções do Seesaw do arquivo e adicione uma seção do MetalLB.

Em seguida, atualize o cluster de novo:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Verifique se os componentes metallb estão sendo executados corretamente: 

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

A saída mostra pods do controlador e alto-falante do MetalLB. Exemplo:

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

Após a migração, exclua manualmente as VMs do Seesaw desativadas do cluster de usuário. É possível encontrar os nomes de VMs do Seesaw na seção vmnames do arquivo seesaw-for-[USERCLUSTERNAME].yaml no diretório de configuração.

Exemplo: cluster de usuário, endereços IP estáticos

Suponha que você tenha um cluster de usuário que use endereços IP estáticos para os nós do cluster. Suponha também que o cluster tenha dois Serviços do tipo LoadBalancer e os endereços externos desses serviços sejam 172.16.21.41 e 172.16.21.45.

Ajuste o arquivo de configuração do cluster de usuário da seguinte maneira:

  • Mantenha a seção network.hostConfig.
  • Defina loadBalancer.kind como MetalLB.
  • Remova a seção loadBalancer.seesaw.
  • Adicione uma seção loadBalancer.metalLB.

Exemplo:

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"

Pontos principais do exemplo anterior:

  • Mesmo que o cluster não use mais o balanceador de carga do Seesaw, a seção network.hostConfig é necessária porque os nós do cluster usam endereços IP estáticos.

  • O valor de ingressVIP aparece no pool de endereços do MetalLB.

  • Os endereços IP externos, 172.16.21.41 e 172.16.21.45, dos Serviços atuais do tipo LoadBalancer estão incluídos no pool de endereços do MetalLB.

Exemplo: cluster de usuário, DHCP

Suponha que você tenha um cluster de usuário que use DHCP para os nós do cluster. Suponha também que o cluster tenha dois Serviços do tipo LoadBalancer e os endereços externos desses serviços sejam 172.16.21.61 e 172.16.21.65.

Ajuste o arquivo de configuração do cluster de usuário da seguinte maneira:

  • Remova a seção network.hostConfig.
  • Defina loadBalancer.kind como MetalLB.
  • Remova a seção loadBalancer.seesaw.
  • Adicione uma seção loadBalancer.metalLB.

Exemplo:

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"

Pontos principais do exemplo anterior:

  • O cluster não vai mais usar o balanceador de carga do Seesaw, e o cluster não vai usar endereços IP estáticos para os nós do cluster. Portanto, a seção network.hostConfig não será necessária.

  • O valor de ingressVIP aparece no pool de endereços do MetalLB.

  • Os endereços IP externos, 172.16.21.61 e 172.16.21.65, dos Serviços atuais do tipo LoadBalancer estão incluídos no pool de endereços do MetalLB.

Migração de cluster de administrador

No arquivo de configuração do cluster de administrador, defina loadBalancer.kind como MetalLB e remova a seção loadBalancer.seesaw.

Atualize o cluster:

gkectl update admin --kubeconfig  ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Substitua:

  • ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador

  • ADMIN_CLUSTER_CONFIG: é o caminho do arquivo de configuração do cluster de administrador

Verifique se os componentes metallb estão sendo executados corretamente: 

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

A saída mostra pods do controlador e alto-falante do MetalLB. Exemplo:

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

Após a migração, exclua manualmente as VMs do Seesaw desativadas do cluster de administrador. É possível encontrar os nomes de VMs do Seesaw na seção vmnames do arquivo seesaw-for-gke-admin.yaml no diretório de configuração.

Exemplo: cluster de administrador, endereços IP estáticos

Suponha que você tenha um cluster de administrador que use endereços IP estáticos para os nós do cluster.

Ajuste o arquivo de configuração do cluster de administrador da seguinte maneira:

  • Mantenha a seção network.hostConfig.
  • Defina loadBalancer.kind como MetalLB.
  • Remova a seção loadBalancer.seesaw.

Exemplo:

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

Ponto principal do exemplo anterior:

  • Mesmo que o cluster não use mais o balanceador de carga do Seesaw, a seção network.hostConfig é necessária porque os nós do cluster usam endereços IP estáticos.

Exemplo: cluster de administrador, DHCP

Suponha que você tenha um cluster de administrador que use DHCP para os nós do cluster.

Ajuste o arquivo de configuração do cluster de administrador da seguinte maneira:

  • Remova a seção network.hostConfig.
  • Defina loadBalancer.kind como MetalLB.
  • Remova a seção loadBalancer.seesaw.

Exemplo:

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

Ponto principal do exemplo anterior:

  • O cluster não vai mais usar o balanceador de carga do Seesaw, e o cluster não vai usar endereços IP estáticos para os nós do cluster. Portanto, a seção network.hostConfig não será necessária.

Solução de problemas

Se gkectl update falhar durante a migração do cluster de usuário e os pods metálicos não estiverem em execução no cluster de usuário, as VMs do Seesaw deste último precisam ser ativadas manualmente. Isso vai restabelecer o tráfego para os VIPs usados atualmente. No entanto, pode ser que os VIPs recém-criados não sejam mostrados pelas VMs do Seesaw se o pod load-balancer-seesaw não estiver em execução. Se esse for o caso, crie um tíquete de suporte.

Se gkectl update falhar durante a migração do cluster de administrador e os pods metallb não estiverem em execução no cluster de administrador, as VMs do Seesaw deste último precisam ser ativadas manualmente. Assim, o tráfego pode usar os VIPs do plano de controle no momento para que os clusters de usuário voltem a funcionar. No entanto, pode ser que o VIP para o plano de controle do cluster de administrador não funcione. Nesse caso, edite o arquivo kubeconfig do cluster de administrador para usar o endereço IP diretamente do nó do plano de controle do cluster de administrador.

Além disso, no namespace kube-system, mude o tipo de serviço kube-apiserver de ClusterIP para LoadBalancer. Se necessário, crie um tíquete de suporte.