Bilanciamento del carico nativo del container

Questa pagina spiega il bilanciamento del carico nativo dei container in Google Kubernetes Engine (GKE).

Questa pagina presuppone che tu conosca Cloud Load Balancing e i gruppi di endpoint di rete (NEG) a livello di zona. Con il bilanciamento del carico nativo del container, questi bilanciatori del carico possono distribuire il traffico direttamente e in modo uniforme 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 dei pod.

Il bilanciamento del carico nativo del container viene sempre utilizzato per GKE Ingress interno ed è facoltativo per Ingress esterno. 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 una maggiore flessibilità, puoi anche creare NEG autonomi. In questo caso, sei responsabile della creazione e della gestione di tutti gli aspetti del bilanciamento 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 di nodi e instradato utilizzando le regole iptables ai pod che potrebbero trovarsi o meno nello stesso nodo. Con il bilanciamento del carico nativo del container, il traffico del bilanciatore del carico viene distribuito direttamente ai pod che devono ricevere il traffico, eliminando l'hop di rete aggiuntivo. Il bilanciamento del carico nativo del container contribuisce anche a migliorare il controllo di integrità in quanto ha come target diretto 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, sia la latenza che la velocità effettiva vengono migliorate.
Migliore visibilità
Con il bilanciamento del carico nativo del container, hai visibilità sulla latenza dal bilanciatore del carico delle applicazioni ai pod. È visibile la latenza dal bilanciatore del carico delle applicazioni a ogni pod, che sono stati aggregati con il bilanciamento del carico nativo del container basato su IP del nodo. In questo modo, la risoluzione dei problemi relativi ai tuoi servizi a livello di gruppo di annunci è più semplice.
Supporto delle funzionalità avanzate di bilanciamento del carico
Il bilanciamento del carico nativo dei container in GKE supporta diverse funzionalità dei bilanciatori del carico delle applicazioni esterni, come l'integrazione con i servizi come Google Cloud Armor, Cloud CDN e Identity-Aware Proxy. Trusted Cloud by S3NS 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 diTrusted Cloudper mesh di servizi.

Pod readiness

Per i pod pertinenti, il controller Ingress corrispondente gestisce un gate di preparazione 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 del gate di idoneità del pod su True. kubelet in esecuzione su ogni nodo calcola l'effettiva disponibilità del pod, tenendo conto sia del valore di questo gate di disponibilità sia, se definita, della probe di disponibilità del pod.

I gate di preparazione dei pod vengono attivati automaticamente quando si utilizza il bilanciamento del carico nativo del container tramite Ingress.

I gate di preparazione controllano la velocità di un aggiornamento in sequenza. Quando avvii un aggiornamento in sequenza, man mano che GKE crea nuovi pod, a un NEG viene aggiunto un endpoint per ogni nuovo pod. Quando l'endpoint è integro dal punto di vista del bilanciatore del carico, il controller Ingress imposta il gate di idoneità su True. Un pod appena creato deve superare almeno il gate di preparazione prima che GKE rimuova un vecchio pod. In questo modo, l'endpoint corrispondente per il pod ha già superato il controllo di integrità del bilanciatore del carico e la capacità del backend viene mantenuta.

Se l'indicatore di disponibilità di un pod non indica mai che il pod è pronto, a causa di un'immagine container errata 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 di questo tipo durante l'implementazione di un deployment aggiornato, l'implementazione si blocca dopo aver tentato di creare un nuovo pod perché il readiness gate 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 dei container e i readiness gate, GKE non può rilevare se gli endpoint di un bilanciatore del carico sono integri prima di contrassegnare i pod come pronti. Nelle versioni precedenti di Kubernetes, controlli la velocità con cui i pod vengono rimossi e sostituiti specificando un periodo di ritardo (minReadySeconds nella specifica del deployment).

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

  • Nessuno degli indirizzi IP del pod è un endpoint in un NEG GCE_VM_IP_PORTgestito dal control plane GKE.
  • Uno o più indirizzi IP del pod sono endpoint in un NEG GCE_VM_IP_PORT gestito dal control plane GKE. Il NEG è collegato a un servizio di backend. Il servizio di backend ha superato 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 control plane 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 controllo di integrità del bilanciatore del carico.

Affinità sessione

Il bilanciamento del carico nativo del container supporta l'affinità di sessione basata sui 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.
  • Il cluster deve avere il componente aggiuntivo HttpLoadBalancing abilitato. I cluster GKE hanno l'addon HttpLoadBalancing abilitato 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 presentano le seguenti limitazioni:

  • Non supportano 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 apportate vengono sovrascritte da GKE.

Passaggi successivi