Quando si avvia un cluster Kubernetes per un'applicazione specifica, è importante comprendere quali sono i requisiti che questa risorsa impone all'applicazione stessa, al business e agli sviluppatori. Con queste informazioni, è possibile procedere a una decisione architettonica e, in particolare, alla scelta di un controller Ingress specifico, di cui oggi ci sono già molte opzioni. Per fornire una panoramica di base delle opzioni disponibili senza dover esaminare numerosi articoli/documentazione, abbiamo preparato questa panoramica, includendo i principali controller Ingress (pronti per la produzione).
Ci auguriamo che possa aiutare i colleghi nella scelta della soluzione architettonica - almeno sarà un punto di partenza per ottenere informazioni più dettagliate ed esperimenti pratici. Inizialmente, abbiamo esaminato altri materiali simili online e, stranamente, non abbiamo trovato alcuna panoramica completa e, soprattutto, strutturata. Quindi riempiamo questo vuoto!
Criteri
Per poter fare un confronto e ottenere risultati utili, è necessario comprendere non solo il contesto, ma anche avere un elenco specifico di criteri che definirà la direzione della ricerca. Senza pretendere di analizzare tutti i possibili casi d'uso di Ingress/Kubernetes, abbiamo cercato di evidenziare i requisiti più generali per i controller - preparatevi, perché ogni specificità e dettaglio dovrà comunque essere studiato separatamente.
Ma cominciamo con le caratteristiche che sono diventate così familiari da essere implementate in tutte le soluzioni e non vengono esaminate:
- rilevamento dinamico dei servizi (service discovery);
- terminazione SSL;
- supporto per le websocket.
Ora passiamo ai punti di confronto:
Protocollo supportati
Uno dei criteri fondamentali per la scelta. Il tuo software potrebbe non funzionare secondo il protocollo HTTP standard o potrebbero essere necessari più protocolli contemporaneamente. Se il tuo caso è non standard, assicurati di considerare questo fattore, in modo da non dover riconfigurare il cluster in seguito. Per tutti i controller, l'elenco dei protocolli supportati varia.
Software di base
Ci sono diverse applicazioni su cui si basa il controller. Le più popolari sono nginx, traefik, haproxy, envoy. In generale, ciò potrebbe non influenzare troppo il modo in cui viene ricevuto e trasmesso il traffico, ma è sempre utile conoscere i potenziali dettagli e le peculiarità di ciò che c'è 'sotto il cofano'.
Routing del traffico
Su cosa si basa la decisione di indirizzare il traffico verso un particolare servizio? Di solito si tratta di host e path, ma ci possono essere anche opzioni aggiuntive.
Namespace all'interno del cluster
Lo spazio dei nomi (namespace) è la possibilità di suddividere logicamente le risorse in Kubernetes (ad esempio, in 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 quello spazio). Ce ne sono anche altri (e sono di gran lunga la maggioranza) che funzionano globalmente su tutto il cluster — in essi il traffico viene diretto in qualsiasi pod del cluster, indipendentemente dallo spazio dei nomi.
Probe per upstream
In che modo viene garantito l'instradamento del traffico verso istanze sane dell'applicazione, servizi? Ci sono opzioni con controlli attivi e passivi, tentativi di ripetizione (retries), circuit breaker (per maggiori dettagli vedere, ad esempio, nel ), implementazioni personalizzate dei controlli di stato (custom health checks) ecc. È un parametro molto importante se hai elevate richieste di disponibilità e un'uscita tempestiva dalla bilanciatura dei servizi falliti.
Algoritmi di bilanciamento
Ci sono molte opzioni: dai tradizionali fino a esotiche come , oltre a possibilità specifiche come .
Autenticazione
Quali schemi di autorizzazione supporta il controller? Basic, digest, oauth, external-auth — penso che queste opzioni ti siano familiari. È un criterio importante se vengono utilizzati molti ambienti per sviluppatori (e/o semplicemente chiusi), l'accesso ai quali avviene tramite Ingress.
Distribuzione del traffico
Il controller supporta meccanismi comunemente utilizzati per la distribuzione del traffico, come i rilasci canary, A/B testing e il mirroring del traffico (mirroring/shadowing)? Questo è davvero un tema delicato per le applicazioni che richiedono una gestione attenta e precisa del traffico per testare in produzione, risolvere problemi di prodotto non in contesto reale (o con perdite minime), analizzare il traffico, ecc.
Abbonamento a pagamento
Esiste una versione a pagamento del controller con funzionalità avanzate e/o supporto tecnico?
Interfaccia grafica (Web UI)
Esiste un'interfaccia grafica per la gestione della configurazione del controller? Principalmente per la "comodità" e/o per coloro che devono apportare modifiche alla configurazione di Ingress, ma lavorare con template "grezzi" è scomodo. Potrebbe essere utile nel caso in cui gli sviluppatori vogliano condurre esperimenti sul traffico in volo.
Validazione JWT
Verifica integrata dei token web JSON per l'autenticazione e la validazione dell'utente presso l'applicazione finale.
Opzioni di personalizzazione del config
Estendibilità dei template in termini di meccanismi che consentono di aggiungere direttive, flag, ecc. agli standard template di configurazione.
Meccanismi di base per la protezione da attacchi DDoS
Algoritmi semplici di rate limit o varianti più complesse di filtraggio del traffico basate su indirizzi, liste bianche, paesi, ecc.
Tracciamento delle richieste
Opzioni di monitoraggio, tracciamento e debug delle richieste da Ingress a servizi/pod specifici e, idealmente, anche tra servizi/pod.
WAF
Supporto .
Controller Ingress
L'elenco dei controller è stato compilato sulla base e . Alcuni di essi sono stati esclusi dalla revisione a causa della loro specificità o bassa diffusione (stadio di sviluppo precoce). Gli altri sono trattati di seguito. Iniziamo con una descrizione generale delle soluzioni e proseguiamo con una tabella riepilogativa.
Ingress di Kubernetes
Sito:
Licenza: Apache 2.0
Questo è un controller ufficiale per Kubernetes sviluppato dalla comunità. Come suggerisce il nome, è basato su nginx ed è arricchito con vari plugin Lua utilizzati per implementare funzionalità aggiuntive. Grazie alla popolarità di nginx e alle modifiche minime applicate ad esso quando utilizzato 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à, compatibilità retroattiva costante, assenza di moduli estranei e una velocità dichiaratamente aumentata (rispetto al controller ufficiale), raggiunta grazie all'abbandono di Lua.
La versione gratuita è sostanzialmente ridotta, anche rispetto al controller ufficiale (a causa dell'assenza dei suddetti moduli Lua). La versione a pagamento ha un funzionalità aggiuntiva abbastanza ampia: metriche in tempo reale, validazione JWT, controlli attivi e altro ancora. Un'importante vantaggio rispetto a NGINX Ingress è il supporto completo per il traffico TCP/UDP (anche nella versione community!). Contro — di 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 varianti: commerciale e gratuita. Basato su nginx, le cui possibilità sono ampliate da un gran numero di moduli Lua.
Inizialmente era orientato alla gestione e al routing delle richieste API, ossia come API Gateway, ma attualmente è diventato un vero e proprio controller Ingress. I principali vantaggi: numerosi moduli aggiuntivi (inclusi quelli di sviluppatori di terze parti) che sono facili da installare e configurare e attraverso i quali si realizzano un ampio spettro di funzionalità aggiuntive. Tuttavia, le funzioni integrate già offrono molte possibilità. La configurazione del funzionamento avviene tramite risorse CRD.
Una caratteristica importante del prodotto è che il funzionamento all'interno di un singolo contesto (invece di cross-namespaced) è un tema controverso: per alcuni sembra un difetto (bisogna creare entità per ogni contesto), mentre per altri è una funzionalità (maggiore livello di isolamento, poiché se un controller si rompe, il problema è limitato a un solo contesto).uniù alto livello di isolamento, poiché se un controller si guasta, il problema è limitato a un solo contesto).
Traefik
Sito:
Licenza: MIT
Un proxy che è stato originariamente progettato per gestire la routing delle richieste per microservizi e il loro ambiente dinamico. Da qui molte funzionalità utili: aggiornamento della configurazione senza riavvii, supporto per un gran numero di metodi di bilanciamento, interfaccia web, forwarding delle metriche, supporto per vari protocolli, REST API, rilascio a canarino e molto altro. Un aspetto piacevole è anche il supporto per i certificati Let's Encrypt 'out of the box'. Uno svantaggio è che, per organizzare un'elevata disponibilità (HA), il controller dovrà installare e connettere un proprio archivio KV.
HAProxy
Sito:
Licenza: Apache 2.0
HAProxy è da tempo noto come proxy e bilanciatore di traffico. Nel contesto di un cluster Kubernetes, offre un 'soft' aggiornamento della configurazione (senza perdita di traffico), service discovery basato su DNS e configurazione dinamica tramite API. Un aspetto attraente è la completa personalizzazione del modello di configurazione tramite la sostituzione del ConfigMap, così come la possibilità di utilizzare funzioni della libreria Sprig. In generale, la principale enfasi di questa soluzione è sulle elevate prestazioni, l'ottimizzazione e l'efficienza delle risorse consumate. Un vantaggio del controller è il supporto per un numero record di modalità di bilanciamento diverse.
Voyager
Sito:
Licenza: Apache 2.0
Un controller basato su HAproxy, che si posiziona come una soluzione universale, supportando ampie funzionalità su un gran numero di fornitori. Offre la possibilità di bilanciare il traffico su L7 e L4, e il bilanciamento del traffico TCP L4 può essere considerato una delle caratteristiche chiave della soluzione.
Contour
Sito:
Licenza: Apache 2.0
Alla base di questa soluzione non è solo Envoy: è stato sviluppato congiuntamente con gli 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, questo aiuta a massimizzare la sicurezza nella gestione del traffico nei contorni adiacenti e a proteggerli dagli errori durante la modifica delle risorse Ingress.
È inoltre offerta una gamma ampliata di metodi di bilanciamento (inclusi il mirroring delle richieste, i riavvii automatici, le limitazioni del rateo delle richieste e molto altro), monitoraggio dettagliato del flusso di traffico e degli errori. Potrebbe essere una significativa svantaggio per alcuni l'assenza del supporto per sessioni sticky (anche se i lavori ).
Istio Ingress
Sito:
Licenza: Apache 2.0
Una soluzione completa di service mesh, che non è solo un controller Ingress che gestisce il traffico in entrata dall'esterno, ma controlla anche tutto il traffico all'interno del cluster. “Sotto il cofano”, come sidecar proxy per ogni servizio, viene utilizzato Envoy. In sostanza, è un grande combinato che "può fare tutto", e la sua idea principale è la massima gestibilità, scalabilità, sicurezza e trasparenza. Con esso puoi configurare dettagliatamente la gestione del traffico, l'autorizzazione dell'accesso tra i servizi, il bilanciamento, il monitoraggio, i rilasci canary e molto altro. Maggiori informazioni su Istio possono essere trovate in una serie di articoli "».
Ambassador
Sito:
Licenza: Apache 2.0
Un'altra soluzione basata su Envoy. Ha versioni gratuita e commerciale. Si posiziona come "completamente nativa per Kubernetes", il che porta vantaggi corrispondenti (integrazione stretta con metodi ed entità del cluster K8s).
Tabella comparativa
Dunque, il culmine dell'articolo è questa enorme tabella:
È cliccabile per consentire una visualizzazione più dettagliata ed è disponibile anche in formato .
Riepiloghiamo
L'obiettivo dell'articolo è fornire una comprensione più completa (sebbene non esaustiva!) di quale scelta fare nel vostro caso specifico. Come spesso accade, ogni controller ha i suoi punti di forza e di debolezza...
L'Ingress classico di Kubernetes è apprezzato per la sua disponibilità e affidabilità, con funzioni abbastanza ricche: in generale, dovrebbe essere "sufficiente per la maggior parte delle esigenze". Tuttavia, se ci sono requisiti elevati per stabilità, funzionalità e sviluppo, è opportuno considerare l'Ingress con NGINX Plus e abbonamento a pagamento. Kong dispone di un ampio set di plugin (e, di conseguenza, delle funzionalità che essi offrono), e nella versione a pagamento ce ne sono addirittura di più. Ha elevate capacità come API Gateway, configurazione dinamica basata su risorse CRD e servizi di base di Kubernetes.
Per esigenze elevate di bilanciamento e metodi di autorizzazione, prendi in considerazione Traefik e HAProxy. Questi sono progetti open source, collaudati nel tempo, molto stabili e in costante sviluppo. Contour è apparso ormai da un paio d'anni, ma appare ancora troppo giovane e ha solo funzionalità di base aggiunte sopra Envoy. Se ci sono requisiti per la presenza/integrazione di WAF davanti all'applicazione, è opportuno considerare lo stesso Ingress di Kubernetes o HAProxy.
I prodotti con le funzionalità più ricche sono quelli costruiti su base Envoy, in particolare Istio. Si presenta come una soluzione complessa, che "può fare tutto", il che, purtroppo, significa anche una soglia di entrata significativamente più alta in termini di configurazione/implementazione/amministrazione, rispetto alle altre soluzioni.
Abbiamo scelto come controller standard e continuiamo ad utilizzare l'Ingress di Kubernetes, che copre l'80-90% delle esigenze. È abbastanza affidabile, facile da configurare e da espandere. In generale, in assenza di requisiti specifici, dovrebbe adattarsi alla maggior parte dei cluster/applicazioni. Tra i prodotti altrettanto versatili e relativamente semplici, si possono raccomandare Traefik e HAProxy.
P.S.
Leggi anche nel nostro blog:
- «Tornare ai microservizi con Istio»: , , ;
- «»;
- «».
Fonte: habr.com
