Quando avvii un cluster Kubernetes per un'applicazione specifica, devi capire cosa rappresentano l'applicazione stessa, l'azienda e gli sviluppatori per questa risorsa. Con queste informazioni, puoi iniziare a prendere una decisione architettonica e, in particolare, scegliere un controller di ingresso specifico, di cui oggi esiste già un gran numero. Per avere un'idea di base delle opzioni disponibili senza dover esaminare molti articoli/documentazione, ecc., abbiamo preparato questa panoramica, inclusi i principali controller di ingresso (pronti per la produzione).
Ci auguriamo che possa aiutare i colleghi nella scelta di una soluzione architettonica, almeno diventerà un punto di partenza per ottenere informazioni più dettagliate ed esperimenti pratici. In precedenza, abbiamo studiato altri materiali simili in rete e, stranamente, non abbiamo trovato un'unica recensione più o meno completa e, soprattutto, strutturata. Quindi colmiamo questa lacuna!
criteri
In linea di principio, per fare un confronto e ottenere qualsiasi risultato utile, è necessario comprendere non solo l'area tematica, ma anche disporre di un elenco specifico di criteri che definiranno il vettore di 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: preparati che in ogni caso dovrai studiare separatamente tutti i tuoi dettagli e dettagli.
Ma inizierò con le caratteristiche che sono diventate così familiari da essere implementate in tutte le soluzioni e non essere considerate:
- scoperta dinamica dei servizi (scoperta dei servizi);
- terminazione SSL;
- lavorare con i websocket.
Ora per i punti di confronto:
Protocolli supportati
Uno dei criteri di selezione fondamentali. Il tuo software potrebbe non funzionare su HTTP standard o potrebbe richiedere il lavoro su più protocolli contemporaneamente. Se il tuo caso non è standard, assicurati di tenere conto di questo fattore in modo da non dover riconfigurare il cluster in un secondo momento. Per tutti i controller, l'elenco dei protocolli supportati varia.
software al centro
Esistono diverse varianti di applicazioni su cui si basa il controller. Quelli popolari sono nginx, traefik, haproxy, envoy. In generale, potrebbe non avere molto effetto sul modo in cui il traffico viene ricevuto e trasmesso, ma è sempre utile conoscere le potenziali sfumature e caratteristiche di ciò che è "sotto il cofano".
Instradamento del traffico
Sulla base di cosa è possibile prendere una decisione sulla direzione del traffico verso un particolare servizio? Di solito si tratta di host e percorso, ma ci sono possibilità aggiuntive.
Spazio dei nomi all'interno di un cluster
Spazio dei nomi (spazio dei nomi): la capacità di suddividere logicamente le risorse in Kubernetes (ad esempio, sul palco, produzione, ecc.). Esistono controller di ingresso che devono essere installati separatamente in ogni spazio dei nomi (e quindi possono dirigere il traffico solo ai baccelli di questo spazio). E ci sono quelli (e la loro netta maggioranza) che lavorano a livello globale per l'intero cluster: in essi il traffico è diretto a qualsiasi pod del cluster, indipendentemente dallo spazio dei nomi.
Campioni per monte
In che modo il traffico viene indirizzato alle istanze integre dell'applicazione e dei servizi? Sono disponibili opzioni con controlli attivi e passivi, nuovi tentativi, interruttori automatici (Per maggiori dettagli si veda, ad esempio, ), controlli sanitari personalizzati, ecc. Un parametro molto importante se si hanno requisiti elevati per la disponibilità e la rimozione tempestiva dei servizi falliti dal bilanciamento.
Algoritmi di bilanciamento
Ci sono molte opzioni: dal tradizionale all'esotico , così come singole funzionalità come .
autenticazione
Quali schemi di autorizzazione supporta il titolare del trattamento? Basic, digest, oauth, external-auth: penso che queste opzioni dovrebbero essere familiari. Questo è un criterio importante se sono presenti molti loop di sviluppatori (e/o solo privati) a cui si accede tramite Ingress.
Distribuzione del traffico
Il controller supporta meccanismi di distribuzione del traffico comunemente usati come rollout canary (canary), test A / B, mirroring del traffico (mirroring / shadowing)? Questo è un argomento davvero dolente per le applicazioni che richiedono una gestione del traffico accurata e precisa per test produttivi, debug di bug del prodotto offline (o con perdite minime), analisi del traffico e così via.
Abbonamento a pagamento
Esiste un'opzione a pagamento per il controller, con funzionalità avanzate e/o supporto tecnico?
Interfaccia utente grafica (interfaccia utente Web)
Esiste una GUI per gestire la configurazione del controller? Principalmente per "maneggevolezza" e/o per chi ha necessità di apportare qualche modifica alla configurazione di Ingress'a, ma lavorare con i template "grezzi" è scomodo. Può essere utile se gli sviluppatori vogliono condurre al volo alcuni esperimenti con il traffico.
Convalida JWT
La presenza della convalida integrata dei token web JSON per l'autorizzazione e la convalida dell'utente fino all'applicazione finale.
Possibilità di personalizzazione della configurazione
Estensibilità del modello nel senso di avere meccanismi che consentono di aggiungere le proprie direttive, flag, ecc. ai modelli di configurazione standard.
Meccanismi di protezione DDOS di base
Semplici algoritmi di limite di velocità o opzioni di filtraggio del traffico più complesse basate su indirizzi, whitelist, paesi, ecc.
Richiedi traccia
La capacità di monitorare, tracciare ed eseguire il debug delle richieste da Ingress a servizi/pod specifici e, idealmente, anche tra servizi/pod.
WAF
Sostegno .
Controllori
L'elenco dei controllori è stato formato sulla base di и . Ne abbiamo esclusi alcuni dalla revisione a causa della specificità o della bassa prevalenza (fase iniziale di sviluppo). Il resto è discusso di seguito. Iniziamo con una descrizione generale delle soluzioni e proseguiamo con una tabella riassuntiva.
Ingresso da Kubernetes
Sito web:
Licenza: Apache 2.0
Questo è il controller ufficiale per Kubernetes ed è stato sviluppato dalla community. Ovviamente dal nome, è basato su nginx ed è completato da un diverso set di plugin Lua utilizzati per implementare funzionalità aggiuntive. A causa della popolarità di nginx stesso e delle modifiche minime apportate ad esso quando viene utilizzato come controller, questa opzione potrebbe essere la più semplice e facile da configurare per l'ingegnere medio (con esperienza web).
Ingresso di NGINX Inc.
Sito web:
Licenza: Apache 2.0
Il prodotto ufficiale degli sviluppatori nginx. Ha una versione a pagamento basata su . L'idea principale è un alto livello di stabilità, una retrocompatibilità costante, l'assenza di moduli estranei e la dichiarata maggiore velocità (rispetto al controller ufficiale), ottenuta grazie al rifiuto di Lua.
La versione gratuita è notevolmente ridotta, anche se confrontata con il controller ufficiale (a causa della mancanza degli stessi moduli Lua). Allo stesso tempo, quello a pagamento ha una funzionalità aggiuntiva abbastanza ampia: metriche in tempo reale, convalida JWT, controlli sanitari attivi e altro. Un importante vantaggio rispetto a NGINX Ingress è il pieno supporto per il traffico TCP/UDP (e anche nella versione community!). Meno - funzione di distribuzione del traffico, che, tuttavia, "ha la massima priorità per gli sviluppatori", ma richiede tempo per essere implementata.
Ingresso Kong
Sito web:
Licenza: Apache 2.0
Prodotto sviluppato da Kong Inc. in due versioni: commerciale e gratuita. Basato su nginx, che è stato esteso con un gran numero di moduli Lua.
Inizialmente, era incentrato sull'elaborazione e l'instradamento delle richieste API, ad es. come gateway API, ma al momento è diventato un vero e proprio controller Ingress. Principali vantaggi: molti moduli aggiuntivi (compresi quelli di sviluppatori di terze parti) facili da installare e configurare e con l'aiuto dei quali viene implementata un'ampia gamma di funzionalità aggiuntive. Tuttavia, le funzioni integrate offrono già molte possibilità. La configurazione del lavoro viene eseguita utilizzando le risorse CRD.
Una caratteristica importante del prodotto: lavorare all'interno dello stesso contorno (invece che con spazi dei nomi incrociati) è un argomento controverso: per alcuni sembrerà uno svantaggio (devi produrre entità per ogni contorno), e per qualcuno è una caratteristica ( BоMaggiore livello di isolamento, come se un controller è guasto, il problema è limitato al solo circuito).
Traefik
Sito web:
Licenza: MIT
Un proxy originariamente creato per funzionare con il routing delle richieste per i microservizi e il relativo ambiente dinamico. Quindi, molte funzionalità utili: aggiornamento della configurazione senza riavviare affatto, supporto per un gran numero di metodi di bilanciamento, interfaccia web, inoltro delle metriche, supporto per vari protocolli, API REST, versioni canary e molto altro. Un'altra caratteristica interessante è il supporto per i certificati Let's Encrypt pronti all'uso. Lo svantaggio è che per organizzare l'alta disponibilità (HA), il controller dovrà installare e connettere il proprio storage KV.
HAProxy
Sito web:
Licenza: Apache 2.0
HAProxy è noto da tempo come proxy e bilanciamento del traffico. Come parte di un cluster Kubernetes, offre un aggiornamento della configurazione "soft" (senza perdita di traffico), rilevamento del servizio basato su DNS, configurazione dinamica tramite API. Può essere interessante personalizzare completamente il modello di configurazione sostituendo il CM, così come la possibilità di utilizzare le funzioni della libreria Sprig al suo interno. In generale, l'enfasi principale della soluzione è sull'alta velocità, la sua ottimizzazione ed efficienza nelle risorse consumate. Il vantaggio del controller è il supporto di un numero record di diversi metodi di bilanciamento.
Voyager
Sito web:
Licenza: Apache 2.0
Basato sul controller HAproxy, che si posiziona come una soluzione universale che supporta un'ampia gamma di funzionalità su un gran numero di provider. Viene offerta un'opportunità per bilanciare il traffico su L7 e L4 e il bilanciamento del traffico TCP L4 nel suo insieme può essere definito una delle caratteristiche chiave della soluzione.
Contorno
Sito web:
Licenza: Apache 2.0
Questa soluzione non si basa solo su Envoy: è stata sviluppata da insieme con gli autori di questo popolare proxy. Una caratteristica importante è la possibilità di separare il controllo delle risorse Ingress utilizzando le risorse CRD IngressRoute. Per le organizzazioni con molti team di sviluppo che utilizzano lo stesso cluster, questo aiuta a massimizzare la sicurezza di lavorare con il traffico nei loop vicini e proteggerli da errori durante la modifica delle risorse Ingress.
Offre inoltre una serie estesa di metodi di bilanciamento (sono disponibili mirroring delle richieste, ripetizione automatica, limitazione della frequenza delle richieste e molto altro), monitoraggio dettagliato del flusso di traffico e dei guasti. Forse per qualcuno sarà uno svantaggio significativo la mancanza di supporto per le sessioni appiccicose (sebbene il lavoro ).
Ingresso Istio
Sito web:
Licenza: Apache 2.0
Una soluzione service mesh completa 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, Envoy viene utilizzato come proxy sidecar per ogni servizio. In sostanza, si tratta di una grande mietitrebbia che “può fare qualsiasi cosa”, e la sua idea principale è la massima gestibilità, estensibilità, sicurezza e trasparenza. Con esso, puoi ottimizzare l'instradamento del traffico, l'autorizzazione di accesso tra i servizi, il bilanciamento, il monitoraggio, le versioni canary e molto altro. Leggi di più su Istio nella serie di articoli "'.
Ambassador
Sito web:
Licenza: Apache 2.0
Un'altra soluzione basata su Envoy. Ha versioni gratuite e commerciali. È posizionato come "completamente nativo di Kubernetes", che porta i vantaggi corrispondenti (stretta integrazione con i metodi e le entità del cluster K8s).
tavola di comparazione
Quindi, il culmine dell'articolo è questo enorme tavolo:
È cliccabile per una visione più ravvicinata ed è disponibile anche nel formato .
Riassumere
Lo scopo di questo articolo è fornire una comprensione più completa (tuttavia, non esaustiva!) di quale scelta fare nel tuo caso particolare. Come al solito, ogni controller ha i suoi vantaggi e svantaggi...
Il classico Ingress di Kubernetes è buono per la sua disponibilità e provenza, funzionalità abbastanza ricche - nel caso generale, dovrebbe essere "abbastanza per gli occhi". Tuttavia, se ci sono maggiori requisiti di stabilità, livello di funzionalità e sviluppo, dovresti prestare attenzione a Ingress con NGINX Plus e un abbonamento a pagamento. Kong ha il set più ricco di plug-in (e, di conseguenza, le opportunità che offrono) e nella versione a pagamento ce ne sono ancora di più. Ha ampie opportunità di lavorare come gateway API, configurazione dinamica basata su risorse CRD e servizi Kubernetes di base.
Con l'aumento dei requisiti per il bilanciamento e i metodi di autorizzazione, dai un'occhiata a Traefik e HAProxy. Si tratta di progetti Open Source, comprovati negli anni, molto stabili e in fase di sviluppo attivo. Contour è uscito da un paio d'anni, ma sembra ancora troppo giovane e ha solo funzionalità di base aggiunte a Envoy. Se ci sono requisiti per la presenza / incorporamento di WAF davanti all'applicazione, dovresti prestare attenzione allo stesso Ingress da Kubernetes o HAProxy.
E i più ricchi in termini di funzionalità sono i prodotti basati su Envoy, in particolare Istio. Sembra essere una soluzione completa che “può fare qualsiasi cosa”, il che però significa anche una soglia di ingresso per configurazione/avvio/amministrazione significativamente più alta rispetto ad altre soluzioni.
Abbiamo scelto e utilizziamo ancora Ingress di Kubernetes come controller standard, che copre l'80-90% delle esigenze. È abbastanza affidabile, facile da configurare ed espandere. In generale, in assenza di requisiti specifici, dovrebbe adattarsi alla maggior parte dei cluster/applicazioni. Degli stessi prodotti universali e relativamente semplici, si possono consigliare Traefik e HAProxy.
PS
Leggi anche sul nostro blog:
- "Torna ai microservizi con Istio": , , ;
- «";
- «'.
Fonte: habr.com