Bilanciamento del carico nativo del container

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 a diversi tipi di bilanciatori del carico di scegliere come target direttamente i pod e di distribuire in modo uniforme il traffico ai pod.

Architettura di bilanciamento del carico nativo del container

Il bilanciamento del carico nativo del container utilizza 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 il traffico GKE Ingress interno ed è facoltativo per quelli in entrata esterni. Il controller Ingress crea il bilanciatore del carico, inclusi l'indirizzo IP virtuale, le regole di forwarding, i controlli di integrità e le 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 maggiore flessibilità, puoi anche creare NEG autonomi. In questo caso, sei responsabile della creazione e della gestione di tutti gli aspetti del bilanciatore del carico.

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 le regole iptables dei nodi per distribuire il traffico ai pod. Senza il bilanciamento del carico nativo del container, il traffico del bilanciatore del carico viene indirizzato ai gruppi di istanze del nodo e viene indirizzato utilizzando le regole iptables ai pod che potrebbero essere o meno sullo stesso nodo. Con il bilanciamento del carico nativo del container, il traffico del bilanciatore del carico viene distribuito direttamente ai pod che dovrebbero riceverlo, eliminando così l'hop di rete aggiuntivo. Il bilanciamento del carico nativo del container aiuta anche a migliorare il controllo di integrità, in quanto ha come target direttamente i pod.

Confronto tra il comportamento predefinito (a sinistra) e il comportamento del bilanciatore del carico nativo del container.
Migliori prestazioni di rete
Poiché il bilanciatore del carico nativo del container comunica direttamente con i pod e le connessioni hanno meno hop di rete, la latenza e la velocità effettiva sono migliorate.
Migliore visibilità
Il bilanciamento del carico nativo del container ti offre visibilità sulla latenza dal bilanciatore del carico delle applicazioni ai pod. È visibile la latenza del bilanciatore del carico delle applicazioni per ogni pod, che è stata aggregata con il bilanciamento del carico nativo del container basato sull'IP del nodo. In questo modo, la risoluzione dei problemi dei servizi a livello di NEG è più semplice.
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 come Google Cloud Armor, Cloud CDN e Identity-Aware Proxy. Dispone inoltre di algoritmi di bilanciamento del carico per una distribuzione accurata del traffico.
Supporto per Cloud Service Mesh
Il modello dei dati NEG è necessario per utilizzare Cloud Service Mesh, il piano di controllo del traffico completamente gestito di Google Cloud per il mesh di servizi.

Idoneità dei pod

Per i pod pertinenti, il controller Ingress corrispondente gestisce un gateway di idoneità di tipo cloud.google.com/load-balancer-neg-ready. Il controller Ingress esegue il polling dello stato del controllo di integrità del bilanciatore del carico, che include l'integrità di tutti gli endpoint nel NEG. Quando lo stato del controllo di integrità del bilanciatore del carico 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 questa porta di idoneità sia, se definito, il probe di idoneità del pod.

Le soglie di idoneità dei pod vengono abilitate automaticamente quando si utilizza il bilanciamento del carico nativo del container tramite Ingress.

I controlli di idoneità controllano la frequenza di un aggiornamento in sequenza. Quando avvii un aggiornamento in sequenza, mentre GKE crea nuovi pod, viene aggiunto un endpoint per ogni nuovo pod a un NEG. Se l'endpoint è integro dal punto di vista del bilanciatore del carico, il controller Ingress imposta la soglia di idoneità su True. Un pod appena creato deve superare almeno il limite di idoneità prima che GKE rimuova un pod precedente. Ciò garantisce che l'endpoint corrispondente per il pod abbia già superato il controllo di integrità del bilanciatore del carico e che la capacità del backend sia mantenuta.

Se la soglia di idoneità di un pod non indica mai che il pod è pronto, a causa di un'immagine del container non valida o di un controllo di integrità del bilanciatore del carico configurato in modo errato, il bilanciatore del carico non indirizzerà il traffico al nuovo pod. Se si verifica un errore durante l'implementazione di un deployment aggiornato, l'implementazione si blocca dopo aver tentato di creare un nuovo pod, perché il limite di idoneità del pod non è mai True. Consulta la sezione relativa alla risoluzione dei problemi per informazioni su come rilevare e risolvere questo problema.

Senza il bilanciamento del carico nativo del container e le porte di idoneità, GKE non è in grado di rilevare se gli endpoint di un bilanciatore del carico sono integri prima di contrassegnare i pod come pronti. Nelle versioni precedenti di Kubernetes, puoi controllare la frequenza di rimozione e sostituzione dei pod specificando un periodo di ritardo (minReadySeconds nella specifica del deployment).

GKE imposta il valore cloud.google.com/load-balancer-neg-ready per un pod su True se viene soddisfatta una delle seguenti condizioni:

  • Nessuno degli indirizzi IP del pod è endpoint in un NEG GCE_VM_IP_PORT gestito dal piano di controllo GKE.
  • Uno o più indirizzi IP del pod sono endpoint in un NEG GCE_VM_IP_PORT gestito dal piano di controllo GKE. Il NEG è collegato a un servizio di backend. Il servizio di backend ha completato il controllo di integrità del bilanciatore del carico.
  • Uno o più indirizzi IP del pod sono endpoint in un NEG GCE_VM_IP_PORT gestito dal piano di controllo GKE. Il NEG è collegato a un 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ù NEG GCE_VM_IP_PORT. 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 l'affinità sessione basata su pod.

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 è abilitato il componente aggiuntivo HttpLoadBalancing per impostazione predefinita; non devi disabilitarlo.

Limitazioni per i bilanciatori del carico nativi del container

I bilanciatori del carico nativi del container tramite Ingress su GKE hanno le seguenti limitazioni:

  • Non supporta i bilanciatori del carico di rete passthrough esterni.
  • Non devi modificare o aggiornare manualmente la configurazione del 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 vengono addebitati i costi per il bilanciatore del carico delle applicazioni di cui è stato eseguito il provisioning da Ingress che crei in questa guida. Per informazioni sui prezzi del bilanciatore del carico, consulta Bilanciamento del carico e regole di forwarding nella pagina dei prezzi di VPC.

Passaggi successivi