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 generali del servizio 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 nella versione 1.29. Se i tuoi cluster sono alla versione 1.30 o successiva, ti consigliamo di seguire le istruzioni riportate in Pianificare la migrazione dei 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 dei tuoi agenti F5 in modo indipendente senza influire sulla funzionalità del bilanciatore del carico F5 o dei tuoi servizi Kubernetes. Se esegui la migrazione alla configurazione manuale, puoi ottenere 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, non significa che il bilanciamento del carico sia manuale. Con il bilanciamento del carico F5 integrato o manuale, gli agenti del bilanciatore del carico ti aiutano a gestire automaticamente la configurazione del bilanciamento del carico.

Questa migrazione è obbligatoria nelle seguenti circostanze:

• Vuoi attivare nuove funzionalità come Controlplane v2 e hai anche bisogno di accedere a F5.

• Sono necessarie le funzionalità fornite da una versione di BIG-IP CIS Container Ingress Services (CIS) Controller successiva alla v1.14.

Se le circostanze precedenti non si applicano al tuo caso, 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 per il bilanciatore del carico F5 BIG-IP

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

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

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

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

Tuttavia, la soluzione in bundle presenta alcune limitazioni:

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

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

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 di F5 per la versione 2.x di CIS. 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 installazioni indipendenti. Se esegui la migrazione, puoi continuare a utilizzare gli agenti esistenti senza interruzioni e i servizi creati in precedenza rimangono operativi.

Per i cluster di bilanciamento del carico manuale appena creati con F5 come soluzione di bilanciamento del carico, devi installare i controller autonomamente. Analogamente, se la migrazione del cluster è stata eseguita 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 della versione 1.29 o successive.

• Devi utilizzare indirizzi IP statici per i nodi del cluster di amministrazione e utente. Il tipo di indirizzo 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 all'IP virtuale di ingresso.

   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 loadBalancer.manualLB.ingressHTTPNodePort campo, ad esempio:

      loadBalancer:
        manualLB:
          ingressHTTPNodePort: 30243

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

   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 loadBalancer.manualLB.ingressHTTPSNodePort campo, ad esempio:

      loadBalancer:
        manualLB:
          ingressHTTPSNodePort: 30879

5. Configura nodePort per il server API Kubernetes:

   1. Ottieni il valore corrente di nodePort 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 di amministrazione.

      • USER_CLUSTER_NAME: il nome del cluster di utenti.

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

      loadBalancer:
        manualLB:
          controlPlaneNodePort: 30968

6. Configura nodePort per il server Konnectivity:

   1. Ottieni il valore corrente di nodePort 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 loadBalancer.manualLB.konnectivityServerNodePort campo, ad esempio:

      loadBalancer:
        manualLB:
          konnectivityServerNodePort: 30563

7. Elimina l'intera sezione loadBalancer.f5BigIP.

Aggiorna il cluster utente

Esegui il seguente 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 amministrativi non HA:

   1. Ottieni 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 loadBalancer.manualLB.controlPlaneNodePort campo, ad esempio:

      loadBalancer:
        manualLB:
          controlPlaneNodePort: 30968

5. Esegui il seguente comando per verificare se sono presenti componenti aggiuntivi 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 loadBalancer.manualLB.addonsNodePort campo, ad esempio:

   loadBalancer:
     manualLB:
       addonsNodePort: 31405

6. Elimina l'intera sezione loadBalancer.f5BigIP.

Aggiorna il cluster di amministrazione

Esegui il comando seguente 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.

Verificare che le risorse F5 legacy esistano ancora

Dopo aver aggiornato i cluster in modo da utilizzare 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 di utenti:

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 seguenti tabelle descrivono le mappature dai VIP agli indirizzi IP dei nodi:nodePort.

Cluster di amministrazione HA

Traffico verso i nodi del control plane

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

Traffico verso i servizi nei nodi dei componenti aggiuntivi

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

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

Questa mappatura deve essere presente 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 ad alta disponibilità

Traffico del piano di controllo

Di seguito è riportata la mappatura all'indirizzo IP e al valore nodePort per il nodo del piano di controllo:

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

Questa mappatura deve essere presente per tutti i nodi del cluster di amministrazione, sia per il nodo del control plane sia per i nodi dei componenti aggiuntivi.

Traffico verso i servizi nei nodi dei componenti 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)

Questa mappatura deve essere presente per tutti i nodi del cluster di amministrazione, sia per il nodo del control plane sia per i nodi dei componenti aggiuntivi.

Cluster utente

Traffico del piano di controllo

Di seguito è riportata la mappatura agli indirizzi IP e ai valori nodePort per il traffico del piano di controllo:

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

Questa mappatura deve essere presente per tutti i nodi del cluster admin, sia per i nodi del cluster di amministrazione sia per i nodi del piano di controllo del cluster utente.

Traffico del piano dati

Di seguito è riportata la mappatura agli indirizzi IP e ai valori nodePort per il traffico del piano di dati:

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

Nota: il controllo di stato di ingressVIP non andrà a buon fine finché non avrai configurato almeno un ingress.