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, scopri come creare un servizio di tipo LoadBalancer.

Utilizzo del sottoinsieme del bilanciatore del carico di rete passthrough interno

I bilanciatori del carico di rete passthrough interni rendono i servizi del cluster accessibili ai client all'interno della rete VPC del cluster e ai client nelle reti connesse alla rete VPC del cluster. I client non devono necessariamente trovarsi all'interno del cluster. Ad esempio, un servizio LoadBalancer interno può essere accessibile a istanze di macchine virtuali (VM) situate nella rete VPC del cluster.

Utilizzo dell'impostazione di sottoinsiemi di GKE

L'impostazione di sottoinsiemi di GKE migliora la scalabilità dei servizi LoadBalancer interni perché utilizza GCE_VM_IP gruppi di endpoint di rete (NEG) come backend anziché gruppi di istanze. Quando l'impostazione di sottoinsiemi di GKE è abilitata, GKE crea un NEG per zona di calcolo per servizio LoadBalancer interno. Gli endpoint dei membri nel NEG sono gli indirizzi IP dei nodi che hanno almeno uno dei pod gestiti dal servizio. Per maggiori informazioni sulle sottoimpostazioni di GKE, consulta Raggruppamento dei nodi.

Requisiti e limitazioni

L'impostazione di sottoinsiemi di GKE presenta i seguenti requisiti e limitazioni:

  • Puoi abilitare l'impostazione di sottoinsiemi di GKE in cluster Standard nuovi ed esistenti in GKE versione 1.18.19-gke.1400 e successive. L'impostazione secondaria di GKE non può essere disabilitata dopo essere stata abilitata.
  • La creazione di sottoinsiemi di GKE è sempre abilitata nei cluster Autopilot.
  • L'impostazione di sottoinsiemi di GKE richiede che il componente aggiuntivo HttpLoadBalancing sia abilitato. Questo componente aggiuntivo è attivo per impostazione predefinita. Nei cluster Autopilot, non puoi disabilitare questo componente aggiuntivo obbligatorio.
  • Si applicano quote per i gruppi di endpoint di rete. Google Cloud crea un NEG GCE_VM_IP per servizio LoadBalancer interno per zona.
  • Si applicano le quote per le regole di forwarding, i servizi di backend e i controlli di integrità. Per ulteriori informazioni, consulta Quote e limiti.
  • Non è possibile utilizzare l'impostazione di sottoinsiemi di GKE con l'annotazione per condividere un servizio di backend tra più bilanciatori del carico, alpha.cloud.google.com/load-balancer-backend-share.
  • Devi avere Google Cloud CLI 345.0.0 o versioni successive.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
  • Abilita l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.

Abilita l'impostazione di sottoinsiemi di GKE in un nuovo cluster Standard

Puoi creare un cluster Standard con l'impostazione di sottoinsiemi GKE abilitata utilizzando Google Cloud CLI o la console Google Cloud. Un cluster creato con l'impostazione di sottoinsiemi GKE abilitata utilizza sempre l'impostazione di sottoinsiemi GKE.

Console

  1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud.

    Vai a Google Kubernetes Engine

  2. Fai clic su Crea.

  3. Configura il cluster come preferisci.

  4. Nel riquadro di navigazione, in Cluster, fai clic su Networking.

  5. Seleziona la casella di controllo Abilita impostazione secondaria per i bilanciatori del carico interni L4.

  6. Fai clic su Crea.

gcloud

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-l4-ilb-subsetting \
    --location=COMPUTE_LOCATION

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del nuovo cluster.
  • VERSION: la versione di GKE, che deve essere 1.18.19-gke.1400 o successiva. Puoi anche utilizzare l'opzione --release-channel per selezionare un canale di rilascio. Il canale di rilascio deve avere una versione predefinita 1.18.19-gke.1400 o successive.
  • COMPUTE_LOCATION: la località di Compute Engine per il cluster.

Abilita l'impostazione di sottoinsiemi di GKE in un cluster Standard esistente

Puoi abilitare l'impostazione di sottoinsiemi di GKE per un cluster Standard esistente utilizzando gcloud CLI o la console Google Cloud. Non puoi disabilitare l'impostazione secondaria di GKE dopo averla abilitata.

Console

  1. Nella console Google Cloud, vai alla pagina Google Kubernetes Engine.

    Vai a Google Kubernetes Engine

  2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

  3. In Networking, accanto al campo Impostazione secondaria per i bilanciatori del carico interni L4, fai clic su Abilita impostazione secondaria per i bilanciatori del carico interni L4.

  4. Seleziona la casella di controllo Abilita impostazione secondaria per i bilanciatori del carico interni L4.

  5. Fai clic su Salva modifiche.

gcloud

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

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.

L'abilitazione dell'impostazione di sottoinsiemi di 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 GCE_VM_IP NEG come backend, devi eseguire il deployment di un manifest del servizio sostitutivo. Per maggiori dettagli, consulta Raggruppamento dei nodi nella documentazione sui concetti del servizio LoadBalancer.

Esegui il deployment di un carico di lavoro

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

  1. Salva il file 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 tuo cluster:

    kubectl apply -f ilb-deployment.yaml
    

Crea un servizio LoadBalancer interno

L'esempio seguente crea un servizio LoadBalancer interno utilizzando la porta TCP 8080. GKE esegue il deployment di un bilanciatore del carico di rete passthrough interno la cui regola di forwarding utilizza la porta 8080:

  1. Salva il file 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: 8080
        targetPort: 8080
    

    Il file manifest deve contenere i seguenti elementi:

    • Un name per il servizio LoadBalancer interno, in questo caso ilb-svc.
    • Un'annotazione che specifica che hai bisogno di 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 invece cloud.google.com/load-balancer-type: "Internal".
    • L'elemento type: LoadBalancer.
    • Un campo spec: selector per specificare i pod che il servizio deve scegliere come target, ad esempio app: hello.
    • Informazioni sulla porta:
      • port rappresenta la porta di destinazione sulla quale la regola di forwarding del bilanciatore del carico di rete passthrough interno riceve i pacchetti.
      • targetPort deve corrispondere a un containerPort definito su ciascun pod di pubblicazione.
      • I valori port e targetPort non devono necessariamente essere uguali. I nodi eseguono sempre il 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 maggiori dettagli, consulta Traduzione degli indirizzi di rete di destinazione sui nodi nella documentazione relativa ai concetti del servizio LoadBalancer.

    Il file manifest può contenere i seguenti elementi:

    • spec.ipFamilyPolicy e ipFamilies per definire il modo in cui GKE assegna gli indirizzi IP al servizio. GKE supporta i servizi LoadBalancer 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 a doppio stack di GKE è disponibile nella versione 1.29 o successive. Per scoprire di più, consulta la pagina relativa ai servizi a doppio stack IPv4/IPv6.

    Per maggiori informazioni, consulta Parametri del servizio LoadBalancer

  2. Applica il manifest al tuo cluster:

    kubectl apply -f ilb-svc.yaml
    
  3. Ottieni 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":8080,"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: 8080
        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 gestione per questo servizio. Questi sono i pod che ricevono pacchetti instradati dal bilanciatore del carico di rete passthrough interno.
    • I client chiamano il servizio utilizzando l'indirizzo IP loadBalancer e la porta di destinazione TCP specificata nel campo port del file manifest del servizio. Per dettagli completi sull'instradamento dei pacchetti dopo la ricezione da un nodo, consulta Elaborazione dei pacchetti.
    • GKE ha assegnato un valore nodePort al servizio; in questo esempio è assegnata la porta 30521. nodePort non è pertinente per il bilanciatore del carico di rete passthrough interno.
  4. Esamina 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 l'impostazione secondaria GKE e non è presente nei servizi che non utilizzano l'impostazione secondaria GKE.

Verificare 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 Creare 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 pertinente del bilanciatore del carico di rete passthrough interno, 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 computing del servizio di backend.

L'output include il NEG o i NEG GCE_VM_IP backend 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 di 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 computing del gruppo di endpoint di rete su cui operare.

Per determinare l'elenco di 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

Accedi tramite SSH a un'istanza VM nella stessa rete VPC e nella stessa regione del cluster, quindi esegui questo comando:

curl LOAD_BALANCER_IP

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, l'accesso globale è disabilitato per la regola di forwarding del bilanciatore del carico, di conseguenza le VM client, i tunnel Cloud VPN o i collegamenti 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 sulla regola di forwarding del bilanciatore del carico includendo l'annotazione di accesso globale nel manifest del servizio.

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

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

kubectl

Elimina il deployment

Per eliminare il deployment, esegui questo comando:

kubectl delete deployment ilb-deployment

Elimina il servizio

Per eliminare il servizio, esegui questo comando:

kubectl delete service ilb-svc

Console

Elimina il deployment

Per eliminare il deployment, segui questi passaggi:

  1. Vai alla pagina Carichi di lavoro nella console Google Cloud.

    Vai a Carichi di lavoro

  2. Seleziona il deployment da eliminare, quindi fai clic su Elimina.

  3. Quando ti viene richiesto di confermare, seleziona la casella di controllo Delete Horizontal Pod Autoscaler associato al deployment selezionato, quindi fai clic su Elimina.

Elimina il servizio

Per eliminare il servizio, segui questi passaggi:

  1. Vai alla pagina Servizi e Ingress nella console Google Cloud.

    Vai a Servizi e Ingress

  2. Seleziona il servizio che vuoi eliminare, quindi fai clic su Elimina.

  3. Quando ti viene richiesto di confermare, fai clic su Elimina.

IP condiviso

Il bilanciatore del carico di rete passthrough interno consente la condivisione di un indirizzo IP virtuale tra più regole di forwarding. Questo è utile per espandere il numero di porte simultanee sullo stesso IP o per accettare il traffico UDP e TCP sullo stesso IP. Consente fino a 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 capacità:

  • Ogni servizio (o regola di forwarding) può avere un massimo di cinque porte.
  • Un massimo di dieci servizi (regole di forwarding) possono condividere un indirizzo IP. Ciò comporta 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, tuttavia non puoi esporre entrambe le 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. È necessario creare un indirizzo IP a questo scopo per consentirne la condivisione. Se crei l'indirizzo IP interno statico in un VPC condiviso, devi creare l'indirizzo IP nello stesso progetto di servizio dell'istanza che utilizzerà l'indirizzo IP, anche se il valore dell'indirizzo IP proverrà dall'intervallo di IP disponibili in una subnet condivisa selezionata della rete VPC condivisa. Per ulteriori informazioni, consulta la pagina relativa alla prenotazione di un IP interno statico nella pagina Provisioning del VPC condiviso.

  2. Esegui il deployment di massimo 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 ne viene eseguito il deployment utilizzando lo stesso IP frontend.

L'esempio seguente illustra le operazioni eseguite 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 subnet 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 condivisa 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: 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 del VPC condiviso.
    • COMPUTE_REGION: la regione di computing contenente la subnet condivisa.
    • IP_ADDRESS: un indirizzo IP interno non utilizzato dell'intervallo di indirizzi IP principali della subnet selezionata. Se ometti di specificare un indirizzo IP, Google Cloud seleziona un indirizzo IP interno inutilizzato 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 tuo 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 di 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, quindi eseguine il deployment. Utilizza anche IP_ADDRESS che hai 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. Convalida che il VIP sia condiviso tra le regole di forwarding del bilanciatore del carico elencandole e filtrando l'IP statico. Questo mostra che esiste una regola di forwarding UDP e TCP in ascolto su sette porte diverse sulla IP_ADDRESS condivisa, 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
    

Restrizioni e limiti

Limitazioni per i bilanciatori del carico di rete passthrough interni

  • Per i cluster che eseguono Kubernetes 1.7.4 e versioni successive, puoi utilizzare bilanciatori del carico interni con subnet in modalità personalizzata oltre a subnet in modalità automatica.
  • I cluster che eseguono Kubernetes 1.7.X e versioni 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 dettagliate, consulta Attivazione dell'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. Altrimenti, GKE potrebbe modificare l'indirizzo IP del bilanciatore del carico (spec.loadBalancerIP) se il servizio viene aggiornato (ad esempio in caso di modifica delle porte).
  • Anche se l'indirizzo IP del bilanciatore del carico cambia (vedi il punto precedente), spec.clusterIP rimane costante.

Limitazioni per i bilanciatori del carico UDP interni

  • I bilanciatori del carico UDP interni non supportano l'utilizzo di sessionAffinity: ClientIP.

Problemi noti

Timeout della connessione ogni 10 minuti

I servizi LoadBalancer interni creati con l'impostazione secondaria potrebbero osservare interruzioni del traffico ogni 10 minuti circa. 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 è abilitata l'impostazione dei sottoinsiemi 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