Migre as definições de configuração do seu equilibrador de carga F5 BIG-IP

Pré-visualização

Esta funcionalidade está sujeita aos "Termos das Ofertas de Pré-DG" na secção Termos Gerais de Serviço dos Termos Específicos do Serviço. As funcionalidades de pré-DG estão disponíveis "tal como estão" e podem ter apoio técnico limitado. Para mais informações, consulte as descrições das fases de lançamento.

1.29: pré-visualização
1.28: não disponível

Este documento mostra como migrar as definições de configuração da integração do equilibrador de carga F5 BIG-IP para o modo de equilíbrio de carga manual para clusters na versão 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 F5 BIG-IP no modo de equilíbrio de carga manual dá-lhe a flexibilidade de atualizar os agentes F5 de forma independente sem afetar a funcionalidade do equilibrador de carga F5 ou dos seus serviços Kubernetes. Se migrar para a configuração manual, pode obter atualizações diretamente da F5 para garantir um desempenho e uma segurança ideais.

Nota: se optar por alterar as definições nos ficheiros de configuração do cluster para usar o equilíbrio de carga manual para o F5 BIG-IP, isto não significa que o equilíbrio de carga seja manual. Com o balanceamento de carga F5 agrupado ou manual, os agentes do balanceador de carga ajudam a gerir automaticamente a configuração do balanceamento de carga.

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

• Quiser ativar novas funcionalidades, como o Controlplane V2, e também precisar de acesso ao F5.

• Precisa de capacidades fornecidas por uma versão do BIG-IP CIS Container Ingress Services (CIS) Controller superior à v1.14.

Se as circunstâncias anteriores não se aplicarem a si, pode continuar a usar a configuração incluída para o equilíbrio de carga do F5 BIG-IP.

De qualquer forma, continuamos a suportar oficialmente o F5 como uma solução de balanceamento de carga.

Suporte para o balanceador de carga F5 BIG-IP

Suportamos a utilização do F5 BIG-IP com agentes de balanceamento de carga, que consistem nos dois controladores seguintes:

• Controlador F5 (prefixo do pod: load-balancer-f5): reconcilia os serviços Kubernetes do tipo LoadBalancer no formato F5 Common Controller Core Library (CCCL) ConfigMap.

• F5 BIG-IP CIS Controller v1.14 (prefixo do pod: k8s-bigip-ctlr-deployment): traduz os ConfigMaps em configurações do equilibrador de carga F5.

Estes 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 equilibrador de carga F5 para direcionar o tráfego para os nós do cluster.

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

• A expressividade da API Service é limitada. Não pode configurar o controlador BIG-IP como quiser nem usar funcionalidades avançadas da F5. A F5 já oferece melhor suporte da API Service de forma nativa.

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

O controlador do CIS no pacote do Google Distributed Cloud permaneceu na versão 1.14 devido a problemas de compatibilidade com as orientações de atualização do F5 para o CIS v2.x. Por conseguinte, para lhe dar a flexibilidade de resolver vulnerabilidades de segurança e aceder às funcionalidades mais recentes, estamos a fazer a transição dos agentes F5 de componentes incluídos para instalação independente. Se migrar, pode continuar a usar os agentes existentes sem interrupções e os serviços criados anteriormente permanecem operacionais.

Para clusters de equilíbrio de carga manual criados recentemente com o F5 como solução de equilíbrio de carga, tem de instalar os controladores manualmente. Da mesma forma, se o cluster tiver sido migrado do F5 integrado e quiser usar uma versão mais recente do controlador do CIS, tem de instalar os controladores manualmente.

Requisitos

Seguem-se os requisitos para a migração:

• O cluster de administrador e todos os clusters de utilizadores têm de ter a versão 1.29 ou superior.

• Tem de usar endereços IP estáticos para os nós do cluster de administrador e de utilizador. O tipo de endereçamento IP é definido no campo network.ipMode.type e é imutável. Se este campo estiver definido como DHCP, não pode migrar os clusters.

Atualize o ficheiro de configuração do cluster de utilizadores

Faça as seguintes alterações ao ficheiro de configuração do cluster de utilizadores:

1. Alterar 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 para o VIP de entrada.

   1. Obter 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 ficheiro kubeconfig do cluster de utilizadores.

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

      loadBalancer:
        manualLB:
          ingressHTTPNodePort: 30243

4. Configure a nodePort usada para o tráfego HTTPS enviado para o VIP de entrada:

   1. Obter 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. Obtenha o valor nodePort atual 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 o seguinte:

      • ADMIN_CLUSTER_KUBECONFIG com o caminho do ficheiro kubeconfig do cluster admin.

      • USER_CLUSTER_NAME: nome do cluster de utilizadores.

   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. Obtenha o valor nodePort atual 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. Eliminar a secção loadBalancer.f5BigIP inteira.

Atualize o cluster de utilizadores

Execute o seguinte comando para migrar 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 de utilizadores.

Atualize o ficheiro de configuração do cluster de administrador

Faça as seguintes alterações ao ficheiro de configuração do cluster de administrador:

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

4. Execute os seguintes passos apenas para clusters de administrador sem HA:

   1. Obtenha 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 ficheiro 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 existe um suplemento 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. Eliminar a secção loadBalancer.f5BigIP inteira.

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 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 recursos F5 antigos ainda existem

Depois de atualizar os clusters para usar o equilíbrio de carga manual, o tráfego para os clusters não é interrompido porque os recursos F5 existentes continuam a existir, como pode ver executando 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 ficheiro kubeconfig do cluster de administrador ou do cluster de utilizador.

O resultado esperado é semelhante ao seguinte:

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 utilizadores:

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

Verifique o equilibrador de carga

Após a migração, não deve ter de alterar nenhuma definição no seu equilibrador de carga porque manteve os mesmos VIPs e valores nodePort. As tabelas seguintes descrevem os mapeamentos de VIPs para endereços IP de nós:nodePort.

Cluster de administrador de HA

Tráfego para nós do plano de controlo

O Google Distributed Cloud processa automaticamente o equilíbrio de carga do tráfego do plano de controlo para clusters de administrador de HA. Embora não precise de configurar um mapeamento no equilibrador de carga, tem de especificar um endereço IP no campo loadBalancer.vips.controlPlaneVIP.

Tráfego para serviços nos nós suplementares

Se o seu cluster de administrador tiver um valor para addonsNodePort, deve ver um mapeamento para os endereços IP e o valor nodePort para o tráfego para serviços em nós suplementares:

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

Deve ter este mapeamento para todos os nós no cluster de administrador, tanto os nós do plano de controlo como os nós do suplemento.

Cluster de administrador não de HA

Tráfego do plano de controlo

A imagem seguinte mostra o mapeamento para o endereço IP e o valor nodePort do nó do plano de controlo:

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

Deve ter este mapeamento para todos os nós no cluster de administrador, tanto o nó do plano de controlo como os nós de suplementos.

Tráfego para serviços nos nós suplementares

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

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

Deve ter este mapeamento para todos os nós no cluster de administrador, tanto o nó do plano de controlo como os nós de suplementos.

Cluster de utilizadores

Tráfego do plano de controlo

A imagem seguinte mostra o mapeamento para os endereços IP e os valores nodePort para o tráfego do plano de controlo:

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

Deve ter este mapeamento para todos os nós no cluster admin, tanto o cluster de administrador como os nós do plano de controlo do cluster de utilizador.

Tráfego do plano de dados

A tabela seguinte mostra o mapeamento para os endereços IP e os valores nodePort para o tráfego do plano de dados:

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

Nota: a verificação de estado para ingressVIP vai falhar até configurar, pelo menos, uma entrada.