Crea un bilanciatore del carico interno

Questa pagina spiega come creare un bilanciatore del carico di rete passthrough interno o un bilanciatore del carico interno su Google Kubernetes Engine (GKE). Per creare un bilanciatore del carico di rete passthrough esterno, consulta Crea un servizio di tipo LoadBalancer.

Prima di leggere questa pagina, assicurati di avere familiarità con i seguenti concetti:

• Servizio LoadBalancer.
• Parametri del servizio LoadBalancer.
• Bilanciatore del carico di rete passthrough esterno basato sui servizi di backend.

Utilizzo del bilanciatore del carico di rete passthrough interno

I bilanciatori del carico di rete pass-through interni rendono i servizi del cluster accessibili ai client che si trovano nella rete VPC del cluster e ai client nelle reti connesse alla rete VPC del cluster. I client nella rete VPC del cluster possono essere nodi o pod del cluster oppure VM al di fuori del cluster. Per ulteriori informazioni sulla connettività dai client nelle reti connesse, consulta Bilanciatori del carico di rete passthrough interni e reti connesse.

Utilizzo dell'impostazione secondaria GKE

Il sottoinsieme GKE migliora la scalabilità dei servizi LoadBalancer interni perché utilizza i gruppi di endpoint di rete (NEG) GCE_VM_IP come backend anziché i gruppi di istanze. Quando il subsetting GKE è abilitato, GKE crea un NEG per zona di calcolo per ogni servizio LoadBalancer interno.

Il externalTrafficPolicy del nodo di controllo del servizio nell'appartenenza ai backend NEG GCE_VM_IP. Per ulteriori informazioni, consulta Iscrizione dei nodi ai backend NEG di GCE_VM_IP.

Requisiti e limitazioni

Di seguito sono riportati i requisiti e le limitazioni per i bilanciatori del carico interni.

Requisiti

Il sottoinsieme GKE presenta i seguenti requisiti e limitazioni:

• Puoi abilitare l'impostazione secondaria di GKE nei cluster Standard nuovi ed esistenti in GKE versioni 1.18.19-gke.1400 e successive. Il sottoinsieme GKE non può essere disabilitato dopo essere stato abilitato.
• Il sottoinsieme GKE è disabilitato per impostazione predefinita nei cluster Autopilot. Tuttavia, puoi abilitarlo dopo aver creato il cluster.
• L'impostazione secondaria GKE richiede l'attivazione del componente aggiuntivo HttpLoadBalancing. Questo componente aggiuntivo è attivato per impostazione predefinita. Nei cluster Autopilot, non puoi disattivare questo componente aggiuntivo obbligatorio.
• Si applicano le quote per i gruppi di endpoint di rete. Google Cloud crea un NEG GCE_VM_IP per ogni servizio LoadBalancer interno per zona.
• Si applicano le quote per regole di forwarding, servizi di backend e controlli di integrità. Per maggiori informazioni, consulta Quote e limiti.
• L'impostazione secondaria GKE non può essere utilizzata con l'annotazione per condividere un servizio di backend tra più bilanciatori del carico, alpha.cloud.google.com/load-balancer-backend-share.
• Devi disporre di Google Cloud CLI versione 345.0.0 o successive.

Limitazioni

Bilanciatori del carico di rete passthrough interni

• Per i cluster che eseguono Kubernetes versione 1.7.4 e successive, puoi utilizzare bilanciatori del carico interni con subnet in modalità personalizzata oltre alle subnet in modalità automatica.
• I cluster che eseguono Kubernetes versione 1.7.x e successive supportano l'utilizzo di un indirizzo IP riservato per il bilanciatore del carico di rete passthrough interno se crei l'indirizzo IP riservato con il flag --purpose impostato su SHARED_LOADBALANCER_VIP. Per istruzioni passo passo, consulta la sezione Attivare l'IP condiviso. GKE conserva l'indirizzo IP di un bilanciatore del carico di rete passthrough interno solo se il servizio fa riferimento a un indirizzo IP interno con questo scopo. In caso contrario, GKE potrebbe modificare l'indirizzo IP del bilanciatore del carico (spec.loadBalancerIP) se il servizio viene aggiornato (ad esempio, se le porte vengono modificate).
• Anche se l'indirizzo IP del bilanciatore del carico cambia (vedi il punto precedente), spec.clusterIP rimane costante.
• I bilanciatori del carico UDP interni non supportano l'utilizzo di sessionAffinity: ClientIP.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializzala. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

• Assicurati di avere un cluster Autopilot o Standard esistente. Per creare un nuovo cluster, consulta Crea un cluster Autopilot.

Abilita il sottoinsieme di GKE in un cluster

Puoi abilitare l'impostazione secondaria di GKE per un cluster esistente utilizzando gcloud CLI o la console Google Cloud . Non puoi disattivare il sottoinsieme GKE dopo averlo attivato.

gcloud container clusters update CLUSTER_NAME \
    --enable-l4-ilb-subsetting

L'abilitazione del sottoinsieme GKE non interrompe i servizi LoadBalancer interni esistenti. Se vuoi eseguire la migrazione dei servizi LoadBalancer interni esistenti per utilizzare i servizi di backend con i NEG GCE_VM_IP come backend, devi eseguire il deployment di un manifest del servizio sostitutivo. Per ulteriori dettagli, consulta la sezione Raggruppamento dei nodi nella documentazione sui concetti del servizio LoadBalancer.

Esegui il deployment di un workload

Il seguente manifest descrive un deployment che esegue un'immagine container di esempio dell'applicazione web.

1. Salva il manifest come ilb-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: ilb-deployment
   spec:
     replicas: 3
     selector:
       matchLabels:
         app: ilb-deployment
     template:
       metadata:
         labels:
           app: ilb-deployment
       spec:
         containers:
         - name: hello-app
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

2. Applica il manifest al cluster:

   kubectl apply -f ilb-deployment.yaml
   

Crea un servizio LoadBalancer interno

1. (Facoltativo) Disabilita la creazione automatica delle regole firewall VPC:

   Anche se GKE crea automaticamente regole firewall VPC per consentire il traffico al bilanciatore del carico interno, puoi disattivare la creazione automatica delle regole firewall VPC e gestire le regole firewall autonomamente. Puoi disabilitare le regole firewall VPC solo se hai abilitato l'impostazione secondaria GKE per il tuo servizio LoadBalancer interno. Tuttavia, la gestione delle regole firewall VPC è facoltativa e puoi fare affidamento sulle regole automatiche.

   Prima di disabilitare la creazione automatica delle regole firewall VPC, assicurati di definire regole di autorizzazione che consentano al traffico di raggiungere il bilanciatore del carico e i pod dell'applicazione.

   Per ulteriori informazioni sulla gestione delle regole firewall VPC, consulta Gestisci la creazione automatica delle regole firewall e per informazioni su come disabilitare la creazione automatica delle regole firewall, consulta Regole firewall gestite dall'utente per i servizi LoadBalancer GKE.

2. L'esempio seguente crea un servizio LoadBalancer interno utilizzando la porta TCP 80. GKE esegue il deployment di un bilanciatore del carico di rete passthrough interno la cui regola di forwarding utilizza la porta 80, ma poi inoltra il traffico ai pod di backend sulla porta 8080:

   1. Salva il manifest come ilb-svc.yaml:

      apiVersion: v1
      kind: Service
      metadata:
        name: ilb-svc
        annotations:
          networking.gke.io/load-balancer-type: "Internal"
      spec:
        type: LoadBalancer
        externalTrafficPolicy: Cluster
        selector:
          app: ilb-deployment
        ports:
        - name: tcp-port
          protocol: TCP
          port: 80
          targetPort: 8080
      

      Il manifest deve contenere quanto segue:

      • Un name per il servizio LoadBalancer interno, in questo caso ilb-svc.
      • Un'annotazione che specifica che è necessario un servizio LoadBalancer interno. Per GKE 1.17 e versioni successive, utilizza l'annotazione networking.gke.io/load-balancer-type: "Internal" come mostrato nel manifest di esempio. Per le versioni precedenti, utilizza cloud.google.com/load-balancer-type: "Internal".
      • Il type: LoadBalancer.
      • Un campo spec: selector per specificare i pod a cui deve fare riferimento il servizio, ad esempio app: hello.
      • Informazioni sulla porta:
        • port rappresenta la porta di destinazione su cui la regola di forwarding del bilanciatore del carico di rete passthrough interno riceve i pacchetti.
        • targetPort deve corrispondere a un containerPort definito in ogni pod di pubblicazione.
        • I valori di port e targetPort non devono essere uguali. I nodi eseguono sempre la NAT di destinazione, modificando l'indirizzo IP della regola di forwarding del bilanciatore del carico di destinazione e port in un indirizzo IP del pod di destinazione e targetPort. Per ulteriori dettagli, consulta Traduzione dell'indirizzo di rete di destinazione sui nodi nella documentazione sui concetti del servizio LoadBalancer.

      Il manifest può contenere quanto segue:

      • spec.ipFamilyPolicy e ipFamilies per definire in che modo GKE alloca gli indirizzi IP al servizio. GKE supporta i servizi di bilanciamento del carico IP a stack singolo (solo IPv4 o solo IPv6) o a doppio stack. Un servizio LoadBalancer a doppio stack viene implementato con due regole di forwarding del bilanciatore del carico di rete passthrough interno separate: una per il traffico IPv4 e una per il traffico IPv6. Il servizio LoadBalancer dual-stack GKE è disponibile nella versione 1.29 o successive. Per saperne di più, consulta Servizi dual-stack IPv4/IPv6.

      Per saperne di più, consulta Parametri del servizio LoadBalancer

   2. Applica il manifest al cluster:

      kubectl apply -f ilb-svc.yaml
      

3. Per informazioni dettagliate sul Servizio:

   kubectl get service ilb-svc --output yaml
   

   L'output è simile al seguente:

   apiVersion: v1
   kind: Service
   metadata:
     annotations:
       cloud.google.com/neg: '{"ingress":true}'
       cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
       kubectl.kubernetes.io/last-applied-configuration: |
         {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}}
       networking.gke.io/load-balancer-type: Internal
       service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
       service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw
       service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc
       service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
     creationTimestamp: "2022-07-22T17:26:04Z"
     finalizers:
     - gke.networking.io/l4-ilb-v2
     - service.kubernetes.io/load-balancer-cleanup
     name: ilb-svc
     namespace: default
     resourceVersion: "51666"
     uid: d7a1a865-7972-44e1-aa9e-db5be23d6567
   spec:
     allocateLoadBalancerNodePorts: true
     clusterIP: 10.88.2.141
     clusterIPs:
     - 10.88.2.141
     externalTrafficPolicy: Cluster
     internalTrafficPolicy: Cluster
     ipFamilies:
     - IPv4
     ipFamilyPolicy: SingleStack
     ports:
     - name: tcp-port
       nodePort: 30521
       port: 80
       protocol: TCP
       targetPort: 8080
     selector:
       app: ilb-deployment
     sessionAffinity: None
     type: LoadBalancer
   status:
     loadBalancer:
       ingress:
       - ip: 10.128.15.245
   

   L'output ha i seguenti attributi:

   • L'indirizzo IP della regola di forwarding del bilanciatore del carico di rete passthrough interno è incluso in status.loadBalancer.ingress. Questo indirizzo IP è diverso dal valore di clusterIP. In questo esempio, l'indirizzo IP della regola di forwarding del bilanciatore del carico è 10.128.15.245.
   • Qualsiasi pod con l'etichetta app: ilb-deployment è un pod di pubblicazione per questo servizio. Questi sono i pod che ricevono i pacchetti instradati dal bilanciatore del carico di rete passthrough interno.
   • I client chiamano il servizio utilizzando questo indirizzo IP loadBalancer e la porta di destinazione TCP specificata nel campo port del manifest del servizio. Per informazioni dettagliate su come vengono instradati i pacchetti una volta ricevuti da un nodo, consulta Elaborazione dei pacchetti.
   • GKE ha assegnato un nodePort al servizio; in questo esempio, viene assegnata la porta 30521. nodePort non è pertinente al bilanciatore del carico di rete passthrough interno.

4. Ispeziona il gruppo di endpoint di rete del servizio:

   kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
   

   L'output è simile al seguente:

   {"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}
   

   La risposta indica che GKE ha creato un gruppo di endpoint di rete denominato k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Questa annotazione è presente nei servizi di tipo LoadBalancer che utilizzano il sottoinsieme GKE e non è presente nei servizi che non utilizzano il sottoinsieme GKE.

Verifica i componenti del bilanciatore del carico di rete passthrough interno

L'indirizzo IP della regola di forwarding del bilanciatore del carico di rete passthrough interno è 10.128.15.245 nell'esempio incluso nella sezione Crea un servizio LoadBalancer interno. Puoi vedere che questa regola di forwarding è inclusa nell'elenco delle regole di forwarding nel progetto del cluster utilizzando Google Cloud CLI:

gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"

L'output include la regola di forwarding del bilanciatore del carico di rete passthrough interno pertinente, il relativo indirizzo IP e il servizio di backend a cui fa riferimento la regola di forwarding (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r in questo esempio).

NAME                          ... IP_ADDRESS  ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r

Puoi descrivere il servizio di backend del bilanciatore del carico utilizzando Google Cloud CLI:

gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION

Sostituisci COMPUTE_REGION con la regione di calcolo del servizio di backend.

L'output include il NEG o i NEG di backend GCE_VM_IP per il servizio (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r in questo esempio):

backends:
- balancingMode: CONNECTION
  group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...

Per determinare l'elenco dei nodi in un sottoinsieme per un servizio, utilizza il seguente comando:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
    --zone=COMPUTE_ZONE

Sostituisci quanto segue:

• NEG_NAME: il nome del gruppo di endpoint di rete creato dal controller GKE.
• COMPUTE_ZONE: la zona di calcolo del gruppo di endpoint di rete su cui operare.

Per determinare l'elenco dei nodi integri per un bilanciatore del carico di rete passthrough interno, utilizza il seguente comando:

gcloud compute backend-services get-health SERVICE_NAME \
    --region=COMPUTE_REGION

Sostituisci quanto segue:

• SERVICE_NAME: il nome del servizio di backend. Questo valore è uguale al nome del gruppo di endpoint di rete creato dal controller GKE.
• COMPUTE_REGION: la regione di computing del servizio di backend su cui operare.

Testa la connettività al bilanciatore del carico di rete passthrough interno

Esegui questo comando nella stessa regione del cluster:

curl LOAD_BALANCER_IP:80

Sostituisci LOAD_BALANCER_IP con l'indirizzo IP della regola di forwarding del bilanciatore del carico.

La risposta mostra l'output di ilb-deployment:

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

Il bilanciatore del carico di rete passthrough interno è accessibile solo all'interno della stessa rete VPC (o di una rete connessa). Per impostazione predefinita, la regola di forwarding del bilanciatore del carico ha l'accesso globale disattivato, pertanto le VM client, i tunnel Cloud VPN o gli allegati Cloud Interconnect (VLAN) devono trovarsi nella stessa regione del bilanciatore del carico di rete passthrough interno. Per supportare i client in tutte le regioni, puoi abilitare l'accesso globale nella regola di forwarding del bilanciatore del carico includendo l'annotazione accesso globale nel manifest del servizio.

Elimina il servizio LoadBalancer interno e le risorse del bilanciatore del carico

Puoi eliminare il deployment e il servizio utilizzando kubectl delete o la consoleGoogle Cloud .

kubectl delete deployment ilb-deployment

kubectl delete service ilb-svc

IP condiviso

Il bilanciatore del carico di rete passthrough interno consente la condivisione di un indirizzo IP virtuale tra più regole di forwarding. Ciò è utile per aumentare il numero di porte simultanee sullo stesso IP o per accettare il traffico UDP e TCP sullo stesso IP. Consente un massimo di 50 porte esposte per indirizzo IP. Gli IP condivisi sono supportati in modo nativo sui cluster GKE con servizi LoadBalancer interni. Durante il deployment, il campo loadBalancerIP del servizio viene utilizzato per indicare quale IP deve essere condiviso tra i servizi.

Limitazioni

Un IP condiviso per più bilanciatori del carico presenta le seguenti limitazioni e funzionalità:

• Ogni regola di forwarding può avere fino a cinque porte (contigue o non contigue) oppure può essere configurata per corrispondere e inoltrare il traffico su tutte le porte. Se un servizio Internal LoadBalancer definisce più di cinque porte, la regola di forwarding verrà impostata automaticamente in modo che corrisponda a tutte le porte.
• Un massimo di dieci servizi (regole di forwarding) può condividere un indirizzo IP. In questo modo, si ottengono un massimo di 50 porte per IP condiviso.
• Ogni regola di forwarding che condivide lo stesso indirizzo IP deve utilizzare una combinazione univoca di protocolli e porte. Pertanto, ogni servizio LoadBalancer interno deve utilizzare un insieme univoco di protocolli e porte.
• Una combinazione di servizi solo TCP e solo UDP è supportata sullo stesso IP condiviso, ma non puoi esporre porte TCP e UDP nello stesso servizio.

Abilitazione dell'IP condiviso

Per consentire a un servizio LoadBalancer interno di condividere un IP comune, segui questi passaggi:

1. Crea un IP interno statico con --purpose SHARED_LOADBALANCER_VIP. Per consentire la condivisione, è necessario creare un indirizzo IP con questo scopo. Se crei l'indirizzo IP interno statico in un VPC condiviso, devi crearlo nello stesso progetto di servizio dell'istanza che utilizzerà l'indirizzo IP, anche se il valore dell'indirizzo IP proviene dall'intervallo di IP disponibili in una subnet condivisa selezionata della rete VPC condiviso. Per saperne di più, consulta la sezione Prenotazione di un IP interno statico nella pagina Provisioning di VPC condiviso.

2. Esegui il deployment di un massimo di dieci servizi LoadBalancer interni utilizzando questo IP statico nel campo loadBalancerIP. I bilanciatori del carico di rete passthrough interni vengono riconciliati dal controller di servizio GKE e vengono implementati utilizzando lo stesso IP frontend.

L'esempio seguente mostra come viene eseguita questa operazione per supportare più porte TCP e UDP rispetto allo stesso IP del bilanciatore del carico interno.

1. Crea un IP statico nella stessa regione del cluster GKE. La subnet deve essere la stessa utilizzata dal bilanciatore del carico, che per impostazione predefinita è la stessa utilizzata dagli IP dei nodi del cluster GKE.

   Se il cluster e la rete VPC si trovano nello stesso progetto:

   gcloud compute addresses create IP_ADDR_NAME \
       --project=PROJECT_ID \
       --subnet=SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_REGION \
       --purpose=SHARED_LOADBALANCER_VIP
   

   Se il cluster si trova in un progetto di servizio VPC condiviso, ma utilizza una rete VPC condiviso in un progetto host:

   gcloud compute addresses create IP_ADDR_NAME \
       --project=SERVICE_PROJECT_ID \
       --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET \
       --addresses=IP_ADDRESS \
       --region=COMPUTE_REGION \
       --purpose=SHARED_LOADBALANCER_VIP
   

   Sostituisci quanto segue:

   • IP_ADDR_NAME: un nome per l'oggetto indirizzo IP.
   • SERVICE_PROJECT_ID: l'ID del progetto di servizio.
   • PROJECT_ID: l'ID del tuo progetto (singolo progetto).
   • HOST_PROJECT_ID: l'ID del progetto host VPC condiviso.
   • COMPUTE_REGION: la regione di Compute contenente la subnet condivisa.
   • IP_ADDRESS: un indirizzo IP interno inutilizzato dall'intervallo di indirizzi IP principali della subnet selezionata. Se ometti di specificare un indirizzo IP, Google Cloud seleziona un indirizzo IP interno non utilizzato dall'intervallo di indirizzi IP principali della subnet selezionata. Per determinare un indirizzo selezionato automaticamente, devi eseguire gcloud compute addresses describe.
   • SUBNET: il nome della subnet condivisa.

2. Salva la seguente configurazione del servizio TCP in un file denominato tcp-service.yaml, quindi esegui il deployment nel cluster. Sostituisci IP_ADDRESS con l'indirizzo IP che hai scelto nel passaggio precedente.

   apiVersion: v1
   kind: Service
   metadata:
     name: tcp-service
     namespace: default
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
   spec:
     type: LoadBalancer
     loadBalancerIP: IP_ADDRESS
     selector:
       app: myapp
     ports:
     - name: 8001-to-8001
       protocol: TCP
       port: 8001
       targetPort: 8001
     - name: 8002-to-8002
       protocol: TCP
       port: 8002
       targetPort: 8002
     - name: 8003-to-8003
       protocol: TCP
       port: 8003
       targetPort: 8003
     - name: 8004-to-8004
       protocol: TCP
       port: 8004
       targetPort: 8004
     - name: 8005-to-8005
       protocol: TCP
       port: 8005
       targetPort: 8005
   

3. Applica questa definizione del servizio al tuo cluster:

   kubectl apply -f tcp-service.yaml
   

4. Salva la seguente configurazione del servizio UDP in un file denominato udp-service.yaml e poi eseguine il deployment. Utilizza anche il IP_ADDRESS specificato nel passaggio precedente.

   apiVersion: v1
   kind: Service
   metadata:
     name: udp-service
     namespace: default
     annotations:
       networking.gke.io/load-balancer-type: "Internal"
   spec:
     type: LoadBalancer
     loadBalancerIP: IP_ADDRESS
     selector:
       app: my-udp-app
     ports:
     - name: 9001-to-9001
       protocol: UDP
       port: 9001
       targetPort: 9001
     - name: 9002-to-9002
       protocol: UDP
       port: 9002
       targetPort: 9002
   

5. Applica questo file al tuo cluster:

   kubectl apply -f udp-service.yaml
   

6. Verifica che il VIP sia condiviso tra le regole di forwarding del bilanciatore del carico elencandole e filtrando l'IP statico. Ciò dimostra che esiste una regola di forwarding UDP e una TCP in ascolto su sette porte diverse sul IP_ADDRESS condiviso, che in questo esempio è 10.128.2.98.

   gcloud compute forwarding-rules list | grep 10.128.2.98
   ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
   acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
   

Problemi noti

Timeout della connessione ogni 10 minuti

I servizi LoadBalancer interni creati con il sottoinsieme potrebbero subire interruzioni del traffico circa ogni 10 minuti. Questo bug è stato corretto nelle versioni:

• 1.18.19-gke.1700 e versioni successive
• 1.19.10-gke.1000 e versioni successive
• 1.20.6-gke.1000 e versioni successive

Errore durante la creazione del bilanciatore del carico nel livello Standard

Quando crei un bilanciatore del carico di rete passthrough interno in un progetto con il livello di rete predefinito del progetto impostato su Standard, viene visualizzato il seguente messaggio di errore:

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest

Per risolvere questo problema nelle versioni di GKE precedenti alla 1.23.3-gke.900, configura il livello di rete predefinito del progetto su Premium.

Questo problema è stato risolto nelle versioni di GKE 1.23.3-gke.900 e successive quando è abilitato il sottoinsieme di GKE.

Il controller GKE crea bilanciatori del carico di rete passthrough interni nel livello di rete Premium anche se il livello di rete predefinito del progetto è impostato su Standard.

Passaggi successivi

• Leggi la panoramica della rete GKE.
• Scopri di più sui bilanciatori del carico di Compute Engine.
• Scopri come creare un cluster nativo di VPC.
• Risolvi i problemi di bilanciamento del carico in GKE.
• Scopri di più sull'agente di mascheramento IP.
• Scopri di più sulla configurazione delle reti autorizzate.