Crea un bilanciatore del carico interno

In questa pagina viene spiegato come creare un'etichetta bilanciatore del carico di rete passthrough interno o carico interno bilanciatore del carico attivato Google Kubernetes Engine (GKE). Per creare un bilanciatore del carico di rete passthrough esterno, scopri come creare un servizio di tipo LoadBalancer.

Utilizzo della configurazione secondaria del bilanciatore del carico di rete passthrough interno

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

Utilizzo dell'impostazione secondaria di GKE

L'impostazione secondaria di GKE migliora la scalabilità del LoadBalancer interno Servizi perché utilizza GCE_VM_IP gruppi di endpoint di rete (NEG) come backend anziché gruppi di istanze. Quando è abilitata l'impostazione secondaria di GKE, GKE crea un NEG per zona di computing per servizio LoadBalancer interno. Gli endpoint membro nel NEG sono gli indirizzi IP dei nodi che hanno almeno uno dei pod di gestione del servizio. Per ulteriori informazioni su GKE vedi Raggruppamento dei nodi.

Requisiti e limitazioni

L'impostazione secondaria di GKE ha i seguenti requisiti e limitazioni:

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

Prima di iniziare

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

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

Abilita la creazione secondaria di GKE in un nuovo cluster Standard

Puoi creare un cluster Standard con l'impostazione secondaria di GKE abilitato utilizzando Google Cloud CLI, la console Google Cloud o Terraform. R un cluster creato con l'impostazione secondaria di GKE abilitata utilizza sempre Creazione secondaria di 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 GKE, che deve essere 1.18.19-gke.1400 o successivo. Puoi anche usare --release-channel per selezionare un canale di rilascio. Il canale di rilascio deve avere un'impostazione predefinita versione 1.18.19-gke.1400 o successiva.
  • COMPUTE_LOCATION: il valore Località di Compute Engine per il cluster.

Se vuoi utilizzare una rete o una subnet non predefinita, esegui questo comando:

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

Sostituisci quanto segue:

  • SUBNET_NAME: il nome della nuova subnet. Nel GKE 1.22.4-gke.100 e versioni successive, puoi specificare una subnet in un progetto diverso utilizzando URL per questo campo. Puoi ottenere l'URL completo della risorsa utilizzando il comando gcloud compute networks subnets describe.
  • NETWORK_NAME: il nome del VPC per la subnet.

Terraform

Creazione di un cluster Standard con sottoinsieme GKE se usi Terraform, consulta l'esempio seguente:

resource "google_container_cluster" "default" {
  name               = "gke-standard-regional-cluster"
  location           = "us-central1"
  initial_node_count = 1

  enable_l4_ilb_subsetting = true

  # Set `deletion_protection` to `true` will ensure that one cannot
  # accidentally delete this instance by use of Terraform.
  deletion_protection = false
}

Per saperne di più sull'utilizzo di Terraform, consulta Supporto Terraform per GKE.

Abilita la creazione secondaria di GKE in un cluster Standard esistente

Puoi abilitare la creazione secondaria di GKE per uno standard esistente utilizzando gcloud CLI o la console Google Cloud. Non puoi disabilita la creazione 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 Nel 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 della sottoinsiezione di GKE non interrompe le applicazioni con i servizi LoadBalancer interni. Se vuoi eseguire la migrazione dei dati interni esistenti Servizi LoadBalancer per utilizzare servizi di backend con GCE_VM_IP NEG come backend, devi eseguire il deployment di un manifest sostitutivo. Per ulteriori dettagli, vedi Raggruppamento dei nodi nella documentazione sui concetti del servizio LoadBalancer.

Esegui il deployment di un carico di lavoro

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

  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

Nell'esempio seguente viene creato un servizio LoadBalancer interno utilizzando TCP porta 80. GKE esegue il deployment di un bilanciatore del carico di rete passthrough interno la 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 file 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 nell'esempio del file manifest. Per le versioni precedenti, utilizza cloud.google.com/load-balancer-type: "Internal" in alternativa.
    • L'elemento type: LoadBalancer.
    • Un campo spec: selector per specificare i pod che il servizio deve scegliere come target, ad esempio app: hello.
    • Informazioni porta:
      • port rappresenta la porta di destinazione su cui viene utilizzata la regola di forwarding del bilanciatore del carico di rete passthrough interno riceve pacchetti.
      • Il targetPort deve corrispondere a un valore containerPort definito su ogni di gestione dei dati nel pod.
      • I valori port e targetPort non devono essere necessariamente uguali. Nodi eseguire sempre la destinazione NAT, modificando il bilanciatore del carico di destinazione l'indirizzo IP della regola di forwarding e port all'indirizzo IP di un pod di destinazione e targetPort. Per ulteriori dettagli, consulta Indirizzo rete di destinazione Traduzione sui nodi nella documentazione sui concetti del servizio LoadBalancer.

    Il file manifest può contenere quanto segue:

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

    Per ulteriori informazioni, vedi Parametri del servizio LoadBalancer

  2. Applica il manifest al cluster:

    kubectl apply -f ilb-svc.yaml

  3. Ricevere 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 assistenza. Si tratta dei 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 rete TCP alla porta di destinazione specificata nel campo port del manifest del servizio. Per per tutti i dettagli su come i pacchetti vengono indirizzati una volta ricevuti da un nodo, vedi Elaborazione dei pacchetti.
    • GKE ha assegnato un nodePort al servizio. in questo esempio, la porta 30521 è assegnato. nodePort non è pertinente per il bilanciatore del carico di rete passthrough interno.

  4. Controlla il gruppo di endpoint di rete dei servizi:

    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 endpoint di rete gruppo denominato k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Questa annotazione è presenti nei servizi di tipo LoadBalancer che utilizzano GKE la creazione di sottoinsiemi e non è presente nei servizi che non utilizzano GKE la creazione di sottoinsiemi.

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 in l'esempio incluso in Crea un servizio LoadBalancer interno . Puoi vedere che questa regola di forwarding è inclusa nell'elenco dei 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 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 regione di computing del servizio di backend.

L'output include il NEG o il 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 di nodi in un sottoinsieme di un servizio, usa quanto segue :

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: il valore zona di computing dell'endpoint di rete su cui lavorare.

Per determinare l'elenco di nodi integri per un bilanciatore del carico di rete passthrough interno, utilizza 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 corrisponde al nome del gruppo di endpoint di rete creato un controller GKE.
  • COMPUTE_REGION: il valore regione di computing del 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 della stessa regione del cluster, quindi esegui questo comando:

curl LOAD_BALANCER_IP:80

Sostituisci LOAD_BALANCER_IP con il valore del bilanciatore del carico della regola di forwarding.

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 dello stesso VPC (o una rete connessa). Per impostazione predefinita, la regola di forwarding del bilanciatore del carico ha l'accesso globale disabilitato, quindi il client VM, tunnel Cloud VPN o collegamenti di Cloud Interconnect (VLAN) devono trovarsi nella stessa regione del bilanciatore del carico di rete passthrough interno. A in tutte le regioni, puoi abilitare l'accesso globale la regola di forwarding del bilanciatore del carico includendo l'accesso globale nel file 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 nella 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 e fai clic su Elimina.

  3. Quando ti viene chiesto 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 scheda Servizi e pagina in entrata nella console Google Cloud.

    Vai a Servizi e In entrata

  2. Seleziona il servizio che vuoi eliminare e 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 condivisione di un indirizzo IP virtuale tra più regole di forwarding. È utile per espandere il numero di porte simultanee sullo stesso IP. per accettare 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 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 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. Questo può generare 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 set univoco di protocolli e porte.
  • Sulla stessa piattaforma è supportata una combinazione di servizi solo TCP e solo UDP ma non puoi esporre entrambe le porte TCP e UDP nello stesso servizio.

Abilitazione dell'IP condiviso in corso...

Per abilitare un servizio LoadBalancer interno per condividere un IP comune, segui questi passaggi passaggi:

  1. Crea un IP interno statico con --purpose SHARED_LOADBALANCER_VIP. Un IP indirizzo deve essere creato a questo scopo per consentirne la condivisione. Se crei l'indirizzo IP interno statico in un VPC condiviso, devi creare l'indirizzo IP nel lo stesso progetto di servizio dell'istanza che utilizzerà l'indirizzo IP, anche se il valore di indirizzi IP proverranno dall'intervallo di IP disponibili in un una subnet condivisa della rete VPC condiviso. Consulta la sezione sulla prenotazione di un IP interno statico per saperne di più, consulta la pagina Provisioning condiviso VPC.

  2. Esegui il deployment di massimo dieci servizi LoadBalancer interni utilizzando questo IP statico nella campo loadBalancerIP. I bilanciatori del carico di rete passthrough interni sono stati riconciliati dal controller di servizio GKE ed eseguire il deployment usando lo stesso IP frontend.

L'esempio seguente illustra come supportare questa operazione per supportare più porte TCP e porte UDP sullo 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 predefinita è la stessa subnet utilizzata dal cluster GKE IP dei nodi.

    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 del VPC condiviso, ma utilizza un 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 dell'indirizzo IP.
    • SERVICE_PROJECT_ID: l'ID del progetto di servizio.
    • PROJECT_ID: l'ID del tuo progetto (progetto singolo).
    • HOST_PROJECT_ID: l'ID del VPC condiviso progetto host.
    • COMPUTE_REGION: il valore regione di computing contenente una subnet condivisa.
    • IP_ADDRESS: un indirizzo IP interno non utilizzato da all'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 automaticamente l'indirizzo selezionato, dovrai 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 nella 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 nel cluster:

    kubectl apply -f tcp-service.yaml

  4. Salva la seguente configurazione del servizio UDP in un file denominato udp-service.yaml per poi eseguirne 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. Verifica che il VIP sia condiviso tra le regole di forwarding del bilanciatore del carico elencandole e filtrando l'IP statico. Questo dimostra che c'è UDP e una regola di forwarding TCP in ascolto su sette diverse porte l'elemento 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

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 in modalità personalizzata, oltre in modalità automatica.
  • I cluster che eseguono Kubernetes 1.7.X e versioni successive supportano l'uso di un Indirizzo IP del bilanciatore del carico di rete passthrough interno se crei il bilanciatore del carico riservato Indirizzo IP con --purpose impostato su SHARED_LOADBALANCER_VIP. Vedi Abilitazione dell'IP condiviso per ricevere indicazioni stradali passo passo. GKE conserva solo l'indirizzo IP di un bilanciatore del carico di rete passthrough interno se il servizio fa riferimento a un IP interno indirizzo con tale scopo. In caso contrario, GKE potrebbe modificare indirizzo IP del bilanciatore del carico (spec.loadBalancerIP) se il servizio viene aggiornato (ad esempio se le porte sono cambiate).
  • Anche se l'indirizzo IP del bilanciatore del carico cambia (vedi punto precedente), spec.clusterIP rimane costante.

Restrizioni 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 il traffico interruzioni ogni 10 minuti circa. Questo bug è stato risolto 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 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 il problema nelle versioni di GKE precedenti a 1.23.3-gke.900, configurare il livello di rete predefinito del progetto su Premium.

Questo problema viene risolto nelle versioni GKE 1.23.3-gke.900 e in un secondo momento, quando sarà abilitata l'impostazione secondaria di GKE.

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

Passaggi successivi