Migrar do balanceador de carga do Seesaw para o MetalLB

Neste documento, mostramos como migrar do balanceador de carga Seesaw para o balanceador de carga MetalLB nas versões 1.16 a 1.29. Se os clusters estiverem na versão 1.30 ou mais recente, recomendamos que você siga as instruções em Planejar a migração de clusters para recursos recomendados.

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

1.28 e 1.29: GA
1.16: pré-lançamento

Aviso: não migre para o MetalLB se você estiver usando o Seesaw para a preservação do endereço IP do cliente. Mais especificamente, não migre para o MetalLB se houver serviços no cluster com spec.externalTrafficPolicy definido como Local.

Para verificar o externalTrafficPolicy, execute este comando:

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

Entre em contato com o Suporte do Google para receber ajuda com esse problema.

Observações sobre o tempo de inatividade

Há um tempo de inatividade da carga de trabalho durante a migração. As observações a seguir só se aplicam a clusters de administrador sem alta disponibilidade (não HA), porque o balanceador de carga SeeSaw não funciona com clusters de administrador HA.

• Ao migrar um cluster de administrador:

  • Há um tempo de inatividade do plano de controle para clusters de usuário kubeception, porque o controlPlaneVIP é migrado. O tempo de inatividade deve ser inferior a 10 minutos, mas a duração depende da sua infraestrutura.

  • Há um tempo de inatividade para o plano de controle do cluster de administrador, porque o nó mestre de administrador precisa ser recriado com o controlPlaneVIP diretamente anexado à VM. O tempo de inatividade precisa ser inferior a 20 minutos, mas a duração dele depende da sua infraestrutura.

• Ao migrar um cluster de usuário, há uma interrupção dos VIPs depois que o balanceador de carga do Seesaw é desativado e antes que os pods do MetalLB apareçam. Esse processo geralmente leva cerca de um minuto.

Migração de cluster de usuário

Você precisa escolher um pool de nós e ativá-lo para uso com o MetalLB. O MetalLB será implantado nos nós desse pool de nós.

Aviso: verifique se o pool de nós ativado para uso pelo MetalLB não inclui o endereço IP de um serviço com um volume de entrada da conversão de endereços de rede (NAT) alto. Isso pode fazer com que suas cargas de trabalho fiquem sem memória. Use outro pool de nós ou crie um novo para o MetalLB usar.

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

Importante: o processo de migração vai interromper as conexões de rede com todos os VIPs no cluster de usuário para Serviços do Kubernetes do tipo LoadBalancer por dois a dez minutos. Depois que a migração for concluída, as conexões vão voltar a funcionar.

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 kubeception, 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:

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"
  

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.

Exemplo: cluster de usuário do Controlplane V2, DHCP

Suponha que você tenha um cluster de usuário com o Controlplane V2 ativado e que use DHCP para os nós de worker. 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.81 e 172.16.21.85.

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:

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"
  

Pontos principais do exemplo anterior:

• O cluster não vai mais usar endereços IP estáticos para os nós de trabalho, mas vai usar endereços IP estáticos para os nós do plano de controle. Portanto, a seção network.hostConfig é necessária.

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

• Os endereços IP externos, 172.16.21.81 e 172.16.21.85, 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. Por 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

Importante: o processo de migração vai interromper as conexões de rede com todos os VIPs no cluster de administrador para Serviços do Kubernetes do tipo LoadBalancer por dois a dez minutos. Depois que a migração for concluída, as conexões vão voltar a funcionar.

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