Questa pagina spiega che cos'è il bilanciamento del carico nativo del container in Google Kubernetes Engine (GKE). Il bilanciamento del carico nativo del container consente vari tipi di bilanciatori del carico per il targeting diretto dei pod e la distribuzione uniforme del traffico ai pod.
Architettura di bilanciamento del carico nativo del container
Usi del bilanciamento del carico nativo del container
GCE_VM_IP_PORT
gruppi di endpoint di rete (NEG).
Gli endpoint del NEG sono indirizzi IP del pod.
Il bilanciamento del carico nativo del container viene sempre utilizzato per GKE interno Ingress ed è facoltativo per quelli esterni. Il controller Ingress crea bilanciatore del carico, inclusi indirizzo IP virtuale, regole di forwarding, integrità di firewall e regole firewall.
Per scoprire come utilizzare il bilanciamento del carico nativo del container con Ingress, consulta Bilanciamento del carico nativo del container tramite Ingress.
Per una maggiore flessibilità, puoi anche crea NEG autonomi. In questo in questo caso, sei responsabile della creazione e della gestione di tutti gli aspetti del carico con il bilanciatore del carico di rete passthrough esterno regionale.
Vantaggi del bilanciamento del carico nativo del container
Il bilanciamento del carico nativo del container offre i seguenti vantaggi:
- I pod sono oggetti principali per il bilanciamento del carico
- kube-proxy
configura i nodi
iptables
regole per distribuire il traffico ai pod. Senza bilanciamento del carico nativo del container, bilanciatore del carico, il traffico arriva ai gruppi di istanze dei nodi e viene instradato utilizzandoiptables
ai pod che potrebbero trovarsi o meno nello stesso nodo. Con del carico nativo del container, il traffico del bilanciatore del carico viene distribuito direttamente ai pod che dovrebbero ricevere il traffico, eliminando la rete hop. Il bilanciamento del carico nativo del container aiuta anche a migliorare il controllo di integrità poiché ha come target direttamente i pod.
- Migliori prestazioni di rete
- Perché il bilanciatore del carico nativo del container comunica direttamente con i pod, connessioni hanno meno hop di rete, sia la latenza che la velocità effettiva sono state migliorate.
- Migliore visibilità
- Il bilanciamento del carico nativo del container ti offre visibilità sulla latenza dal bilanciatore del carico delle applicazioni ai pod. La latenza è visibile il bilanciatore del carico delle applicazioni per ogni pod, che sono stati aggregati il bilanciamento del carico nativo del container basato sull'IP del nodo. In questo modo, la risoluzione dei problemi Servizi a livello di NEG più semplici.
- Supporto per funzionalità di bilanciamento del carico avanzate
- Il bilanciamento del carico nativo del container in GKE supporta diverse Funzionalità dei bilanciatori del carico delle applicazioni esterni, come l'integrazione con i servizi Google Cloud Mi piace Google Cloud Armor, Cloud CDN e Identity-Aware Proxy. Offre anche funzionalità di algoritmi di bilanciamento per una distribuzione accurata del traffico.
- Supporto per Cloud Service Mesh
- Il modello dei dati NEG è necessario per utilizzare Cloud Service Mesh, Piano di controllo del traffico completamente gestito di Google Cloud per mesh di servizi.
Idoneità dei pod
Per i pod pertinenti, il controller Ingress corrispondente gestisce un'istanza
controllo di idoneità
di tipo cloud.google.com/load-balancer-neg-ready
. Il controller Ingress esegue il polling
del bilanciatore del carico
stato del controllo di integrità, ovvero
include l'integrità di tutti gli endpoint nel NEG. Quando l'integrità del bilanciatore del carico
"check status" indica che l'endpoint corrispondente a un determinato pod
integro, il controller Ingress imposta il valore della porta di idoneità del pod su True
.
Il kubelet in esecuzione su ciascun nodo calcola quindi l'idoneità effettiva del pod.
considerando sia il valore di questo controllo di idoneità sia, se definito, pod
probe di idoneità.
I controlli di idoneità dei pod vengono abilitati automaticamente quando si utilizza il container-native del carico tramite Ingress.
I controlli di idoneità controllano la frequenza di un aggiornamento in sequenza. Quando avvii una
in sequenza, man mano che GKE crea nuovi pod, un endpoint per
Il pod viene aggiunto a un NEG. Quando l'endpoint è integro dal punto di vista
bilanciatore del carico, il controller Ingress imposta la porta di idoneità su True
. R
il pod appena creato deve superare almeno il limite di idoneità prima
GKE rimuove un pod precedente. In questo modo ci assicuriamo che
dell'endpoint per il pod ha già superato il controllo di integrità del bilanciatore del carico
in modo che venga mantenuta
la capacità del backend.
Se il limite di idoneità di un pod non indica mai che il pod è pronto, a causa di un'immagine container o un controllo di integrità del bilanciatore del carico non configurato correttamente, non indirizzerà il traffico al nuovo pod. Se si verifica un errore di questo tipo durante l'implementazione di un deployment aggiornato, l'implementazione si blocca dopo aver tentato di crearne uno nuovo perché il limite di idoneità del pod non è mai True. Consulta le sezione relativa alla risoluzione dei problemi per informazioni su come rilevare e risolvere il problema.
Senza il bilanciamento del carico nativo del container e le porte di idoneità, GKE
non riesce a rilevare se gli endpoint di un bilanciatore del carico sono integri prima di contrassegnare i pod come
pronto. Nelle versioni precedenti di Kubernetes, controllavi
la velocità con cui i pod vengono rimossi e sostituiti specificando un periodo di ritardo
(minReadySeconds
nella specifica del deployment).
GKE imposta il valore
cloud.google.com/load-balancer-neg-ready
per un pod a True
se uno degli
le seguenti condizioni sono soddisfatte:
- Nessuno degli indirizzi IP del pod è un endpoint in un
GCE_VM_IP_PORT
NEG gestito da dal piano di controllo GKE. - Uno o più indirizzi IP del pod sono endpoint in un
GCE_VM_IP_PORT
NEG gestito dal piano di controllo GKE. Il NEG è collegato a un servizio di backend. Il servizio di backend ha un controllo di integrità del bilanciatore del carico riuscito. - Uno o più indirizzi IP del pod sono endpoint in un
GCE_VM_IP_PORT
NEG gestito dal piano di controllo GKE. Il NEG è collegato a un di servizio di backend. Il controllo di integrità del bilanciatore del carico per il servizio di backend scade. - Uno o più indirizzi IP del pod sono endpoint in uno o più
GCE_VM_IP_PORT
NEG. Nessuno dei NEG è collegato a un servizio di backend. Non sono disponibili dati sul controllo di integrità del bilanciatore del carico.
Affinità sessione
Il bilanciamento del carico nativo del container supporta Basato su pod affinità sessione.
Requisiti per l'utilizzo del bilanciamento del carico nativo del container
I bilanciatori del carico nativi del container tramite Ingress su GKE hanno i seguenti requisiti:
- Il cluster deve essere nativo di VPC.
- Nel cluster deve essere abilitato il componente aggiuntivo
HttpLoadBalancing
. Nei cluster GKE il componente aggiuntivoHttpLoadBalancing
è abilitato default; non devi disattivarla.
Limitazioni per i bilanciatori del carico nativi del container
I bilanciatori del carico nativi del container tramite Ingress su GKE hanno seguenti:
- Non supporta i bilanciatori del carico di rete passthrough esterni.
- Non devi modificare o aggiornare manualmente la configurazione del il bilanciatore del carico delle applicazioni creato da GKE. Tutte le modifiche che apporti vengono sovrascritte da GKE.
Prezzi per i bilanciatori del carico nativi del container
Ti viene addebitato il costo del bilanciatore del carico delle applicazioni di cui è stato eseguito il provisioning dall'Ingress che che creerai in questa guida. Per informazioni sui prezzi dei bilanciatori del carico, consulta Bilanciamento del carico e regole di forwarding nella dei prezzi di VPC.
Passaggi successivi
- Scopri di più sui NEG.
- Scopri di più su Cluster nativi VPC.
- Scopri di più su bilanciatori del carico delle applicazioni esterni.
- Guarda un KubeCon parla dei gate di idoneità dei pod.