Questa pagina spiega come utilizzare il bilanciamento del carico nativo del container in Google Kubernetes Engine (GKE). Il bilanciamento del carico nativo del container consente ai bilanciatori del carico di scegliere direttamente come target i pod Kubernetes e di distribuire il traffico ai pod in modo uniforme.
Per ulteriori informazioni su vantaggi, requisiti e limitazioni del bilanciamento del carico nativo del container, consulta Bilanciamento del carico nativo del container.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Abilita l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo
gcloud components update
.
Utilizza il bilanciamento del carico nativo del container
Le sezioni seguenti illustrano la configurazione del bilanciamento del carico nativo del container su GKE. Tieni presente che per i cluster GKE che eseguono la versione 1.17 o successive e in determinate condizioni, il bilanciamento del carico nativo del container è predefinito e non richiede un'annotazione del servizio cloud.google.com/neg: '{"ingress": true}'
esplicita.
Crea un cluster nativo di VPC
Per utilizzare il bilanciamento del carico nativo del container, nel cluster GKE deve essere abilitato gli IP alias.
Ad esempio, il comando seguente crea un cluster GKE, neg-demo-cluster
, con una subnet di cui è stato eseguito il provisioning automatico:
Per la modalità Autopilot, gli indirizzi IP alias sono abilitati per impostazione predefinita:
gcloud container clusters create-auto neg-demo-cluster \ --location=COMPUTE_LOCATION
Sostituisci
COMPUTE_LOCATION
con la località di Compute Engine per il cluster.
Per la modalità Standard, abilita gli indirizzi IP alias quando crei il cluster:
gcloud container clusters create neg-demo-cluster \ --enable-ip-alias \ --create-subnetwork="" \ --network=default \ --zone=us-central1-a
Creazione di un deployment
Il seguente
deployment
neg-demo-app
di esempio esegue una singola istanza di un server HTTP containerizzato. Ti consigliamo di utilizzare carichi di lavoro che usano il feedback relativo all'idoneità dei pod.
Utilizzo del feedback sull'idoneità dei pod
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname # Container name ports: - containerPort: 9376 protocol: TCP
Utilizzo del ritardo impostato come hardcoded
apiVersion: apps/v1 kind: Deployment metadata: labels: run: neg-demo-app # Label for the Deployment name: neg-demo-app # Name of Deployment spec: minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready selector: matchLabels: run: neg-demo-app template: # Pod template metadata: labels: run: neg-demo-app # Labels Pods from this Deployment spec: # Pod specification; each Pod created by this Deployment has this specification containers: - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods name: hostname # Container name # Note: The following line is necessary only on clusters running GKE v1.11 and lower. # For details, see https://cloud.google.com/kubernetes-engine/docs/how-to/container-native-load-balancing#align_rollouts ports: - containerPort: 9376 protocol: TCP terminationGracePeriodSeconds: 60 # Number of seconds to wait for connections to terminate before shutting down Pods
In questo deployment, ogni container esegue un server HTTP. Il server HTTP restituisce come risposta il nome host del server delle applicazioni (il nome del pod su cui viene eseguito il server).
Salva il manifest come neg-demo-app.yaml
, quindi crea il deployment:
kubectl apply -f neg-demo-app.yaml
Creazione di un servizio per un bilanciatore del carico nativo del container
Dopo aver creato un deployment, devi raggruppare i suoi pod in un servizio.
Il seguente servizio di esempio, neg-demo-svc
, ha come target il deployment di esempio che hai creato nella sezione precedente:
apiVersion: v1
kind: Service
metadata:
name: neg-demo-svc # Name of Service
annotations:
cloud.google.com/neg: '{"ingress": true}' # Creates a NEG after an Ingress is created
spec: # Service's specification
type: ClusterIP
selector:
run: neg-demo-app # Selects Pods labelled run: neg-demo-app
ports:
- name: http
port: 80 # Service's port
protocol: TCP
targetPort: 9376
L'annotazione del servizio, cloud.google.com/neg: '{"ingress": true}'
, consente il bilanciamento del carico nativo del container. Tuttavia, il bilanciatore del carico non viene creato finché non crei una risorsa Ingress per il servizio.
Salva il manifest come neg-demo-svc.yaml
, quindi crea il servizio:
kubectl apply -f neg-demo-svc.yaml
Crea una risorsa Ingress per il servizio
Il seguente esempio di codice
In entrata,
neg-demo-ing
, ha come target il servizio che hai creato:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: neg-demo-ing
spec:
defaultBackend:
service:
name: neg-demo-svc # Name of the Service targeted by the Ingress
port:
number: 80 # Should match the port used by the Service
Salva il manifest come neg-demo-ing.yaml
, quindi crea l'oggetto Ingress:
kubectl apply -f neg-demo-ing.yaml
Dopo aver creato la risorsa Ingress, nel progetto viene creato un bilanciatore del carico delle applicazioni e i gruppi di endpoint di rete(NEG) vengono creati in ogni zona in cui viene eseguito il cluster. Gli endpoint nel NEG e gli endpoint del servizio vengono mantenuti sincronizzati.
Verifica il traffico in entrata
Dopo aver eseguito il deployment di un carico di lavoro, aver raggruppato i relativi pod in un servizio e creato una risorsa Ingress per il servizio, devi verificare che il provisioning del bilanciatore del carico nativo del container sia stato eseguito correttamente da Ingress.
Recupera lo stato dell'Ingress:
kubectl describe ingress neg-demo-ing
L'output include eventi ADD
e CREATE
:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ADD 16m loadbalancer-controller default/neg-demo-ing
Normal Service 4s loadbalancer-controller default backend set to neg-demo-svc:32524
Normal CREATE 2s loadbalancer-controller ip: 192.0.2.0
Testa il bilanciatore del carico
Le seguenti sezioni spiegano come testare la funzionalità di un bilanciatore del carico nativo del container.
Visita indirizzo IP Ingress
Attendi alcuni minuti per la configurazione del bilanciatore del carico delle applicazioni.
Puoi verificare che il bilanciatore del carico nativo del container funzioni visitando l'indirizzo IP di Ingress.
Per ottenere l'indirizzo IP Ingress, esegui questo comando:
kubectl get ingress neg-demo-ing
Nell'output comando, l'indirizzo IP in entrata viene visualizzato nella colonna ADDRESS
. Visita l'indirizzo IP in un browser web.
Controlla lo stato di integrità del servizio di backend
Puoi anche ottenere lo stato di integrità del servizio di backend del bilanciatore del carico.
Ottieni un elenco dei servizi di backend in esecuzione nel tuo progetto:
gcloud compute backend-services list
Registra il nome del servizio di backend che include il nome del servizio, ad esempio
neg-demo-svc
.Recupera lo stato di integrità del servizio di backend:
gcloud compute backend-services get-health BACKEND_SERVICE_NAME --global
Sostituisci
BACKEND_SERVICE_NAME
con il nome del servizio di backend.
Testa Ingress
Un altro modo per verificare che il bilanciatore del carico funzioni come previsto consiste nello scalare il deployment di esempio, inviare richieste di test a Ingress e verificare che il numero corretto di repliche risponda.
Scala il deployment
neg-demo-app
da un'istanza a due istanze:kubectl scale deployment neg-demo-app --replicas 2
Il completamento di questo comando potrebbe richiedere diversi minuti.
Verifica che l'implementazione sia stata completata:
kubectl get deployment neg-demo-app
L'output dovrebbe includere due repliche disponibili:
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE neg-demo-app 2 2 2 2 26m
Recupera l'indirizzo IP in entrata:
kubectl describe ingress neg-demo-ing
Se questo comando restituisce un errore 404, attendi qualche minuto per l'avvio del bilanciatore del carico, quindi riprova.
Conta il numero di risposte distinte dal bilanciatore del carico:
for i in `seq 1 100`; do \ curl --connect-timeout 1 -s IP_ADDRESS && echo; \ done | sort | uniq -c
Sostituisci
IP_ADDRESS
con l'indirizzo IP in entrata.L'output è simile al seguente:
44 neg-demo-app-7f7dfd7bc6-dcn95 56 neg-demo-app-7f7dfd7bc6-jrmzf
In questo output, il numero di risposte distinte corrisponde al numero di repliche, il che indica che tutti i pod di backend gestiscono il traffico.
Esegui la pulizia
Dopo aver completato le attività in questa pagina, segui questi passaggi per rimuovere le risorse ed evitare addebiti indesiderati sul tuo account:
Elimina il cluster
gcloud
gcloud container clusters delete neg-demo-cluster
Console
Vai alla pagina Google Kubernetes Engine nella console Google Cloud.
Seleziona neg-demo-cluster e fai clic su delete Elimina.
Quando ti viene richiesto di confermare, fai clic su Elimina.
Risoluzione dei problemi
Utilizza le tecniche riportate di seguito per verificare la configurazione del networking. Le seguenti sezioni spiegano come risolvere problemi specifici relativi al bilanciamento del carico nativo del container.
Consulta la documentazione sul bilanciamento del carico per informazioni su come elencare i gruppi di endpoint di rete.
Puoi trovare il nome e le zone del NEG corrispondente a un servizio nell'annotazione
neg-status
del servizio. Ottieni la specifica del servizio con:kubectl get svc SVC_NAME -o yaml
L'annotazione
metadata:annotations:cloud.google.com/neg-status
elenca il nome del NEG corrispondente al servizio e le zone del NEG.Puoi controllare l'integrità del servizio di backend che corrisponde a un NEG con il seguente comando:
gcloud compute backend-services --project PROJECT_NAME \ get-health BACKEND_SERVICE_NAME --global
Il servizio di backend ha lo stesso nome del suo NEG.
Per stampare i log eventi di un servizio:
kubectl describe svc SERVICE_NAME
La stringa del nome del servizio include il nome e lo spazio dei nomi del servizio GKE corrispondente.
Impossibile creare un cluster con IP alias
- Sintomi
Quando provi a creare un cluster con IP alias, potresti riscontrare il seguente errore:
ResponseError: code=400, message=IP aliases cannot be used with a legacy network.
- Potenziali cause
Questo errore si verifica se tenti di creare un cluster con IP alias che utilizza anche una rete legacy.
- Risoluzione
Assicurati di non creare un cluster con IP alias e una rete legacy abilitata contemporaneamente. Per saperne di più sull'utilizzo di IP alias, consulta Creare un cluster nativo di VPC.
Il traffico non raggiunge gli endpoint
- Sintomi
- Errori 502 o connessioni rifiutate.
- Potenziali cause
In genere, i nuovi endpoint diventano raggiungibili dopo averli collegati al bilanciatore del carico, a condizione che rispondano ai controlli di integrità. Potresti riscontrare errori 502 o connessioni rifiutate se il traffico non può raggiungere gli endpoint.
Gli errori 502 e le connessioni rifiutate possono essere causati anche da un container che non gestisce
SIGTERM
. Se un container non gestisceSIGTERM
in modo esplicito, termina immediatamente e interrompe la gestione delle richieste. Il bilanciatore del carico continua a inviare il traffico in entrata al container terminato, causando errori.Il bilanciatore del carico nativo del container ha un solo endpoint di backend. Durante un aggiornamento in sequenza, il vecchio endpoint viene deprogrammato prima della programmazione di quello nuovo.
Il deployment dei pod di backend viene eseguito in una nuova zona per la prima volta dopo il provisioning di un bilanciatore del carico nativo del container. L'infrastruttura del bilanciatore del carico è programmata in una zona quando è presente almeno un endpoint. Quando un nuovo endpoint viene aggiunto a una zona, l'infrastruttura del bilanciatore del carico è programmata e causa interruzioni del servizio.
- Risoluzione
Configura i container per gestire
SIGTERM
e continuare a rispondere alle richieste durante il periodo di tolleranza per la terminazione (30 secondi per impostazione predefinita). Configura i pod in modo che inizino a non superare i controlli di integrità quando ricevonoSIGTERM
. Questo indica al bilanciatore del carico di interrompere l'invio del traffico al pod mentre è in corso la deprogrammazione dell'endpoint.Se l'applicazione non si arresta automaticamente e smette di rispondere alle richieste quando riceve un elemento
SIGTERM
, è possibile utilizzare l'hook di preStop per gestireSIGTERM
e continuare a gestire il traffico mentre è in corso la deprogrammazione dell'endpoint.lifecycle: preStop: exec: # if SIGTERM triggers a quick exit; keep serving traffic instead command: ["sleep","60"]
Consulta la documentazione sulla terminazione dei pod.
Se il backend del bilanciatore del carico ha una sola istanza, configura la strategia di implementazione per evitare di danneggiare l'unica istanza prima che la nuova istanza sia completamente programmata. Per i pod dell'applicazione gestiti dal carico di lavoro
Deployment
, è possibile eseguire questa operazione configurando la strategia di implementazione con il parametromaxUnavailable
uguale a0
.strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0
Per risolvere i problemi del traffico che non raggiunge gli endpoint, verifica che le regole firewall consentano il traffico TCP in entrata verso i tuoi endpoint negli intervalli
130.211.0.0/22
e35.191.0.0/16
. Per saperne di più, consulta Aggiunta dei controlli di integrità nella documentazione di Cloud Load Balancing.Visualizza i servizi di backend nel tuo progetto. La stringa del nome del servizio di backend pertinente include il nome e lo spazio dei nomi del servizio GKE corrispondente:
gcloud compute backend-services list
Recupera lo stato di integrità del backend dal servizio di backend:
gcloud compute backend-services get-health BACKEND_SERVICE_NAME
Se tutti i backend sono in stato non integro, il firewall, il traffico in entrata o il servizio potrebbero essere configurati in modo errato.
Se alcuni backend sono in stato non integro per un breve periodo di tempo, la causa potrebbe essere la latenza della programmazione di rete.
Se alcuni backend non sono visualizzati nell'elenco dei servizi di backend, la latenza di programmazione potrebbe essere la causa. Puoi verificarlo eseguendo questo comando, dove
NEG_NAME
è il nome del servizio di backend. (NEG e servizi di backend condividono lo stesso nome):gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME
Controlla se tutti gli endpoint previsti sono nel NEG.
Se hai un numero ridotto di backend (ad esempio, un pod) selezionato da un bilanciatore del carico nativo del container, valuta la possibilità di aumentare il numero di repliche e di distribuire i pod di backend in tutte le zone distribuite dal cluster GKE. Ciò garantisce che l'infrastruttura sottostante del bilanciatore del carico sia completamente programmata. In caso contrario, valuta la possibilità di limitare i pod di backend a una singola zona.
Se configuri un criterio di rete per l'endpoint, assicurati che il traffico in entrata dalla subnet solo proxy sia consentito.
Implementazione bloccata
- Sintomi
- L'implementazione di un deployment aggiornato si blocca e il numero di repliche aggiornate non corrisponde al numero di repliche desiderato.
- Potenziali cause
I controlli di integrità del deployment non sono riusciti. L'immagine container potrebbe essere errata o il controllo di integrità potrebbe essere configurato in modo errato. La sostituzione in sequenza dei pod attende fino a quando il pod appena avviato non supera il gate di idoneità del pod. Ciò si verifica solo se il pod risponde ai controlli di integrità del bilanciatore del carico. Se il pod non risponde o se il controllo di integrità non è configurato correttamente, non è possibile soddisfare le condizioni della porta di idoneità e l'implementazione non può continuare.
Se utilizzi
kubectl
1.13 o versioni successive, puoi controllare lo stato dei limiti di idoneità di un pod con il comando seguente:kubectl get pod POD_NAME -o wide
Controlla la colonna
READINESS GATES
.Questa colonna non esiste in
kubectl
1.12 e versioni precedenti. Un pod contrassegnato come in statoREADY
potrebbe avere un limite di idoneità non superato. Per verificarlo, utilizza il seguente comando:kubectl get pod POD_NAME -o yaml
Le porte di idoneità e il relativo stato sono elencati nell'output.
- Risoluzione
Verifica che l'immagine container nella specifica del pod del deployment funzioni correttamente e sia in grado di rispondere ai controlli di integrità. Verifica che i controlli di integrità siano configurati correttamente.
Errori relativi alla modalità con prestazioni ridotte
- Sintomi
A partire dalla versione 1.29.2-gke.1643000 di GKE, potresti ricevere i seguenti avvisi sul tuo servizio in Esplora log quando i NEG vengono aggiornati:
Entering degraded mode for NEG <service-namespace>/<service-name>-<neg-name>... due to sync err: endpoint has missing nodeName field
- Potenziali cause
Questi avvisi indicano che GKE ha rilevato errori di configurazione degli endpoint durante un aggiornamento del NEG basato su
EndpointSlice
oggetti, attivando un processo di calcolo più approfondito chiamato modalità ridotta. GKE continua ad aggiornare i NEG secondo il criterio del "best effort", correggendo la configurazione errata o escludendo gli endpoint non validi dagli aggiornamenti del NEG.Alcuni errori comuni sono:
endpoint has missing pod/nodeName field
endpoint corresponds to an non-existing pod/node
endpoint information for attach/detach operation is incorrect
- Risoluzione
Di solito, gli stati transitori causano questi eventi e vengono stabiliti autonomamente. Tuttavia, gli eventi causati da configurazioni errate negli oggetti
EndpointSlice
personalizzati rimangono irrisolti. Per comprendere l'errore di configurazione, esamina gli oggettiEndpointSlice
corrispondenti al servizio:kubectl get endpointslice -l kubernetes.io/service-name=<service-name>
Convalida ogni endpoint in base all'errore nell'evento.
Per risolvere il problema, devi modificare manualmente gli oggetti
EndpointSlice
. L'aggiornamento attiva un nuovo aggiornamento dei NEG. Quando l'errore di configurazione non esiste più, l'output è simile al seguente:NEG <service-namespace>/<service-name>-<neg-name>... is no longer in degraded mode
Problemi noti
Il bilanciamento del carico nativo del container su GKE presenta i seguenti problemi noti:
Garbage collection incompleta
La garbage collection GKE raccoglie ogni due minuti i bilanciatori del carico nativi del container. Se un cluster viene eliminato prima della rimozione completa dei bilanciatori del carico, devi eliminare manualmente i NEG del bilanciatore del carico.
Visualizza i NEG nel tuo progetto eseguendo questo comando:
gcloud compute network-endpoint-groups list
Nell'output comando, cerca i NEG pertinenti.
Per eliminare un NEG, esegui questo comando, sostituendo NEG_NAME
con il nome del NEG:
gcloud compute network-endpoint-groups delete NEG_NAME
Allinea le implementazioni dei carichi di lavoro con la propagazione degli endpoint
Quando esegui il deployment di un carico di lavoro nel tuo cluster o quando aggiorni un carico di lavoro esistente, il bilanciatore del carico nativo del container può impiegare più tempo per propagare i nuovi endpoint rispetto a quanto necessario per completare l'implementazione del carico di lavoro. Il deployment di esempio di cui esegui il deployment in questa guida utilizza due campi per allineare l'implementazione alla propagazione degli endpoint: terminationGracePeriodSeconds
e minReadySeconds
.
terminationGracePeriodSeconds
consente al pod di arrestarsi in modo controllato, attendendo che le connessioni terminino dopo che è stata pianificata l'eliminazione del pod.
minReadySeconds
aggiunge un periodo di latenza dopo la creazione di un pod. Devi specificare il numero minimo di secondi per cui un nuovo pod deve trovarsi in stato Ready
, senza che nessuno dei suoi container si arresti in modo anomalo, affinché il pod venga considerato disponibile.
Devi configurare i valori minReadySeconds
e terminationGracePeriodSeconds
dei carichi di lavoro impostandoli su un valore pari o superiore a 60 secondi per assicurarti che il servizio non venga interrotto a causa delle implementazioni dei carichi di lavoro.
terminationGracePeriodSeconds
è disponibile in tutte le specifiche dei pod, mentre minReadySeconds
è disponibile per i deployment e i DaemonSet.
Per scoprire di più sull'ottimizzazione delle implementazioni, consulta RollingUpdateStrategy.
initialDelaySeconds
nel pod readinessProbe
non rispettato
Potresti aspettarti che la configurazione initialDelaySeconds
nel readinessProbe
del pod venga rispettata dal bilanciatore del carico nativo del container. Tuttavia, readinessProbe
è implementato da kubelet e la configurazione initialDelaySeconds
controlla il controllo di integrità di kubelet, non il bilanciatore del carico nativo del container. Il bilanciamento del carico nativo del container
ha un proprio controllo di integrità del bilanciamento del carico.
Passaggi successivi
- Scopri di più sui NEG.
- Scopri di più sui cluster nativi di VPC.