Crea un bilanciatore del carico interno

Questa pagina mostra come eseguire il deployment di un servizio LoadBalancer interno che crea un bilanciatore del carico di rete passthrough interno. Prima di leggere questa pagina, assicurati di avere familiarità con quanto segue:

Per saperne di più sui bilanciatori del carico di rete passthrough interni in generale, consulta la panoramica del bilanciatore del carico di rete passthrough interno.

Prima di iniziare

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

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  • Assicurati di avere un cluster Autopilot o Standard esistente. Per creare un nuovo cluster, vedi Crea un cluster Autopilot.

Requisiti

  • Questo tutorial utilizza spec.loadBalancerClass per creare un bilanciatore del carico di rete passthrough interno con backend NEG GCE_VM_IP. Questo tutorial richiede GKE 1.33.1-gke.1779000 o versioni successive perché spec.loadBalancerClass richiede GKE 1.33.1-gke.1779000 o versioni successive.

  • L'affinità di zona richiede GKE 1.33.3-gke.1392000 e versioni successive.

  • Nel cluster deve essere abilitato il sottoinsieme GKE:

    • L'impostazione secondaria di GKE è abilitata per impostazione predefinita nei cluster che eseguono la versione 1.36 e successive. Per queste versioni, il sottoinsieme è attivo indipendentemente dal valore del flag del sottoinsieme del cluster.

    • Nelle versioni GKE supportate precedenti alla 1.36, devi abilitare esplicitamente il sottoinsieme GKE. Puoi abilitare l'impostazione secondaria di GKE quando crei un nuovo cluster o aggiornandone uno esistente. Una volta abilitata, il sottoinsieme GKE non può essere disattivato. Per maggiori informazioni, consulta Verificare e attivare il sottoinsieme di GKE.

  • Se il cluster utilizza una versione precedente alla 1.36, l'addon HttpLoadBalancing deve essere abilitato nel cluster. Questo componente aggiuntivo è attivato per impostazione predefinita.

Verifica e abilita l'impostazione secondaria GKE

Assicurati che il sottoinsieme GKE sia abilitato:

  • L'impostazione secondaria di GKE è sempre abilitata in GKE versione 1.36 e successive.

  • Puoi abilitare manualmente l'impostazione secondaria di GKE nei cluster Standard e Autopilot nuovi ed esistenti che eseguono GKE versione 1.18.19-gke.1400 e successive, ma prima della versione 1.36 di GKE. Non puoi disattivare il sottoinsieme GKE dopo averlo attivato.

Per informazioni sul motivo per cui il sottoinsieme GKE è importante, consulta Considerazioni speciali per i servizi LoadBalancer interni.

Per determinare se il sottoinsieme GKE è abilitato, esegui questo comando:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="get(currentMasterVersion, networkConfig.enableL4ilbSubsetting)"

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • LOCATION : la zona o la regione del cluster.

L'output del comando mostra la versione del control plane del cluster seguita da True o False per l'attributo networkConfig.enableL4ilbSubsetting. Interpreta l'output nel seguente modo:

  • Se la versione del control plane è 1.36 o successive, il sottoinsieme GKE è abilitato indipendentemente dal fatto che l'attributo networkConfig.enableL4ilbSubsetting sia True o False.
  • Se la versione del control plane è precedente alla 1.36:
    • True significa che l'impostazione secondaria GKE è abilitata.
    • False significa che il sottoinsieme di GKE è disattivato.

Per abilitare l'impostazione secondaria di GKE in un cluster che esegue GKE versione 1.18.19-gke.1400 e successive, ma precedente alla versione 1.36 di GKE, utilizza gcloud CLI o la console Google Cloud .

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 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 \
    --location=LOCATION
    --enable-l4-ilb-subsetting

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.
  • LOCATION : la zona o la regione del cluster.

L'attivazione del sottoinsieme GKE, utilizzando gcloud CLI, la consoleGoogle Cloud o l'upgrade del cluster alla versione 1.36 o successive, non modifica i servizi LoadBalancer interni esistenti. Se vuoi eseguire la migrazione di un servizio LoadBalancer interno esistente per utilizzare i backend NEG GCE_VM_IP, devi eseguire il deployment di un manifest del servizio di sostituzione.

Esegui il deployment di un workload

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

  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, hai la possibilità di disabilitare 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 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 saperne di più sulla gestione delle regole firewall VPC, consulta Gestisci la creazione automatica delle regole firewall. 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
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Evenly route external traffic to all endpoints.
  externalTrafficPolicy: Cluster
  # Prioritize routing traffic to endpoints that are in the same zone.
  trafficDistribution: PreferClose
  selector:
    app: ilb-deployment
  # Forward traffic from TCP port 80 to port 8080 in backend Pods.
  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.
      • Il campo spec.loadBalancerClass impostato sul valore networking.gke.io/l4-regional-internal per specificare un servizio LoadBalancer interno, come mostrato nel manifest di esempio.
      • 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 maggiori 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ù, vedi Servizi dual-stack IPv4/IPv6.

      • spec.trafficDistribution (anteprima) per definire il modo in cui GKE instrada il traffico in entrata. Per attivare l'affinità di zona, imposta il valore di questo campo su PreferSameZone. L'affinità di zona significa che GKE dà la priorità al routing del traffico proveniente da una zona a nodi e pod all'interno della stessa zona. Se in quella zona non sono disponibili pod integri, il traffico viene indirizzato a un'altra zona. Per le versioni del cluster precedenti a 1.35.0-gke.1811000, utilizza PreferClose come valore. L'affinità di zona richiede l'attivazione del sottoinsieme GKE.

      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
    # Kubernetes automatically allocates a port on the node during the
    # process of implementing a Service of type LoadBalancer.
    nodePort: 30521
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: ilb-deployment
  sessionAffinity: None
  trafficDistribution: PreferSameZone
  type: LoadBalancer
status:
  # IP address of the load balancer forwarding rule.
  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 complete 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, è 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

Questa sezione mostra come verificare i componenti chiave del bilanciatore del carico di rete passthrough interno.

  • Verifica che il servizio sia in esecuzione:

    kubectl get service SERVICE_NAME --output yaml

    Sostituisci SERVICE_NAME con il nome del manifest del servizio.

    Se hai attivato l'affinità di zona, l'output include il parametro spec.trafficDistribution. Il valore di questo campo è impostato su PreferSameZone o PreferClose se la versione del cluster è precedente alla 1.35.0-gke.1811000.

  • Verifica l'indirizzo IP della regola di forwarding 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. Verifica che questa regola di forwarding sia 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

  • Descrivi 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.

    Se hai abilitato l'affinità di zona:

    • Il campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover deve essere impostato sul valore ZONAL_AFFINITY_SPILL_CROSS_ZONE.
    • Il campo networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio deve essere impostato su 0 o non essere incluso.

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

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

    Se hai disattivato l'affinità di zona, il campo networkPassThroughLbTrafficPolicy.zonalAffinity.spillover deve essere impostato su ZONAL_AFFINITY_DISABLED o non essere incluso. Tieni presente che l'affinità di zona viene disattivata automaticamente se il cluster utilizza una versione precedente alla 1.33.3-gke.1392000.

  • Determina l'elenco dei nodi in un sottoinsieme per un servizio:

    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.

  • Determina l'elenco dei nodi integri per un bilanciatore del carico di rete passthrough interno:

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

    Sostituisci quanto segue:

    • SERVICE_NAME: il nome del servizio di backend. Questo valore corrisponde 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 disabilitato, quindi 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 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

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 la deployment:

  1. Vai alla pagina Workload nella console Google Cloud .

    Vai a Carichi di lavoro

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

  3. Quando ti viene chiesto di confermare, seleziona la casella di controllo Elimina Horizontal Pod Autoscaler con associazione a 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, poi 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. 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 trovare una corrispondenza 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 proverrà dall'intervallo di IP disponibili in una subnet condivisa selezionata della rete VPC condivisa. 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 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: un nome per l'oggetto indirizzo IP.
    • SERVICE_PROJECT_ID: l'ID del progetto di servizio.
    • PROJECT_ID: l'ID del progetto (singolo progetto).
    • HOST_PROJECT_ID: l'ID del progetto host del VPC condiviso.
    • COMPUTE_REGION: la regione di Compute contenente la subnet condivisa.
    • IP_ADDRESS: un indirizzo IP interno non utilizzato dall'intervallo di indirizzi IP primario della subnet selezionata. Se ometti la specifica di un indirizzo IP, Google Cloud seleziona un indirizzo IP interno non utilizzato dall'intervallo di indirizzi IP principale 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 e poi 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
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Use an IP address that you create.
  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 IP_ADDRESS specificato nel passaggio precedente.

    apiVersion: v1
kind: Service
metadata:
  name: udp-service
  namespace: default
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Use the same IP address that you used for the TCP Service.
  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 che ascoltano 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

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