Migrar a configuração do F5 Big-IP integrado

Visualização

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Este documento mostra como migrar as definições de configuração do balanceador de carga integrado F5 BIG-IP para o modo de balanceamento de carga manual.

Suporte para o balanceador de carga F5 BIG-IP

Antes, era possível configurar o Google Distributed Cloud para ser integrado ao F5 BIG-IP da seguinte maneira: quando um desenvolvedor cria um Serviço do tipo LoadBalancer e especifica um endereço IP virtual (VIP) para o serviço, o Google Distributed Cloud configura automaticamente o VIP no balanceador de carga.

Para ativar recursos novos e avançados, como o Controlplane V2, recomendamos que você atualize a configuração. É possível continuar usando o balanceador de carga F5 Big-IP, mas é necessário alterar as definições nos arquivos de configuração do cluster para usar o balanceamento de carga manual.

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

• 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. Mude 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. Consiga o valor atual de HTTP nodePort:

      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. Consiga o valor atual de HTTPS nodePort:

      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. Consiga 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ário.

   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. Consiga o valor atual de nodePort para o servidor 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.

8. Execute gkectl diagnose cluster e corrija os problemas encontrados pelo comando.

   gkectl diagnose cluster \
       --kubeconfig=ADMIN_CLUSTER_KUBECONFIG \
       --cluster-name=USER_CLUSTER_NAME

Atualize o cluster de usuário:

Execute o seguinte comando 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 alterações no arquivo de configuração do cluster de administrador:

1. Mude loadBalancer.kind para "ManualLB".

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

3. Verifique o valor do campo adminMaster.replicas. Se o valor for 3, o cluster de administrador tem alta disponibilidade (HA, na sigla em inglês). Se o valor for 1, o cluster de administrador não é de alta disponibilidade.

4. Siga as etapas a seguir apenas para clusters de administrador que não sejam de alta disponibilidade:

   1. Consiga o valor de 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 seguinte comando para ver se há um complemento nodePort:

   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.

7. Execute gkectl diagnose cluster e corrija os problemas encontrados pelo comando.

   gkectl diagnose cluster \
       --kubeconfig=ADMIN_CLUSTER_KUBECONFIG

Atualize o cluster de administrador:

Execute o seguinte comando para atualizar o cluster:

gkectl update cluster \
    --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 F5 legados ainda existem

Depois de atualizar os clusters para usar o balanceamento de carga manual, o tráfego para os clusters não será interrompido porque os recursos F5 atuais ainda existem, como você pode ver 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 cluster de administrador ou pelo arquivo kubeconfig do cluster de usuário.

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 VIPs 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 gerencia 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 do complemento

Se o cluster de administrador tiver um valor para addonsNodePort, você verá um mapeamento para os endereços IP e o valor nodePort para o tráfego para serviços nos nós complementares:

• (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 nós do complemento.

Cluster de administrador que não é de alta disponibilidade

Tráfego do plano de controle

Veja a seguir o mapeamento para o endereço IP e o valor 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 nó do plano de controle quanto os nós do complemento.

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

Se o cluster de administrador tiver um valor para addonsNodePort, será preciso ter o seguinte mapeamento para os endereços IP e os valores nodePort para serviços em execução nos nós complementares:

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

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

Cluster de usuário

Tráfego do plano de controle

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

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

É necessário ter esse mapeamento para todos os nós no cluster admin, tanto o cluster de administrador quanto os nós do plano de controle do cluster de usuário.

Tráfego do plano de dados

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

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

Observação: a verificação de integridade para ingressVIP falhará até que você configure pelo menos uma entrada.