Architettura di riferimento per il bilanciamento del carico di livello 7

Questa architettura di riferimento fornisce una soluzione di bilanciamento del carico di livello 7 gestita dal cliente in Google Distributed Cloud (GDC) air-gapped. Eseguendo il deployment di controller open source diffusi come HAProxy Kubernetes Ingress o NGINX Gateway Fabric su un cluster standard GDC, i clienti possono instradare senza problemi il traffico L7 agli ambienti ibridi. Questa architettura utilizza la terminazione TLS (Ingress / HTTPRoute) per instradare il traffico in base a Indicazione del nome del server (SNI) sia ai pod containerizzati integrati sia alle applicazioni ospitate su macchine virtuali esterne.

Caratteristiche e funzionalità

  • Routing avanzato di livello 7: supporta il routing basato su host, il routing basato su percorso e la gestione avanzata del traffico, ad esempio la corrispondenza basata su intestazione e la ponderazione del traffico.
  • Gestione TLS centralizzata: fornisce la gestione e la terminazione TLS centralizzate.
  • Supporto per ambienti ibridi: instrada senza problemi il traffico L7 sia ai pod containerizzati integrati sia alle applicazioni ospitate su macchine virtuali esterne.
  • Opzioni di controller flessibili: offre una scelta tra NGINX Gateway Fabric moderno (che utilizza l'API Gateway) o il controller Ingress HAProxy consolidato.
  • Preparazione per ambienti air-gapped: integrato con Harbor Registry per archiviare e pubblicare immagini di proxy e applicazioni all'interno di ambienti privati e disconnessi.
  • Suddivisione complessa del traffico: consente strategie avanzate di distribuzione del traffico per la distribuzione di applicazioni moderne.

Principi architetturali

  • Pattern di bilanciamento del carico a due livelli: questa architettura combina il bilanciatore del carico L4 integrato di GDC (come punto di ingresso) con un gateway L7 gestito dal cliente di cui è stato eseguito il deployment in Kubernetes.
  • Separazione orientata ai ruoli: segue una progettazione che separa le responsabilità tra fornitori di infrastrutture, operatori di cluster e sviluppatori tramite risorse specifiche (come GatewayClass, Gateway, e HTTPRoute, o Ingress).
  • Transizione agli standard moderni: l'architettura dà la priorità all'API Gateway per le funzionalità di routing moderne, mantenendo al contempo il supporto per l'API Ingress legacy quando è richiesta la stabilità per controller specifici.
  • Flessibilità gestita dal cliente: eseguendo il deployment di controller autogestiti, i clienti ottengono il controllo sulle funzionalità e sulla configurazione L7 che non sono fornite in modo nativo dal bilanciatore L4 gestito da GDC.
  • Astrazione della posizione del carico di lavoro: l'architettura tratta in modo coerente i carichi di lavoro containerizzati e basati su VM tramite le astrazioni del servizio Kubernetes (standard o headless).

Architettura concettuale

Diagramma dell'architettura concettuale per il bilanciamento del carico di livello 7 su GDC air-gap.

Architettura logica

L'architettura logica è costituita da diversi componenti funzionali che operano in concerto per instradare il traffico esterno ai backend interni o esterni:

  1. Punto di ingresso Ingress/Gateway: un client avvia richieste HTTPS che raggiungono per prime il bilanciatore del carico L4 di GDC. Questo bilanciatore integrato funge da punto di ingresso e distribuisce il traffico TCP/443 al bilanciatore del carico L7.
  2. Piano di controllo: i controller Ingress o Gateway (operatori HAProxy o NGINX) monitorano le risorse Kubernetes come Ingress, Gateway e HTTPRoute.
  3. Piano dati: in base alle risorse osservate, i controller aggiornano dinamicamente i proxy sottostanti che eseguono il routing del traffico effettivo in base alle regole di routing host basate su SNI e alla terminazione TLS.
  4. Servizi di backend:
    • Pod containerizzati: gestiti come deployment standard ed esposti con i normali servizi Kubernetes.
    • VM esterne: integrate nel cluster con un servizio Kubernetes headless e un endpoint personalizzato (o EndpointSlice) contenente l'IP diretto della VM.
  5. Gestione degli artefatti: tutte le immagini per i proxy e le applicazioni vengono pubblicate da un registro Harbor locale per garantire la funzionalità in un ambiente air-gapped.

Concetti e tecnologie di base

L'architettura utilizza un pattern di bilanciamento del carico a due livelli, che combina il bilanciatore del carico L4 integrato di GDC con un gateway L7 gestito dal cliente di cui è stato eseguito il deployment in Kubernetes. I componenti chiave includono:

  • Client: un'entità che avvia richieste HTTPS per interagire con le applicazioni.
  • Cluster standard GDC: GDC fornisce un modo integrato per creare cluster Kubernetes Vanilla. In questa soluzione, il cluster ospiterà il bilanciatore del carico L7 e i relativi controller, insieme ai carichi di lavoro e al servizio headless per le VM esterne.
  • Bilanciatore del carico L4 di GDC: il bilanciatore del carico L4 integrato che funge da punto di ingresso, distribuendo il traffico TCP/443 direttamente ai pod Kubernetes che eseguono i controller Ingress o Gateway.
  • Controller Ingress e Gateway: operatori HAProxy o NGINX in esecuzione nel cluster standard. Per Nginx, monitorano le risorse dell'API Gateway (come Gateway e HTTPRoute) e aggiornano dinamicamente i proxy sottostanti. Per HAProxy, monitorano le risorse Ingress e aggiornano dinamicamente i proxy sottostanti.
    • Controller Ingress HAProxy: un controller Ingress per Kubernetes che utilizza HAProxy come proxy inverso e bilanciatore del carico di livello 7, gestendo anche la terminazione TLS.
    • NGINX Gateway Fabric: un'implementazione dell'API Gateway che utilizza NGINX come piano dati.
  • Ingress e Gateway (con HTTPRoute): risorse Kubernetes standardizzate che definiscono la porta di ascolto fisica (443) e le regole di routing host basate su SNI con terminazione TLS.
  • Carico di lavoro containerizzato (pod): un deployment Kubernetes standard esposto internamente utilizzando un Service Kubernetes normale.
  • Carico di lavoro basato su VM (esterno): un carico di lavoro ospitato su una VM esterna nella rete del progetto, esposto al proxy con un Service Kubernetes headless e un endpoint personalizzato contenente l'IP diretto della VM.
  • Registro Harbor: un registro container privato utilizzato per archiviare e pubblicare le immagini di proxy e applicazioni nell'ambiente air-gapped.

API Ingress e Gateway

Il panorama del networking di Kubernetes sta passando dall'API Ingress legacy alla moderna API Gateway. Comprendere le differenze tra queste due API è fondamentale per selezionare l'architettura giusta per i tuoi carichi di lavoro.

  • API Ingress: storicamente, Ingress è stato lo standard per la gestione dell'accesso esterno ai servizi HTTP. Fornisce il routing basato su host e su percorso, ma la sua progettazione è relativamente semplice e non supporta in modo integrato la gestione avanzata del traffico (ad esempio, la corrispondenza basata su intestazione o la ponderazione del traffico) senza fare affidamento su annotazioni specifiche del fornitore. È importante sottolineare che l'API Ingress è ora considerata feature-frozen dalla community di Kubernetes (limitazioni di Ingress ed evoluzione del networking di Kubernetes).

  • API Gateway: spesso definita come la V2 di Ingress, l'API Gateway è una raccolta di definizioni di risorse personalizzate (CRD) che forniscono un modello più solido ed estensibile per il networking di servizi. È progettata per essere orientata ai ruoli, separando le responsabilità tra i fornitori di infrastrutture (GatewayClass), gli operatori di cluster (Gateway) e gli sviluppatori (HTTPRoute/TLSRoute) (API Gateway in GKE). Questa separazione consente un controllo più granulare e un migliore supporto multi-tenant.

In questa soluzione GDC con air gap, abbiamo scelto appositamente API diverse per i due controller in primo piano:

  • NGINX (API Gateway): per l'implementazione di NGINX, utilizziamo NGINX Gateway Fabric, un'implementazione matura e integrata dell'API Gateway. L'utilizzo dell'API Gateway per NGINX consente ai clienti di usufruire degli standard moderni e delle funzionalità di routing avanzate (come HTTPRoute) integrate nell'API.
  • HAProxy (API Ingress): sebbene l'API Gateway sia la direzione strategica, in questa guida abbiamo selezionato l'API Ingress per HAProxy. Questo perché l'integrazione dell'API Gateway di HAProxy non è considerata matura. Utilizzando il controller Ingress HAProxy consolidato, garantiamo una soluzione L7 stabile e affidabile per i clienti che preferiscono HAProxy, fornendo al contempo un percorso verso le funzionalità L7 moderne.

Ipotesi e vincoli

Ipotesi

  • Preparazione dell'infrastruttura: il deployment presuppone la disponibilità di cluster standard GDC con air gap 1.15.x.
  • Registro locale: si presuppone che un registro Harbor locale sia configurato correttamente per archiviare e pubblicare immagini di proxy e applicazioni nell'ambiente air-gapped.
  • Punto di ingresso nativo: si presuppone che il traffico raggiunga per primo il bilanciatore del carico L4 integrato di GDC, che poi distribuisce il traffico ai proxy L7.

Vincoli

  • Soluzione gestita dal cliente: in GDC non esiste un servizio L7 gestito con SLA; questa implementazione è interamente autogestita dal cliente.
  • Solo cluster standard: i cluster utente condivisi non sono inclusi nell'ambito a causa dei privilegi elevati richiesti per il deployment dei controller Ingress e Gateway.
  • Maturità dell'API: mentre NGINX utilizza la moderna API Gateway, HAProxy è vincolato all'API Ingress perché la sua integrazione con l'API Gateway non è ancora considerata matura.
  • Manutenzione air-gapped: tutte le immagini container devono essere promosse e gestite manualmente all'interno del registro Harbor locale.
  • Versioni della community: l'architettura è progettata per le versioni della community open source di Nginx e HAProxy. Le versioni Enterprise potrebbero funzionare, ma non sono state testate in modo esplicito.
  • Proprietà operativa: i clienti devono gestire autonomamente lo scaling, l'alta disponibilità e l'applicazione di patch per i controller di terze parti.
  • Limiti del supporto: il supporto Google copre solo l'infrastruttura GDC sottostante; i problemi relativi al software HAProxy o NGINX sono di responsabilità del cliente o del fornitore.
  • Obsolescenza dell'API: l'API Ingress (utilizzata per HAProxy) è feature-frozen dalla community di Kubernetes, il che potrebbe limitare le funzionalità di routing future.

Licenze

  • Versioni della community: l'architettura è progettata per le versioni della community open source (in genere Apache 2.0 o simili), che sono senza costi ma gestite dal cliente.
  • Acquisto di versioni Enterprise: l'acquisto e la gestione delle licenze commerciali, come NGINX Plus o HAProxy Enterprise, sono di esclusiva responsabilità del cliente.

Materiali aggiuntivi