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, crea un servizio di tipo LoadBalancer.
Prima di leggere questa pagina, assicurati di conoscere i seguenti concetti:
- Servizio LoadBalancer.
- Parametri del servizio LoadBalancer.
- Bilanciatore del carico di rete passthrough esterno basato su servizi di backend.
Utilizzo del sottoinsieme del bilanciatore del carico di rete passthrough interno
I bilanciatori del carico di rete passthrough interni rendono i servizi del tuo cluster accessibili ai clienti all'interno della rete VPC del cluster e ai clienti nelle reti collegate alla rete VPC del cluster. I client non devono trovarsi all'interno del cluster. Ad esempio, un servizio LoadBalancer interno può essere accessibile alle istanze di macchine virtuali (VM) situate nella rete VPC del cluster.
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 sottoinsieme GKE è abilitato, 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 di pubblicazione del servizio. Per ulteriori informazioni sul sottoinsieme di GKE, consulta Raggruppamento dei nodi.
Requisiti e limitazioni
Il sottoinsieme GKE presenta i seguenti requisiti e limitazioni:
- Puoi abilitare l'impostazione secondaria GKE nei cluster Standard nuovi ed esistenti nelle versioni GKE 1.18.19-gke.1400 e successive. Il sottoinsieme GKE non può essere disattivato dopo essere stato attivato.
- Il sottoinsieme GKE è disattivato per impostazione predefinita nei cluster Autopilot. Tuttavia, puoi attivarlo durante la creazione del cluster o in un secondo momento.
- L'impostazione secondaria GKE richiede l'attivazione del componente aggiuntivo
HttpLoadBalancing
. Questo componente aggiuntivo è attivo 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
GCE_VM_IP
NEG per servizio LoadBalancer interno per ogni zona. - Si applicano le quote per le regole di inoltro, 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 disporre della versione 345.0.0 o successive di Google Cloud CLI.
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à,
installa e poi
inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo
gcloud components update
.
Abilita l'impostazione secondaria GKE in un nuovo cluster standard
Puoi creare un cluster standard con i sottoinsiemi GKE attivati utilizzando Google Cloud CLI, la console Google Cloud o Terraform. Un cluster creato con l'impostazione secondaria GKE abilitata sempre utilizza l'impostazione secondaria GKE.
Console
Vai alla pagina Google Kubernetes Engine nella console Google Cloud.
Fai clic su add_box Crea.
Configura il cluster come preferisci.
Nel riquadro di navigazione, in Cluster, fai clic su Networking.
Seleziona la casella di controllo Abilita impostazione secondaria per i bilanciatori del carico interni L4.
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 uscita. Il canale di rilascio deve avere una versione predefinita 1.18.19-gke.1400 o successiva.COMPUTE_LOCATION
: la posizione Compute Engine per il cluster.
Se vuoi utilizzare una rete o una sottorete non predefinita, esegui il seguente 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. Nelle versioni GKE 1.22.4-gke.100 e successive, puoi specificare una sottorete in un altro progetto utilizzando l'URL della risorsa completo per questo campo. Puoi ottenere l'URL completo della risorsa utilizzando il comandogcloud compute networks subnets describe
.NETWORK_NAME
: il nome della rete VPC per la subnet.
Terraform
Per creare un cluster standard con il sottoinsieme GKE attivato utilizzando Terraform, consulta il seguente esempio:
Per scoprire di più sull'utilizzo di Terraform, consulta Assistenza di Terraform per GKE.
Abilita l'impostazione secondaria GKE in un cluster standard esistente
Puoi abilitare i sottoinsiemi GKE per un cluster standard esistente utilizzando la gcloud CLI o la console Google Cloud. Non puoi disabilitare il sottoinsieme GKE dopo averlo attivato.
Console
Nella console Google Cloud, vai alla pagina Google Kubernetes Engine.
Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.
In Networking, accanto al campo Impostazione secondaria per bilanciatori del carico interni L4, fai clic su edit Abilita impostazione secondaria per i bilanciatori del carico interni L4.
Seleziona la casella di controllo Abilita impostazione secondaria per i bilanciatori del carico interni L4.
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'attivazione del sottoinsieme GKE non interrompe i servizi LoadBalancer interni esistenti. Se vuoi eseguire la migrazione dei servizi LoadBalancer interni esistenti in modo che utilizzino servizi di backend con NEG GCE_VM_IP
come backend, devi eseguire il deployment di un manifest del servizio sostitutivo. Per ulteriori dettagli, consulta
Raggruppamento dei nodi
nella documentazione relativa ai concetti del servizio LoadBalancer.
Esegui il deployment di un carico di lavoro
Il manifest seguente descrive un deployment che esegue un'immagine container di un'applicazione web di esempio.
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
Applica il manifest al cluster:
kubectl apply -f ilb-deployment.yaml
Creare un servizio LoadBalancer interno
Il seguente esempio crea un servizio LoadBalancer interno che utilizza 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
:
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 casoilb-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, usacloud.google.com/load-balancer-type: "Internal"
. - L'elemento
type: LoadBalancer
. - Un campo
spec: selector
per specificare i pod di destinazione del servizio, ad esempioapp: 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 uncontainerPort
definito su ogni pod di pubblicazione.- I valori
port
etargetPort
non devono essere necessariamente uguali. I nodi eseguono sempre la NAT di destinazione, modificando l'indirizzo IP della regola di forwarding del bilanciatore del carico di destinazione eport
in un indirizzo IP del pod di destinazione etargetPort
. Per ulteriori dettagli, consulta Traduzione dell'indirizzo di rete di destinazione sui nodi nella documentazione relativa ai concetti del servizio LoadBalancer.
Il manifest può contenere quanto segue:
spec.ipFamilyPolicy
eipFamilies
per definire in che modo GKE alloca 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 inoltro del bilanciatore del carico di rete passthrough interno distinte: 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 scoprire di più, consulta Servizi IPv4/IPv6 a doppio stack.
Per ulteriori informazioni, consulta Parametri del servizio LoadBalancer.
- Un
Applica il manifest al cluster:
kubectl apply -f ilb-svc.yaml
Visualizza 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 diclusterIP
. 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. 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 porta di destinazione TCP specificata nel campoport
del manifest del servizio. Per dettagli completi su come i pacchetti vengono instradati una volta ricevuti da un nodo, consulta Elaborazione dei pacchetti. - GKE ha assegnato un
nodePort
al servizio; in questo esempio è assegnata la porta30521
.nodePort
non è pertinente per il bilanciatore del carico di rete passthrough interno.
- L'indirizzo IP della regola di forwarding del bilanciatore del carico di rete passthrough interno è incluso in
Controlla 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 chiamato
k8s2-knlc4c77-default-ilb-svc-ua5ugas0
. Questa annotazione è presente nei servizi di tipoLoadBalancer
che utilizzano il sottoinsieme GKE e non è presente nei servizi che non utilizzano il sottoinsieme GKE.
Verifica i componenti del bilanciatore del carico di rete passthrough interno
L'indirizzo IP della regola di forwarding di inoltro 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 inoltro nel progetto del cluster utilizzando Google Cloud CLI:
gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"
L'output include la regola di forwarding del bilanciatore del carico di rete passthrough interno pertinente, il relativo indirizzo IP e il servizio di backend a cui fa riferimento la regola di forwarding (k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
in questo esempio).
NAME ... IP_ADDRESS ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r 10.128.15.245 ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
Puoi descrivere il servizio di backend del bilanciatore del carico utilizzando Google Cloud CLI:
gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION
Sostituisci COMPUTE_REGION
con la regione di calcolo del servizio di backend.
L'output include il NEG o i NEG GCE_VM_IP
di 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 dei nodi in un sottoinsieme per un servizio, utilizza il seguente comando:
gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
--zone=COMPUTE_ZONE
Sostituisci quanto segue:
NEG_NAME
: il nome del gruppo di endpoint di rete creato dal controller GKE.COMPUTE_ZONE
: la zona di calcolo del gruppo di endpoint di rete su cui eseguire l'operazione.
Per determinare l'elenco dei nodi operativi 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 corrisponde al nome del gruppo di endpoint di rete creato dal controller GKE.COMPUTE_REGION
: la regione di calcolo 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 il seguente comando:
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 collegata). Per impostazione predefinita, la regola di forwarding del bilanciatore del carico ha l'accesso globale disattivato, pertanto le VM client, i tunnel Cloud VPN o i collegamenti VLAN di Cloud Interconnect devono trovarsi nella stessa regione del bilanciatore del carico di rete passthrough interno. Per supportare i client in tutte le regioni, puoi attivare l'accesso globale nella regola di forwarding del bilanciatore del carico includendo l'annotazione accesso globale nel file 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 console Google Cloud.
kubectl
Elimina il deployment
Per eliminare il deployment, esegui il comando seguente:
kubectl delete deployment ilb-deployment
Elimina il servizio
Per eliminare il servizio, esegui il seguente comando:
kubectl delete service ilb-svc
Console
Elimina il deployment
Per eliminare il deployment:
Vai alla pagina Carichi di lavoro nella console Google Cloud.
Seleziona il deployment da eliminare e fai clic su delete Elimina.
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:
Vai alla pagina Servizi e Ingress nella console Google Cloud.
Seleziona il servizio che vuoi eliminare e fai clic su delete Elimina.
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 inoltro.
Questo è utile per espandere il numero di porte simultanee sullo stesso IP o 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 nei 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 associare e inoltrare il traffico su tutte le porte. Se un servizio LoadBalancer interno definisce più di cinque porte, la regola di forwarding verrà impostata automaticamente in modo da corrispondere a tutte le porte.
- Un massimo di dieci servizi (regole di inoltro) 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.
- Sul medesimo IP condiviso è 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
Per consentire a un servizio LoadBalancer interno di condividere un indirizzo IP comune, segui questi passaggi:
Crea un IP interno statico con
--purpose SHARED_LOADBALANCER_VIP
. Per poter essere condiviso, è 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 ulteriori informazioni, consulta la sezione Prenotazione di un indirizzo IP interno statico nella pagina Provisioning di un VPC condiviso.Esegui il deployment di un massimo di dieci servizi LoadBalancer interni utilizzando questo indirizzo IP statico nel
loadBalancerIP
campo. I bilanciatori del carico di rete passthrough interni vengono riconciliati dal controller dei servizi GKE e vengono di cui viene eseguito il deployment utilizzando lo stesso indirizzo IP frontend.
L'esempio seguente mostra come viene eseguita questa operazione per supportare più porte TCP e UDP sullo stesso indirizzo IP del bilanciatore del carico interno.
Crea un IP statico nella stessa regione del tuo 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 calcolo contenente la subnet condivisa.IP_ADDRESS
: un indirizzo IP interno inutilizzato dall'intervallo di indirizzi IP principale della subnet selezionata. Se ometti di specificare 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, dovrai eseguiregcloud compute addresses describe
.SUBNET
: il nome della subnet condivisa.
Salva la seguente configurazione del servizio TCP in un file denominato
tcp-service.yaml
e poi esegui il deployment nel cluster. SostituisciIP_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
Applica questa definizione di servizio al tuo cluster:
kubectl apply -f tcp-service.yaml
Salva la seguente configurazione del servizio UDP in un file denominato
udp-service.yaml
e poi esegui il deployment. Utilizza inoltre il valoreIP_ADDRESS
specificato nel passaggio precedente.apiVersion: v1 kind: Service metadata: name: udp-service namespace: default annotations: networking.gke.io/load-balancer-type: "Internal" spec: type: LoadBalancer loadBalancerIP: IP_ADDRESS selector: app: my-udp-app ports: - name: 9001-to-9001 protocol: UDP port: 9001 targetPort: 9001 - name: 9002-to-9002 protocol: UDP port: 9002 targetPort: 9002
Applica questo file al tuo cluster:
kubectl apply -f udp-service.yaml
Verifica che il VIP sia condiviso tra le regole di inoltro del bilanciatore del carico elencandole e filtrando per l'IP statico. Ciò indica che esistono 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
Restrizioni e limiti
Limitazioni per i 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 suSHARED_LOADBALANCER_VIP
. Per istruzioni dettagliate, consulta 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 a 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 punto precedente), il valore
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 il sottoinsieme potrebbero registrare interruzioni del traffico ogni circa 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 il 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 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
- Leggi la panoramica della rete GKE.
- Scopri di più sui bilanciatori del carico di Compute Engine.
- Scopri come creare un cluster nativo di VPC.
- Risolvi i problemi di bilanciamento del carico in GKE.