Esegui la migrazione delle impostazioni di configurazione del bilanciatore del carico F5 BIG-IP

Anteprima

Questa funzionalità è soggetta ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. Le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

1.29: Anteprima
1.28: Non disponibile

Questo documento mostra come eseguire la migrazione delle impostazioni di configurazione per l'integrazione del bilanciatore del carico F5 BIG-IP alla modalità di bilanciamento del carico manuale per i cluster alla versione 1.29. Se i tuoi cluster sono alla versione 1.30 o successive, ti consigliamo di seguire le istruzioni riportate in Pianificare la migrazione del cluster alle funzionalità consigliate.

L'utilizzo di F5 BIG-IP in modalità di bilanciamento del carico manuale ti offre la flessibilità di eseguire l'upgrade degli agenti F5 in modo indipendente senza influire sulla funzionalità del bilanciatore del carico F5 o dei servizi Kubernetes. Se esegui la migrazione alla configurazione manuale, puoi ottenere gli aggiornamenti direttamente da F5 per garantire prestazioni e sicurezza ottimali.

Nota: se scegli di modificare le impostazioni nei file di configurazione del cluster per utilizzare il bilanciamento del carico manuale per F5 BIG-IP, ciò non significa che il bilanciamento del carico sia manuale. Con il bilanciamento del carico F5 in bundle o manuale, gli agenti del bilanciatore del carico ti aiutano a gestire automaticamente la configurazione del bilanciamento del carico.

Questa migrazione è necessaria nelle seguenti circostanze:

• Vuoi attivare nuove funzionalità come Controlplane V2 e hai anche bisogno dell'accesso a F5.

• Hai bisogno delle funzionalità fornite da una versione di BIG-IP CIS Container Ingress Services (CIS) Controller superiore alla v1.14.

Se le circostanze precedenti non ti riguardano, puoi continuare a utilizzare la configurazione in bundle per il bilanciamento del carico F5 BIG-IP.

In ogni caso, continuiamo a supportare ufficialmente F5 come soluzione di bilanciamento del carico.

Supporto del bilanciatore del carico F5 BIG-IP

Supportiamo l'utilizzo di F5 BIG-IP con agenti di bilanciamento del carico, costituiti dai seguenti due controller:

• Controller F5 (prefisso pod: load-balancer-f5): riconcilia i servizi Kubernetes di tipo LoadBalancer nel formato ConfigMap della libreria principale del controller comune (CCCL) F5.

• F5 BIG-IP CIS Controller v1.14 (prefisso pod: k8s-bigip-ctlr-deployment): traduce ConfigMaps in configurazioni del bilanciatore del carico F5.

Questi agenti semplificano la configurazione dei bilanciatori del carico F5 all'interno del tuo cluster Kubernetes. Se crei un servizio di tipo LoadBalancer, i controller configurano automaticamente il bilanciatore del carico F5 per indirizzare il traffico ai nodi del cluster.

Tuttavia, la soluzione in bundle presenta delle limitazioni:

• L'espressività dell'API Service è limitata. Non puoi configurare il controller BIG-IP come preferisci o utilizzare le funzionalità avanzate di F5. F5 fornisce già un migliore supporto dell'API Service in modo nativo.

• L'implementazione utilizza l'API ConfigMap CCCL legacy e CIS 1.x. Tuttavia, F5 ora fornisce le API AS3 ConfigMap e CIS 2.x più recenti.

Il controller CIS nel bundle Google Distributed Cloud è rimasto alla versione 1.14 a causa di problemi di compatibilità con le indicazioni per l'upgrade F5 per CIS v2.x. Pertanto, per offrirti la flessibilità di risolvere le vulnerabilità di sicurezza e accedere alle funzionalità più recenti, stiamo eseguendo la transizione degli agenti F5 da componenti in bundle a componenti installati in modo indipendente. Se esegui la migrazione, puoi continuare a utilizzare gli agenti esistenti senza interruzioni e i servizi creati in precedenza rimangono operativi.

Per i cluster bilanciamento del carico manuale appena creati con F5 come soluzione di bilanciamento del carico, devi installare i controller autonomamente. Analogamente, se il cluster è stato migrato da F5 in bundle e vuoi utilizzare una versione più recente del controller CIS, devi installare i controller autonomamente.

Requisiti

Di seguito sono riportati i requisiti per la migrazione:

• Il cluster di amministrazione e tutti i cluster utente devono essere alla versione 1.29 o successive.

• Devi utilizzare indirizzi IP statici per i nodi del cluster di amministrazione e utente. Il tipo di indirizzamento IP è impostato nel campo network.ipMode.type ed è immutabile. Se questo campo è impostato su DHCP, non puoi eseguire la migrazione dei cluster.

Aggiorna il file di configurazione del cluster utente

Apporta le seguenti modifiche al file di configurazione del cluster utente:

1. Modifica loadBalancer.kind in "ManualLB".

2. Mantieni gli stessi valori per i campi loadBalancer.vips.controlPlaneVIP e loadBalancer.vips.ingressVIP.

3. Configura nodePort utilizzato per il traffico HTTP inviato al VIP in entrata.

   1. Ottieni il valore nodePort HTTP corrente:

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

      Sostituisci USER_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster utente.

   2. Aggiungi il valore del comando precedente al campo loadBalancer.manualLB.ingressHTTPNodePort, ad esempio:

      loadBalancer:
        manualLB:
          ingressHTTPNodePort: 30243

4. Configura nodePort utilizzato per il traffico HTTPS inviato all'IP virtuale Ingress:

   1. Ottieni il valore nodePort HTTPS corrente:

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

   2. Aggiungi il valore del comando precedente al campo loadBalancer.manualLB.ingressHTTPSNodePort, ad esempio:

      loadBalancer:
        manualLB:
          ingressHTTPSNodePort: 30879

5. Configura nodePort per il server dell'API Kubernetes:

   1. Ottieni il valore nodePort corrente per il server API Kubernetes:

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

      Sostituisci quanto segue:

      • ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster amministratore.

      • USER_CLUSTER_NAME: il nome del cluster utente.

   2. Aggiungi il valore del comando precedente al campo loadBalancer.manualLB.controlPlaneNodePort, ad esempio:

      loadBalancer:
        manualLB:
          controlPlaneNodePort: 30968

6. Configura nodePort per il server Konnectivity:

   1. Ottieni il valore nodePort attuale per il server Konnectivity:

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

   2. Aggiungi il valore del comando precedente al campo loadBalancer.manualLB.konnectivityServerNodePort, ad esempio:

      loadBalancer:
        manualLB:
          konnectivityServerNodePort: 30563

7. Elimina l'intera sezione loadBalancer.f5BigIP.

Aggiorna il cluster utente

Esegui questo comando per eseguire la migrazione del cluster:

gkectl update cluster \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Sostituisci quanto segue:

• ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

• USER_CLUSTER_CONFIG: il percorso del file di configurazione del cluster utente.

Aggiorna il file di configurazione del cluster di amministrazione

Apporta le seguenti modifiche al file di configurazione del cluster di amministrazione:

1. Modifica loadBalancer.kind in "ManualLB".

2. Mantieni lo stesso valore per il campo loadBalancer.vips.controlPlaneVIP.

3. Controlla il valore del campo adminMaster.replicas. Se il valore è 3, il cluster di amministrazione è ad alta disponibilità (HA). Se il valore è 1, il cluster di amministrazione non è ad alta disponibilità.

4. Esegui i seguenti passaggi solo per i cluster di amministrazione non HA:

   1. Recupera il valore di nodePort per il server API Kubernetes:

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

      Sostituisci ADMIN_CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione.

   2. Aggiungi il valore del comando precedente al campo loadBalancer.manualLB.controlPlaneNodePort, ad esempio:

      loadBalancer:
        manualLB:
          controlPlaneNodePort: 30968

5. Esegui questo comando per verificare se è presente un componente aggiuntivo nodePort:

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

   Se il comando precedente restituisce un valore, aggiungilo al campo loadBalancer.manualLB.addonsNodePort, ad esempio:

   loadBalancer:
     manualLB:
       addonsNodePort: 31405

6. Elimina l'intera sezione loadBalancer.f5BigIP.

Aggiorna il cluster di amministrazione

Esegui questo comando per aggiornare il cluster:

gkectl update admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG

Sostituisci quanto segue:

• ADMIN_CLUSTER_KUBECONFIG: il percorso del file kubeconfig del cluster di amministrazione.

• ADMIN_CLUSTER_CONFIG: il percorso del file di configurazione del cluster di amministrazione.

Verifica che le risorse F5 legacy esistano ancora

Dopo aver aggiornato i cluster in modo che utilizzino il bilanciamento del carico manuale, il traffico verso i cluster non viene interrotto perché le risorse F5 esistenti sono ancora presenti, come puoi vedere eseguendo il seguente 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

Sostituisci CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster di amministrazione o del cluster utente.

L'output previsto è simile al seguente:

Cluster di amministrazione:

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

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

Controlla il bilanciatore del carico

Dopo la migrazione, non dovresti dover modificare alcuna impostazione nel bilanciatore del carico perché hai mantenuto gli stessi VIP e valori nodePort. Le tabelle seguenti descrivono i mapping dagli IP virtuali agli indirizzi IP nodo:nodePort.

Cluster di amministrazione HA

Traffico verso i nodi del control plane

Google Distributed Cloud gestisce automaticamente il bilanciamento del carico del traffico del control plane per i cluster di amministrazione HA. Sebbene non sia necessario configurare un mapping nel bilanciatore del carico, devi specificare un indirizzo IP nel campo loadBalancer.vips.controlPlaneVIP.

Traffico verso i servizi nei nodi aggiuntivi

Se il cluster di amministrazione aveva un valore per addonsNodePort, dovresti vedere un mapping agli indirizzi IP e al valore nodePort per il traffico verso i servizi nei nodi dei componenti aggiuntivi:

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

Devi avere questo mapping per tutti i nodi del cluster di amministrazione, sia per i nodi del control plane sia per i nodi dei componenti aggiuntivi.

Cluster di amministrazione non HA

Traffico del control plane

Di seguito è riportata la mappatura all'indirizzo IP e al valore nodePort per il nodo del control plane:

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

Devi avere questo mapping per tutti i nodi del cluster di amministrazione, sia per il nodo del control plane sia per i nodi aggiuntivi.

Traffico verso i servizi nei nodi aggiuntivi

Se il tuo cluster di amministrazione aveva un valore per addonsNodePort, dovresti avere la seguente mappatura agli indirizzi IP e ai valori nodePort per i servizi in esecuzione nei nodi dei componenti aggiuntivi:

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

Devi avere questo mapping per tutti i nodi del cluster di amministrazione, sia per il nodo del control plane sia per i nodi aggiuntivi.

Cluster utente

Traffico del control plane

Di seguito è riportato il mapping agli indirizzi IP e ai valori nodePort per il traffico del control plane:

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

Devi disporre di questo mapping per tutti i nodi del cluster admin, sia per il cluster di amministrazione sia per i nodi del control plane del cluster utente.

Traffico del piano dati

Di seguito è riportata la mappatura agli indirizzi IP e ai valori nodePort per il traffico del data plane:

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

Nota: il controllo di integrità di ingressVIP non riuscirà finché non configuri almeno un ingresso.