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) con air gap. Eseguendo il deployment di controller open source popolari come HAProxy Kubernetes Ingress o NGINX Gateway Fabric su un cluster GDC standard, i clienti possono instradare senza problemi il traffico L7 verso ambienti ibridi. Questa architettura utilizza la terminazione TLS (Ingress/HTTPRoute) per instradare il traffico in base alla Server Name Indication (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 sull'host, il routing basato sul percorso e la gestione avanzata del traffico, come la corrispondenza basata sull'intestazione e la ponderazione del traffico.
  • Gestione TLS centralizzata: fornisce la gestione e la terminazione TLS centralizzate.
  • Supporto di 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 la possibilità di scegliere tra il moderno NGINX Gateway Fabric (utilizzando l'API Gateway) o il consolidato controller Ingress HAProxy.
  • Idoneità air-gapped: integrato con Harbor Registry per archiviare e fornire immagini di proxy e applicazioni in ambienti privati e disconnessi.
  • Suddivisione del traffico complessa: consente strategie avanzate di distribuzione del traffico per la distribuzione delle applicazioni moderne.

Principi di architettura

  • Modello 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 all'interno di Kubernetes.
  • Separazione orientata ai ruoli: segue un design che separa le responsabilità tra provider 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 funzionalità di routing moderne, mantenendo al contempo il supporto per l'API Ingress legacy, dove è richiesta la stabilità per controller specifici.
  • Flessibilità gestita dal cliente: con 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 workload: l'architettura tratta i workload containerizzati e basati su VM in modo coerente tramite le astrazioni dei servizi Kubernetes (standard o headless).

Architettura concettuale

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

Architettura logica

L'architettura logica è costituita da diversi componenti funzionali che lavorano insieme 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. Control plane: 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 l'instradamento effettivo del traffico in base alle regole di instradamento dell'host basate su SNI e alla terminazione TLS.
  4. Servizi di backend:
    • Pod containerizzati: gestiti come deployment standard ed esposti con servizi Kubernetes regolari.
    • 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 con air gap

Concetti e tecnologie principali

L'architettura utilizza un pattern di bilanciamento del carico a due livelli, combinando 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 GDC Standard: 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 workload e al servizio headless per le VM esterne
  • Bilanciatore del carico GDC L4: il bilanciatore del carico L4 integrato funge da punto di ingresso e distribuisce 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 API Gateway (come Gateway e HTTPRoute) e aggiornano dinamicamente i proxy sottostanti. Per HAProxy, monitorano le risorse Ingress e aggiornano dinamicamente i proxy sottostanti.
    • HAProxy Ingress Controller: un controller Ingress per Kubernetes che utilizza HAProxy come reverse proxy 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 instradamento dell'host basate su SNI con terminazione TLS.
  • Workload containerizzato (pod): un deployment Kubernetes standard esposto internamente utilizzando un Service Kubernetes standard.
  • Workload basato su VM (esterno): un workload 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.
  • Harbor Registry: un Container Registry privato utilizzato per archiviare ed erogare le immagini del proxy e dell'applicazione nell'ambiente con air gap.

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 opzioni è fondamentale per selezionare l'architettura giusta per i tuoi workload.

  • API Ingress: storicamente, Ingress è stato lo standard per la gestione dell'accesso esterno ai servizi HTTP. Fornisce il routing basato su host e percorso, ma il suo design è relativamente di base e manca di un supporto integrato per la gestione avanzata del traffico (ad esempio, la corrispondenza basata su intestazioni o la ponderazione del traffico) senza fare affidamento su annotazioni specifiche del fornitore. È importante sottolineare che l'API Ingress è ora considerata congelata 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 dei servizi. È progettata per essere orientata ai ruoli, separando le responsabilità tra provider di infrastrutture (GatewayClass), operatori di cluster (Gateway) e sviluppatori (HTTPRoute/TLSRoute) (API Gateway in GKE). Questa separazione consente un controllo più granulare e un migliore supporto della multi-tenancy.

In questa soluzione GDC con air gap, abbiamo scelto intenzionalmente 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. Sfruttando l'API Gateway per NGINX, i clienti possono trarre vantaggio dagli standard moderni e dalle 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 consolidato controller Ingress HAProxy, garantiamo una soluzione L7 stabile e affidabile per i clienti che preferiscono HAProxy, fornendo al contempo un percorso verso funzionalità L7 moderne.

Ipotesi e vincoli

Ipotesi

  • Idoneità dell'infrastruttura: il deployment presuppone la disponibilità di cluster standard GDC con air gap 1.15.x.
  • Registry locale: si presume che un registry Harbor locale sia configurato correttamente per archiviare e gestire le immagini proxy e delle applicazioni nell'ambiente air-gapped.
  • Punto di ingresso nativo: si presume che il traffico raggiunga prima il bilanciatore del carico L4 integrato di GDC, che poi lo distribuisce ai proxy L7.

Vincoli

  • Soluzione gestita dal cliente: non esiste un servizio L7 gestito e supportato da SLA in GDC; questa implementazione è interamente autogestita dal cliente.
  • Solo cluster standard: i cluster utente condivisi non rientrano nell'ambito a causa dei privilegi elevati richiesti per il deployment di Ingress e Gateway Controller.
  • Maturità dell'API: mentre NGINX utilizza la moderna API Gateway, HAProxy è limitato 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 registry Harbor locale.
  • Community Edition: l'architettura è progettata per le versioni open source della community di Nginx e HAProxy. Le versioni Enterprise potrebbero funzionare, ma non sono state testate esplicitamente.
  • Proprietà operativa: i clienti devono gestire autonomamente la scalabilità, l'alta affidabilità e l'applicazione di patch per i controller di terze parti.
  • Ambito dell'assistenza: l'assistenza Google copre solo l'infrastruttura GDC sottostante; i problemi con il software HAProxy o NGINX sono di responsabilità del cliente o del fornitore.
  • Obsolescenza dell'API: l'API Ingress (utilizzata per HAProxy) è stata bloccata dalla community di Kubernetes, il che potrebbe limitare le future funzionalità di routing.

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.
  • Approvvigionamento aziendale: l'approvvigionamento e la gestione delle licenze commerciali, come NGINX Plus o HAProxy Enterprise, sono di esclusiva responsabilità del cliente.

Materiali aggiuntivi