Migrar as definições de configuração do balanceador de carga F5 BIG-IP

1.29: prévia
1.28: indisponível

Neste documento, mostramos como migrar as configurações da integração do balanceador de carga F5 BIG-IP para o modo de balanceamento de carga manual para clusters na versão 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 uso do F5 BIG-IP no modo de balanceamento de carga manual oferece a flexibilidade de atualizar os agentes F5 de forma independente, sem afetar a funcionalidade do balanceador de carga F5 ou dos serviços do Kubernetes. Se você migrar para a configuração manual, poderá receber atualizações diretamente do F5 para garantir a melhor performance e segurança.

Essa migração é necessária nas seguintes circunstâncias:

  • Você quer ativar novos recursos, como o Controlplane V2, e também precisa de acesso ao F5.

  • Você precisa de recursos fornecidos por uma versão do controlador de serviços de entrada de contêineres do BIG-IP CIS (CIS Ingress Services, na sigla em inglês) mais recente que a v1.14.

Se as circunstâncias anteriores não se aplicarem a você, continue usando a configuração agrupada para o balanceamento de carga do F5 BIG-IP.

De qualquer forma, continuamos com suporte oficial para o F5 como uma solução de balanceador de carga.

Suporte para o balanceador de carga F5 BIG-IP

Oferecemos suporte ao uso do F5 BIG-IP com agentes de balanceador de carga, que consistem nos seguintes controladores:

Esses agentes simplificam a configuração dos balanceadores de carga F5 no seu cluster do Kubernetes. Ao criar um serviço do tipo LoadBalancer, os controladores configuram automaticamente o balanceador de carga F5 para direcionar o tráfego aos nós do cluster.

No entanto, a solução agrupada tem limitações:

  • A expressividade da API Service é limitada. Não é possível configurar o controlador BIG-IP como quiser ou usar recursos avançados do F5. O F5 já oferece melhor suporte à API de serviço de forma nativa.

  • A implementação usa a API CCCL ConfigMap legada e o CIS 1.x. No entanto, o F5 agora fornece a API ConfigMap AS3 mais recente e o CIS 2.x.

O controlador do CIS no pacote do Google Distributed Cloud permaneceu na v1.14 devido a problemas de compatibilidade com as orientações de upgrade do F5 para a CIS v2.x. Portanto, para oferecer a flexibilidade de lidar com vulnerabilidades de segurança e acessar os recursos mais recentes, estamos fazendo a transição dos agentes F5 de componentes empacotados para instalação independente. Se você migrar, poderá continuar usando os agentes atuais sem interrupções, e os serviços criados anteriormente vão continuar operacionais.

Para clusters de balanceamento de carga manual recém-criados com o F5 como a solução de balanceamento de carga, você precisa instalar os controladores. Da mesma forma, se o cluster tiver sido migrado do F5 agrupado e você quiser usar uma versão mais recente do controlador CIS, será necessário instalar os controladores.

Requisitos

Confira os requisitos para a migração:

  • O cluster de administrador e todos os clusters de usuário precisam estar na versão 1.29 ou mais recente.

  • Você precisa usar endereços IP estáticos para os nós do cluster de administrador e de usuário. O tipo de endereçamento IP é definido no campo network.ipMode.type e é imutável. Se esse campo estiver definido como DHCP, não será possível migrar os clusters.

Atualizar o arquivo de configuração do cluster de usuário

Faça as seguintes alterações no arquivo de configuração do cluster de usuário:

  1. Altere loadBalancer.kind para "ManualLB".

  2. Mantenha os mesmos valores para os campos loadBalancer.vips.controlPlaneVIP e loadBalancer.vips.ingressVIP.

  3. Configure o nodePort usado para o tráfego HTTP enviado ao VIP de entrada.

    1. Acesse o valor atual de nodePort do HTTP:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          get svc istio-ingress -n gke-system -oyaml | grep http2 -A 1

      Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.

    2. Adicione o valor do comando anterior ao campo loadBalancer.manualLB.ingressHTTPNodePort, por exemplo:

      loadBalancer:
        manualLB:
          ingressHTTPNodePort: 30243
  4. Configure o nodePort usado para o tráfego HTTPS enviado ao VIP de entrada:

    1. Acesse o valor atual de nodePort do HTTPS:

      kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
          get svc istio-ingress -n gke-system -oyaml | grep https -A 1
    2. Adicione o valor do comando anterior ao campo loadBalancer.manualLB.ingressHTTPSNodePort, por exemplo:

      loadBalancer:
        manualLB:
          ingressHTTPSNodePort: 30879
  5. Configure o nodePort para o servidor da API Kubernetes:

    1. Receba o valor atual de nodePort para o servidor da API Kubernetes:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep kube-apiserver-port -A 1

      Substitua:

      • ADMIN_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster admin.

      • USER_CLUSTER_NAME: nome do cluster de usuários.

    2. Adicione o valor do comando anterior ao campo loadBalancer.manualLB.controlPlaneNodePort, por exemplo:

      loadBalancer:
        manualLB:
          controlPlaneNodePort: 30968
  6. Configure o nodePort para o servidor Konnectivity:

    1. Confira o valor atual de nodePort para o servidor da Konnectivity:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          get svc kube-apiserver -n USER_CLUSTER_NAME -oyaml | grep konnectivity-server-port -A 1
    2. Adicione o valor do comando anterior ao campo loadBalancer.manualLB.konnectivityServerNodePort, por exemplo:

      loadBalancer:
        manualLB:
          konnectivityServerNodePort: 30563
  7. Exclua toda a seção loadBalancer.f5BigIP.

Atualizar o cluster de usuários

Execute o comando a seguir para migrar 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.

Atualizar o arquivo de configuração do cluster de administrador

Faça as seguintes mudanças no arquivo de configuração do cluster de administrador:

  1. Altere loadBalancer.kind para "ManualLB".

  2. Mantenha o mesmo valor para o campo loadBalancer.vips.controlPlaneVIP.

  3. Confira o valor do campo adminMaster.replicas. Se o valor for 3, o cluster de administrador estará em alta disponibilidade (HA). Se o valor for 1, o cluster de administrador não é HA.

  4. Siga as etapas a seguir apenas para clusters de administrador sem HA:

    1. Receba o valor do nodePort para o servidor da API Kubernetes:

      kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          get svc kube-apiserver -n kube-system -oyaml | grep nodePort

      Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de administrador.

    2. Adicione o valor do comando anterior ao campo loadBalancer.manualLB.controlPlaneNodePort, por exemplo:

      loadBalancer:
        manualLB:
          controlPlaneNodePort: 30968
  5. Execute o comando a seguir para saber se há um nodePort de complementos:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
        get deploy monitoring-operator -n kube-system -oyaml | grep admin-ingress-nodeport

    Se o comando anterior gerar um valor, adicione-o ao campo loadBalancer.manualLB.addonsNodePort, por exemplo:

    loadBalancer:
      manualLB:
        addonsNodePort: 31405
  6. Exclua toda a seção loadBalancer.f5BigIP.

Atualize o cluster de administrador:

Execute o seguinte comando para atualizar 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

Verificar se os recursos legados do F5 ainda existem

Depois de atualizar os clusters para usar o balanceamento de carga manual, o tráfego para os clusters não é interrompido porque os recursos F5 ainda existem, como pode ser visto ao executar o seguinte comando:

kubectl --kubeconfig CLUSTER_KUBECONFIG \
  api-resources --verbs=list -o name   | xargs -n 1 kubectl --kubeconfig CLUSTER_KUBECONFIG get --show-kind --ignore-not-found --selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

Substitua CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário ou de administrador.

A saída esperada terá esta aparência:

Cluster de administrador:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-xt697x   Opaque   4      13h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         13h
kube-system   serviceaccount/load-balancer-f5   0         13h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           13h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           13h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   13h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T04:37:34Z

Cluster de usuário:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-sspwrd   Opaque   4      14h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         14h
kube-system   serviceaccount/load-balancer-f5   0         14h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           14h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           14h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         14h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   14h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T05:16:40Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T05:16:41Z

Verificar o balanceador de carga

Após a migração, não será necessário mudar nenhuma configuração no balanceador de carga, porque você manteve os mesmos valores de VIP e nodePort. As tabelas a seguir descrevem os mapeamentos de VIPs para endereços IP do nó:nodePort.

Cluster de administrador de alta disponibilidade

Tráfego para nós do plano de controle

O Google Distributed Cloud processa automaticamente o balanceamento de carga do tráfego do plano de controle para clusters de administrador de alta disponibilidade. Embora não seja necessário configurar um mapeamento no balanceador de carga, é preciso especificar um endereço IP no campo loadBalancer.vips.controlPlaneVIP.

Tráfego para serviços nos nós de complemento

Se o cluster de administrador tiver um valor para addonsNodePort, vai aparecer um mapeamento para os endereços IP e o valor nodePort do tráfego para serviços em nós de complemento:

  • (addonsVIP:8443) -> (NODE_IP_ADDRESSES:addonsNodePort)

Você precisa ter esse mapeamento para todos os nós no cluster de administrador, tanto os nós do plano de controle quanto os de complemento.

Cluster de administrador sem alta disponibilidade

Tráfego do plano de controle

O exemplo a seguir mostra o mapeamento para o endereço IP e o valor de nodePort do nó do plano de controle:

  • (controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort)

Você precisa ter esse mapeamento para todos os nós no cluster de administrador, tanto o do plano de controle quanto os de complemento.

Tráfego para serviços nos nós de complemento

Se o cluster de administrador tiver um valor para addonsNodePort, você terá o mapeamento a seguir para os endereços IP e os valores de nodePort dos serviços em execução em nós de complemento:

  • (addonsVIP:8443) -> (NODE_IP_ADDRESSES:addonsNodePort)

Você precisa ter esse mapeamento para todos os nós no cluster de administrador, tanto o do plano de controle quanto os de complemento.

Cluster de usuário

Tráfego do plano de controle

O exemplo a seguir mostra o mapeamento para os endereços IP e os valores de nodePort do tráfego do plano de controle:

  • (controlPlaneVIP:443) -> (NODE_IP_ADDRESSES:controlPlaneNodePort)
  • (controlPlaneVIP:8132) -> (NODE_IP_ADDRESSES:konnectivityServerNodePort)

Esse mapeamento precisa estar presente em todos os nós do cluster de administrador, tanto os nós do plano de controle do cluster de administrador quanto os do cluster de usuário.

Tráfego do plano de dados

O exemplo a seguir mostra o mapeamento para os endereços IP e os valores de nodePort do tráfego do plano de dados:

  • (ingressVIP:80) -> (NODE_IP_ADDRESSES:ingressHTTPNodePort)
  • (ingressVIP:443) -> (NODE_IP_ADDRESSES:ingressHTTPSNodePort)