Quando si avvia un cluster Kubernetes per una specifica applicazione, è fondamentale comprendere quali requisiti presenta per questa risorsa l'applicazione stessa, il business e gli sviluppatori. Con queste informazioni, si può procedere a prendere decisioni architetturali, in particolare alla scelta di un Ingress controller, di cui oggi esiste un'ampia varietà. Per fornire una base di comprensione delle opzioni disponibili senza la necessità di esaminare numerosi articoli/documentazione, abbiamo preparato questa panoramica, includendo i principali (production ready) Ingress controller.
Speriamo che possa aiutare i colleghi a scegliere la soluzione architetturale — almeno sarà un punto di partenza per ottenere informazioni più dettagliate e per esperimenti pratici. Inizialmente, abbiamo esaminato altri materiali simili online e, stranamente, non abbiamo trovato nemmeno una panoramica sufficientemente completa e, cosa più importante, ben strutturata. Quindi, colmiamo questa lacuna!
Criteri
Per effettuare un confronto utile e ottenere risultati significativi, è necessario comprendere non solo il dominio tematico, ma anche avere un elenco specifico di criteri che definiranno l'orientamento della ricerca. Senza pretendere di analizzare tutti i possibili casi di utilizzo di Ingress/Kubernetes, abbiamo cercato di evidenziare i requisiti più generali per i controller — siate pronti a dover approfondire la vostra specificità e dettagli separatamente.
Inizio con le caratteristiche che sono diventate così familiari da essere implementate in tutte le soluzioni e non considerate:
- scoperta dei servizi (service discovery);
- terminazione SSL;
- gestione dei websocket.
Ora — riguardo ai punti di confronto:
Protocolli supportati
Uno dei criteri fondamentali per la scelta. Il vostro software potrebbe non funzionare secondo lo standard HTTP o richiedere l'uso di molteplici protocolli. Se la vostra situazione è non standard, tenete sicuramente in considerazione questo fattore, per evitare di dover riconfigurare il cluster in seguito. La lista dei protocolli supportati varia per tutti i controller.
Software sottostante
Ci sono diverse opzioni di applicazioni su cui è basato il controller. I più popolari sono nginx, traefik, haproxy, envoy. In generale, potrebbe non avere un grande impatto su come viene gestito il traffico, ma è sempre utile conoscere le potenziali sfumature e caratteristiche di ciò che è "sotto il cofano".
Routing del traffico
Su cosa si basa la decisione per indirizzare il traffico verso un servizio specifico? Di solito è basato su host e path, ma ci sono anche opzioni aggiuntive.
Namespace nel cluster
Il namespace è la possibilità di suddividere logicamente le risorse in Kubernetes (ad esempio, su stage, production, ecc.). Ci sono Ingress controller che devono essere installati separatamente in ogni namespace (e allora possono indirizzare il traffico solo verso i pod di quel namespace). Ce ne sono altri (e sono decisamente la maggioranza) che funzionano globalmente per l'intero cluster — in essi, il traffico viene indirizzato a qualsiasi pod del cluster, indipendentemente dal namespace.
Controlli per upstream
In che modo viene garantito che il traffico venga indirizzato verso istanze sane dell'applicazione e dei servizi? Ci sono opzioni con controlli attivi e passivi, tentativi ripetuti (retries), circuit breakers (per saperne di più, ad esempio, vedi ), implementazioni personalizzate dei controlli di stato (custom health checks) e così via. È un parametro molto importante se avete elevate esigenze di disponibilità e per rimuovere tempestivamente i servizi non funzionanti dalla bilanciamento.
Algoritmi di bilanciamento
Ci sono molte opzioni: da quelle tradizionali a quelle esotiche come , oltre a funzioni separate come .
Autenticazione
Quali schemi di autorizzazione supporta il controller? Basic, digest, oauth, external-auth — credo che queste opzioni dovrebbero esservi familiari. Questo è un criterio importante se vengono utilizzati molti ambiti per sviluppatori (e/o semplicemente privati), ai quali si accede tramite Ingress.
Distribuzione del traffico
Il controller supporta meccanismi comunemente usati per la distribuzione del traffico, come le distribuzioni canary, A/B testing, mirroring del traffico? Questo è un tema cruciale per le applicazioni che richiedono una gestione accurata e precisa del traffico per test produttivi, debugging di errori del prodotto senza impatto (o con perdite minime), analisi del traffico, ecc.
Abbonamento a pagamento
Esiste un'opzione a pagamento per il controller, con funzionalità avanzate e/o supporto tecnico?
Interfaccia grafica (Web UI)
Esiste un'interfaccia grafica per gestire la configurazione del controller? Principalmente per 'facilità d'uso' e/o per coloro che necessitano di apportare modifiche alla configurazione di Ingress, poiché lavorare con modelli 'grezzi' non è comodo. Potrebbe essere utile nel caso in cui gli sviluppatori vogliano effettuare esperimenti al volo con il traffico.
Validazione JWT
Presenza di un controllo integrato per i token JSON web per l'autenticazione e la validazione dell'utente nell'applicazione finale.
Opzioni di personalizzazione della configurazione
Espandibilità dei modelli in termini di meccanismi che consentono di aggiungere direttive, flag, ecc. personalizzati ai modelli di configurazione standard.
Meccanismi di base per la protezione DDoS
Algoritmi semplici di limitazione della velocità o varianti più complesse per filtrare il traffico in base a indirizzi, liste bianche, nazioni, ecc.
Tracciamento delle richieste
Opzioni di monitoraggio, tracciamento e debug delle richieste da Ingress verso servizi/pod specifici e, idealmente, anche tra servizi/pod.
WAF
Supporto .
Controller Ingress
L'elenco dei controller è stato redatto sulla base di e . Alcuni di essi sono stati esclusi dalla revisione a causa della loro specificità o della loro scarsa diffusione (fase di sviluppo precoce). Gli altri sono descritti di seguito. Iniziamo con una panoramica delle soluzioni e continueremo con una tabella di sintesi.
Ingress di Kubernetes
Sito:
Licenza: Apache 2.0
Questo è il controller ufficiale per Kubernetes, sviluppato dalla comunità. Come suggerisce il nome, è basato su nginx e arricchito da vari plugin Lua utilizzati per implementare funzionalità aggiuntive. Grazie alla popolarità di nginx e alle modifiche minime necessarie per utilizzarlo come controller, questa opzione può risultare la più semplice e comprensibile da configurare per un ingegnere medio (con esperienza nel web).
Ingress di NGINX Inc
Sito:
Licenza: Apache 2.0
Prodotto ufficiale degli sviluppatori di nginx. Ha una versione a pagamento basata su . L'idea principale è un alto livello di stabilità, totale retrocompatibilità, assenza di moduli esterni e una elevata velocità dichiarata (rispetto al controller ufficiale), ottenuta grazie all'abbandono di Lua.
La versione gratuita è notevolmente ridotta, anche rispetto al controller ufficiale (a causa della mancanza dei suddetti moduli Lua). La versione a pagamento, però, offre funzionalità aggiuntive significative: metriche in tempo reale, validazione JWT, controlli di stato attivi e altro ancora. Un vantaggio importante rispetto a NGINX Ingress è il supporto completo per il traffico TCP/UDP (anche nella versione community!). Lo svantaggio è che ci sono poche funzionalità per la distribuzione del traffico, che, tuttavia, 'ha la massima priorità per gli sviluppatori', ma richiede tempo per l'implementazione.
Kong Ingress
Sito:
Licenza: Apache 2.0
Prodotto sviluppato da Kong Inc. in due versioni: commerciale e gratuita. Basato su nginx, le cui funzionalità sono ampliate da un gran numero di moduli Lua.
Originariamente era orientato al trattamento e alla gestione delle richieste API, cioè come API Gateway, ma attualmente è diventato un controller Ingress completo. I principali vantaggi: numerosi moduli aggiuntivi (inclusi quelli di sviluppatori esterni) che possono essere facilmente installati e configurati, attraverso i quali viene implementata una vasta gamma di funzionalità aggiuntive. Tuttavia, le funzioni integrate offrono già molte possibilità. La configurazione operativa è effettuata tramite risorse CRD.
Una caratteristica importante del prodotto è che funziona all'interno di un singolo contesto (invece che cross-namespaced), un argomento controverso: potrebbe sembrare un difetto (è necessario creare entità per ogni contesto), mentre per altri è una funzionalità (piùunalto livello di isolamento, poiché se un controller si guasta, il problema è limitato solo a quel contesto).
Traefik
Sito:
Licenza: MIT
Un proxy originariamente creato per lavorare con il routing delle richieste per microservizi e il loro ambiente dinamico. Da qui anche molte funzionalità utili: aggiornamento della configurazione senza riavvii, supporto per un gran numero di metodi di bilanciamento, interfaccia web, inoltro delle metriche, supporto per vari protocolli, REST API, rilasci canary e molto altro. Una piacevole caratteristica è anche il supporto per i certificati Let's Encrypt out-of-the-box. Uno svantaggio è che, per garantire un'alta disponibilità (HA), il controller richiederà l'installazione e la connessione di un proprio storage KV.
HAProxy
Sito:
Licenza: Apache 2.0
HAProxy è ben noto come proxy e bilanciatore di carico. All'interno di un cluster Kubernetes, offre aggiornamenti 'soft' della configurazione (senza perdita di traffico), discovery dei servizi basata su DNS e configurazione dinamica tramite API. La personalizzazione completa dei template di configurazione attraverso la sostituzione del ConfigMap è particolarmente attraente, nonché la possibilità di utilizzare funzioni della libreria Sprig. In generale, la soluzione si concentra su alta velocità, ottimizzazione ed efficienza delle risorse. Il vantaggio del controller è il supporto per un numero record di diverse modalità di bilanciamento.
Voyager
Sito:
Licenza: Apache 2.0
Un controller basato su HAProxy, posizionato come una soluzione universale che supporta ampie funzionalità su un gran numero di provider. Offre la possibilità di bilanciare il traffico a L7 e L4; la bilanciatura del traffico TCP L4 può essere considerata una delle funzionalità principali della soluzione.
Contour
Sito:
Licenza: Apache 2.0
Questa soluzione non solo si basa su Envoy ma è stata sviluppata in collaborazione dagli autori di questo popolare proxy. Una caratteristica importante è la possibilità di separare la gestione delle risorse Ingress tramite risorse CRD IngressRoute. Per le organizzazioni con molti team di sviluppo che utilizzano un unico cluster, ciò contribuisce a massimizzare la sicurezza nella gestione del traffico e protegge dai possibili errori quando si modificano le risorse Ingress.
Sono inoltre disponibili un set ampliato di metodi di bilanciamento (include il mirroring delle richieste, i retry automatici, limitazioni sul rate delle richieste e molto altro), monitoraggio dettagliato del flusso di traffico e dei fallimenti. Potrebbe risultare un significativo svantaggio per alcuni l'assenza del supporto per le sessioni sticky (sebbene i lavori ).
Istio Ingress
Sito:
Licenza: Apache 2.0
Una soluzione completa di service mesh, che non solo funge da controller Ingress gestendo il traffico in entrata, ma controlla anche tutto il traffico all'interno del cluster. Sotto il cofano, come proxy sidecar per ogni servizio, utilizza Envoy. In sostanza è un grande insieme di strumenti che 'può fare tutto', e la sua idea principale è massima gestibilità, scalabilità, sicurezza e trasparenza. Con esso, puoi configurare nei dettagli la routing del traffico, l'autenticazione tra i servizi, il bilanciamento, il monitoraggio, i rilasci canarini e molto altro. Scopri di più su Istio nella serie di articoli '».
Ambassador
Sito:
Licenza: Apache 2.0
Un'altra soluzione basata su Envoy. Ha sia versioni gratuite che commerciali. Si posiziona come 'completamente nativa per Kubernetes', portando i vantaggi corrispondenti (integrazione estrema con metodi e entità del cluster K8s).
Tabella comparativa
Quindi, la conclusione dell'articolo è questa enorme tabella:
È cliccabile per un'esperienza di visualizzazione più dettagliata ed è disponibile anche in formato .
Tiriamo le somme
L'obiettivo dell'articolo è fornire una comprensione più completa (sebbene non esaustiva!) di quale scelta fare nel tuo caso specifico. Come sempre, ogni controller ha i suoi pro e contro…
Il classico Ingress di Kubernetes è apprezzato per la sua disponibilità e collaudatezza, con funzionalità sufficientemente ricche — in generale, dovrebbe 'essere più che sufficiente'. Tuttavia, se ci sono requisiti elevati in termini di stabilità, livello di funzionalità e sviluppo, è consigliabile considerare Ingress con NGINX Plus e un abbonamento a pagamento. Kong ha un vastissimo set di plugin (e, di conseguenza, le funzionalità fornite), e nella versione a pagamento ce ne sono anche di più. Ha ampie possibilità di operare come API Gateway, configurazione dinamica basata su risorse CRD, così come servizi Kubernetes di base.
Se hai requisiti elevati per il bilanciamento e i metodi di autenticazione, considera Traefik e HAProxy. Questi sono progetti Open Source, collaudati nel tempo, molto stabili e in continua evoluzione. Contour è stato introdotto solo qualche anno fa, ma appare comunque troppo giovane e ha solo funzionalità di base, aggiunte sopra Envoy. Se ci sono requisiti per avere/inserire un WAF davanti all'applicazione, dovresti considerare lo stesso Ingress di Kubernetes o HAProxy.
I prodotti più ricchi di funzionalità sono quelli costruiti sulla base di Envoy, in particolare Istio. Si presenta come una soluzione complessa che 'può fare tutto', il che, tuttavia, significa anche una soglia di ingresso significativamente più alta in termini di configurazione/implementazione/amministrazione rispetto ad altre soluzioni.
Come standard controller, abbiamo scelto e continuiamo a utilizzare Ingress di Kubernetes, che copre l'80-90% delle necessità. È piuttosto affidabile, facile da configurare e scalabile. In generale, in assenza di requisiti specifici, dovrebbe essere adatto alla maggior parte dei cluster/applicazioni. Altri prodotti altrettanto versatili e relativamente semplici da usare includono Traefik e HAProxy.
P.S.
Leggete anche nel nostro blog:
- «Tornare ai microservizi con Istio»: , , ;
- «»;
- «».
Fonte: habr.com
