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:

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 saperne di più, consulta Appartenenza dei nodi ai backend NEG di GCE_VM_IP.

Utilizzo dell'affinità zonale

Quando abiliti l'affinità di zona in un bilanciatore del carico di rete passthrough interno, GKE instrada il traffico proveniente da una zona a nodi e pod all'interno della stessa zona. Se non sono presenti pod integri nella zona, GKE indirizza il traffico a un'altra zona. Questa implementazione è ottimizzata per latenza e costi.

Per abilitare l'affinità di zona in un cluster GKE, devi aver abilitato l'impostazione secondaria di GKE.

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 le regole di forwarding, i servizi di backend e i 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 avere Google Cloud CLI versione 345.0.0 o successive.

L'affinità di zona presenta i seguenti requisiti:

  • Puoi abilitare l'affinità di zona nei cluster nuovi ed esistenti in GKE versione 1.33.3-gke.1392000 e successive.
  • Devi aver abilitato il sottoinsieme GKE.
  • Devi assicurarti che il componente aggiuntivo HttpLoadBalancing sia abilitato per il tuo cluster. Questo componente aggiuntivo è abilitato per impostazione predefinita e consente al cluster di gestire i bilanciatori del carico che utilizzano i servizi di backend.
  • Devi includere spec.trafficDistribution: PreferClose nel manifest del servizio LoadBalancer.

Il manifest del servizio LoadBalancer può utilizzare externalTrafficPolicy: Local o externalTrafficPolicy: Cluster.

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 inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.

Abilita il subsetting 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.

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

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del cluster.

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 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 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 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
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # 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.
      • 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 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 servizi di bilanciamento del carico IP single-stack (solo IPv4 o solo IPv6) o dual-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 per definire il modo in cui GKE instrada il traffico in entrata (anteprima). Se imposti questo campo su PreferClose, GKE indirizza il traffico proveniente da una zona ai nodi e ai pod all'interno della stessa zona. Se non sono presenti pod integri nella zona, GKE indirizza il traffico a un'altra zona. Se includi questo campo, devi aver attivato il sottoinsieme GKE.

      Per ulteriori informazioni, vedi 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: PreferClose
  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 con il campo impostato su PreferClose.

  • 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 attivato l'affinità a livello di zona:

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

    L'output include il backend GCE_VM_IP NEG o i NEG 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
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 calcolo 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 è 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 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, 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. 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 creare l'indirizzo IP nello stesso progetto di servizio dell'istanza che lo utilizzerà, anche se il valore dell'indirizzo IP proviene 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 distribuiti 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 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 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, 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
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # 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
  # Request an internal load balancer.
  annotations:
    networking.gke.io/load-balancer-type: "Internal"
spec:
  type: LoadBalancer
  # 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 per 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 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