Migrar a configuração da F5 BIG-IP integrada

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.

Neste documento, mostramos 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 o VIP automaticamente no balanceador de carga.

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

Após a migração, suas cargas de trabalho F5 permanecerão, mas o Google Distributed Cloud não vai mais gerenciá-las. Em uma versão futura, a F5 BIG-IP só estará disponível para gerenciamento manual. Isso significa que você será responsável por gerenciar suas cargas de trabalho F5 BIG-IP diretamente.

Requisitos

Confira a seguir os requisitos para fazer a migração:

• O cluster de administrador e todos os clusters de usuário precisam ter a 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. 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 no tráfego HTTP enviado ao VIP de entrada.

   1. Consiga o valor HTTP nodePort atual:

      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 HTTPS nodePort atual:

      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 nodePort atual do 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 de 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 nodePort atual do 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 todos os problemas que o comando encontrar.

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

Atualize o cluster de usuário:

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.

Atualize 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 é altamente disponível (HA). Se o valor for 1, o cluster de administrador não é de alta disponibilidade.

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

   1. Consiga o valor de nodePort do 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 todos os problemas que o comando encontrar.

   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 legados do F5 ainda existem

Depois de atualizar os clusters para usar o balanceamento de carga manual, o tráfego para eles não é interrompido porque os recursos do F5 ainda existem, como você pode conferir ao executar o comando a seguir:

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 do 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 é necessário alterar 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 controlar os nós do plano

O Google Distributed Cloud lida automaticamente com 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 em nós de complementos:

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

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

Cluster de administrador sem alta disponibilidade

Tráfego do plano de controle

Confira 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)

É preciso 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, você terá o seguinte mapeamento para os endereços IP e valores nodePort para serviços em execução em nós complementares:

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

É preciso 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

Confira 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 de 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

Confira 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 de ingressVIP falhará até que você configure pelo menos uma entrada.