Migre do balanceador de carga Seesaw para o MetalLB

Este documento mostra como migrar do balanceador de carga do Seesaw para o balanceador de carga do MetalLB para as versões 1.16 a 1.29. Se os seus clusters estiverem na versão 1.30 ou superior, recomendamos que siga as instruções em Planeie a migração de clusters para funcionalidades recomendadas.

A utilização do MetalLB tem várias vantagens em comparação com outras opções de equilíbrio de carga.

1.28 e 1.29: GA
1.16: Pré-visualização

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

Para verificar o externalTrafficPolicy, execute o seguinte comando:

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

Contacte o Apoio técnico da Google para receber ajuda com este problema.

Notas sobre o período de descanso

Existe um período de inatividade da carga de trabalho durante a migração. As seguintes notas aplicam-se apenas a clusters de administrador de não alta disponibilidade (não HA) porque o balanceador de carga do SeeSaw não suporta clusters de administrador de HA.

• Quando migra um cluster de administrador:

  • Existe um tempo de inatividade do plano de controlo para os clusters de utilizadores do kubeception à medida que o controlPlaneVIP é migrado. O tempo de inatividade deve ser inferior a 10 minutos, mas a duração do tempo de inatividade depende da sua infraestrutura.

  • Existe tempo de inatividade para o plano de controlo do cluster de administrador, uma vez que o nó principal do administrador tem de ser recriado com o controlPlaneVIP diretamente anexado à VM. O tempo de inatividade deve ser inferior a 20 minutos, mas a duração do tempo de inatividade depende da sua infraestrutura.

• Quando migra um cluster de utilizadores, existe uma indisponibilidade para os VIPs depois de o balanceador de carga do Seesaw ser desligado e antes de os pods do MetalLB serem ativados. Geralmente, este processo demora cerca de um minuto.

Migração de clusters de utilizadores

Tem de escolher um conjunto de nós e ativá-lo para utilização com o MetalLB. O MetalLB vai ser implementado nos nós neste conjunto de nós.

Aviso: certifique-se de que o conjunto de nós que ativa para utilização pelo MetalLB não inclui o endereço IP de um serviço com um volume de entrada de tradução de endereços de rede (NAT) elevado. Se o fizer, as suas cargas de trabalho podem ficar sem memória. Em alternativa, use outro conjunto de nós existente ou crie um novo conjunto de nós para o MetalLB usar.

No ficheiro de configuração do cluster de utilizadores, escolha um conjunto 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 o seguinte:

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

• USER_CLUSTER_CONFIG: o caminho do ficheiro de configuração do cluster do utilizador

Em seguida, remova as secções do Seesaw do ficheiro e adicione uma secção do MetalLB.

Em seguida, atualize novamente o cluster:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config USER_CLUSTER_CONFIG

Verifique se os componentes do MetalLB estão a ser executados com êxito:

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

O resultado mostra os pods para o controlador e o altifalante 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 parar as ligações de rede a todos os VIPs no cluster de utilizadores para os serviços Kubernetes do tipo LoadBalancer durante dois a dez minutos. Quando a migração estiver concluída, as associações voltam a funcionar.

Após uma migração bem-sucedida, elimine manualmente as VMs do Seesaw, que já estão desligadas, para o cluster de utilizadores. Pode encontrar os nomes das VMs do Seesaw na secção vmnames do ficheiro seesaw-for-[USERCLUSTERNAME].yaml no diretório de configuração.

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

Suponhamos que tem um cluster de utilizadores que usa endereços IP estáticos para os respetivos nós do cluster. Suponhamos também que o cluster tem dois serviços do tipo LoadBalancer e que os endereços externos desses serviços são 172.16.21.41 e 172.16.21.45.

Ajuste o ficheiro de configuração do cluster de utilizadores da seguinte forma:

• Mantenha a secção network.hostConfig.
• Defina loadBalancer.kind como MetalLB.
• Remova a secção loadBalancer.seesaw.
• Adicione uma secçã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:

• Embora o cluster deixe de usar o equilibrador de carga do Seesaw, a secção network.hostConfig é necessária porque os nós do cluster usam endereços IP estáticos.

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

• Os endereços IP externos, 172.16.21.41 e 172.16.21.45, para os serviços existentes do tipo LoadBalancer estão incluídos no conjunto de endereços do MetalLB.

Exemplo: cluster de utilizador kubeception, DHCP

Suponhamos que tem um cluster de utilizadores que usa DHCP para os respetivos nós de cluster. Suponhamos também que o cluster tem dois serviços do tipo LoadBalancer e que os endereços externos desses serviços são 172.16.21.61 e 172.16.21.65.

Ajuste o ficheiro de configuração do cluster de utilizadores da seguinte forma:

• Remova a secção network.hostConfig.
• Defina loadBalancer.kind como MetalLB.
• Remova a secção loadBalancer.seesaw.
• Adicione uma secçã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 vai deixar de usar o equilibrador de carga do Seesaw e não usa endereços IP estáticos para os respetivos nós do cluster. Por isso, a secção network.hostConfig não é necessária.

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

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

Exemplo: cluster de utilizadores do plano de controlo V2, DHCP

Suponha que tem um cluster de utilizadores com o Controlplane V2 ativado e que usa o DHCP para os respetivos nós de trabalho. Suponha também que o cluster tem dois serviços do tipo LoadBalancer e que os endereços externos desses serviços são 172.16.21.81 e 172.16.21.85.

Ajuste o ficheiro de configuração do cluster de utilizadores da seguinte forma:

• Mantenha a secção network.hostconfig.
• Defina loadBalancer.kind como MetalLB.
• Remova a secção loadBalancer.seesaw.
• Adicione uma secçã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 vai deixar de 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 controlo. Por isso, a secção network.hostConfig é necessária.

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

• Os endereços IP externos, 172.16.21.81 e 172.16.21.85, para os serviços existentes do tipo LoadBalancer estão incluídos no conjunto de endereços do MetalLB.

Migração de cluster de administrador

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

Atualize o cluster:

gkectl update admin --kubeconfig  ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG

Substitua o seguinte:

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

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

Verifique se os componentes do MetalLB estão a ser executados com êxito:

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

O resultado mostra os pods para o controlador e o altifalante 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 ligações de rede a todos os VIPs no cluster de administração para os serviços Kubernetes do tipo LoadBalancer durante dois a dez minutos. Quando a migração estiver concluída, as associações voltam a funcionar.

Após uma migração bem-sucedida, elimine manualmente as VMs do Seesaw, que já estão desligadas, para o cluster de administrador. Pode encontrar os nomes das VMs do Seesaw na secção vmnames do ficheiro seesaw-for-gke-admin.yaml no diretório de configuração.

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

Suponhamos que tem um cluster de administrador que usa endereços IP estáticos para os respetivos nós do cluster.

Ajuste o ficheiro de configuração do cluster de administrador da seguinte forma:

• Mantenha a secção network.hostConfig.
• Defina loadBalancer.kind como MetalLB.
• Remova a secçã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-chave do exemplo anterior:

• Embora o cluster deixe de usar o equilibrador de carga do Seesaw, a secção network.hostConfig é necessária porque os nós do cluster usam endereços IP estáticos.

Exemplo: cluster de administrador, DHCP

Suponhamos que tem um cluster de administrador que usa DHCP para os respetivos nós do cluster.

Ajuste o ficheiro de configuração do cluster de administrador da seguinte forma:

• Remova a secção network.hostConfig.
• Defina loadBalancer.kind como MetalLB.
• Remova a secçã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-chave do exemplo anterior:

• O cluster vai deixar de usar o equilibrador de carga do Seesaw e não usa endereços IP estáticos para os respetivos nós do cluster. Por isso, a secção network.hostConfig não é necessária.

Resolução de problemas

Se a operação gkectl update falhar durante a migração do cluster de utilizadores e os pods do MetalLB não estiverem em execução no cluster de utilizadores, ligue manualmente as VMs do Seesaw do cluster de utilizadores. Esta ação restabelece o tráfego para os VIPs usados atualmente. No entanto, os VIPs criados recentemente podem não ser publicados pelas VMs do Seesaw se o load-balancer-seesawpod não estiver em execução. Se for esse o caso, crie um pedido de apoio técnico.

Se a gkectl update falhar durante a migração do cluster de administrador e os pods do MetalLB não estiverem em execução no cluster de administrador, ligue manualmente as VMs do Seesaw do cluster de administrador. Isto pode permitir que o tráfego para os VIPs do plano de controlo usados atualmente para clusters de utilizadores volte a funcionar. No entanto, o VIP para o plano de controlo do cluster de administrador em si pode não funcionar. Nesse caso, edite o ficheiro kubeconfig do cluster de administrador para usar diretamente o endereço IP do nó do plano de controlo do cluster de administrador.

Além disso, no espaço de nomes kube-system, altere o kube-apiserver tipo de serviço de ClusterIP para LoadBalancer. Se necessário, crie um registo de apoio técnico.