Quandu lanciate un cluster Kubernetes per una applicazione specifica, avete bisognu di capisce ciò chì l'applicazione stessa, l'affari è i sviluppatori ponenu à sta risorsa. Cù sta infurmazione, pudete principià per piglià una decisione architettonica è, in particulare, sceglie un controller Ingress specificu, di quale ci sò digià un gran numaru oghje. Per avè una idea basica di l'opzioni dispunibili senza avè da passà per assai articuli / ducumentazioni, etc., avemu preparatu sta panoramica, cumpresi i principali controller di Ingress (pronti per a produzzione).
Speremu chì aiuterà i culleghi in a scelta di una soluzione architettonica - almenu diventerà un puntu di partenza per ottene infurmazioni più dettagliate è esperimenti pratichi. Prima, avemu studiatu altri materiali simili nantu à a reta è, stranu, ùn truvamu micca una sola rivista più o menu cumpleta, è più impurtante - strutturata - rivista. Dunque, cumpiemu quella lacuna !
Criterii
In principiu, per fà un paraguni è uttene ogni risultatu utile, avete bisognu di capisce micca solu l'area di u sughjettu, ma ancu avè una lista specifica di criteri chì stabiliscerà u vettore di ricerca. Senza pretendenu di analizà tutti i casi pussibuli di usu di Ingress / Kubernetes, avemu pruvatu à mette in risaltu i requisiti più generali per i cuntrolli - esse preparatu chì in ogni casu duverete studià tutte e vostre specifiche è particularità separatamente.
Ma principiaraghju cù e caratteristiche chì sò diventate cusì familiari chì sò implementate in tutte e soluzioni è ùn sò micca cunsiderate:
- scuperta dinamica di servizii (scuperta di serviziu);
- terminazione SSL;
- travaglià cù websockets.
Avà per i punti di paragone:
Protokolli supportati
Unu di i criterii di selezzione fundamentali. U vostru software ùn pò micca travaglià in HTTP standard, o pò esse bisognu di travaglià in parechji protokolli à una volta. Se u vostru casu ùn hè micca standard, assicuratevi di piglià stu fattore in contu per ùn avè micca cunfigurà u cluster dopu. Per tutti i cuntrolli, a lista di protokolli supportati varieghja.
software à u core
Ci hè parechje variazioni di applicazioni chì u controller hè basatu. I populari sò nginx, traefik, haproxy, envoy. In u casu generale, ùn pò micca avè assai effettu nantu à cumu u trafficu hè ricivutu è trasmessu, ma hè sempre utile per cunnosce e sfumature potenziali è e caratteristiche di ciò chì hè "sottu u cappucciu".
Instradamentu di u trafficu
In basa di ciò chì hè pussibule di piglià una decisione nantu à a direzzione di u trafficu à un serviziu particulari? Di solitu questi sò host è percorsu, ma ci sò pussibulità supplementari.
Spaziu di nomi in un cluster
Namespace (namespace) - a capacità di split logically risorse in Kubernetes (per esempiu, in scena, pruduzzione, etc.). Ci sò cuntrolli di Ingress chì deve esse stallati separatamente in ogni spaziu di nomi (è poi pò dirighje u trafficu solu à i baccelli di stu spaziu). E ci sò quelli (è a so maiuranza chjara) chì travaglianu globalmente per tuttu u cluster - in elli u trafficu hè direttu à qualsiasi pod di u cluster, indipendentemente da u namespace.
Campioni per upstreams
Cumu hè u trafficu direttu à i casi sani di l'applicazione, servizii? Ci sò opzioni cù cuntrolli attivi è passivi, riprova, circuit breakers (Per più dettagli, vede, per esempiu, ), implementazioni propiu di cuntrolli di salute (cuntrolli di salute persunalizati), etc. Un paràmetru assai impurtante si avete esigenze elevate per a dispunibilità è a rimozione puntuale di i servizii falluti da l'equilibriu.
Algoritmi di equilibriu
Ci sò parechje scelte: da tradiziunale à l'esoticu , è ancu e caratteristiche individuali cum'è .
Autenticazione
Chì schemi d'autorizazione sustene u cuntrollu? Basic, digest, oauth, external-auth - Pensu chì queste opzioni deve esse familiar. Questu hè un criteriu impurtante s'ellu ci sò parechji loops di sviluppatori (è / o solu privati) chì sò accede à traversu Ingress.
Distribuzione di u trafficu
U controller supporta i meccanismi di distribuzione di trafficu cumunimenti usati cum'è rollouts canari (canari), test A / B, mirroring di trafficu (mirroring / shadowing)? Questu hè un sughjettu veramente dulore per l'applicazioni chì necessitanu una gestione di u trafficu precisa è precisa per teste produttive, debugging bugs di produttu off-line (o cù perdita minima), analisi di trafficu, etc.
Abbonamentu pagatu
Ci hè una opzione pagata per u controller, cù funziunalità avanzata è / o supportu tecnicu?
Interfaccia d'utilizatore grafica (UI Web)
Ci hè una GUI per gestisce a cunfigurazione di u controller? Principalmente per "handiness" è / o per quelli chì anu bisognu di fà qualchi cambiamenti à a cunfigurazione Ingress'a, ma u travagliu cù mudelli "raw" hè inconveniente. Pò esse utile se i sviluppatori volenu fà qualchi esperimenti cù u trafficu nantu à a mosca.
Validazione JWT
A presenza di validazione integrata di i tokens web JSON per l'autorizazione è a validazione di l'utilizatore à l'applicazione finale.
Possibilità di persunalizazione di cunfigurazione
Estensibilità di mudelli in u sensu di avè miccanismi chì permettenu di aghjunghje i vostri direttivi, bandiere, etc. à mudelli di cunfigurazione standard.
Meccanismi basi di prutezzione DDOS
Algoritmi simplici di limitu di tariffu o opzioni di filtrazione di trafficu più cumplessu basatu nantu à indirizzi, liste bianche, paesi, etc.
Richiede traccia
A capacità di monitorà, traccia è debug richieste da Ingressi à servizii / pods specifichi, è idealmente ancu trà servizii / pods.
WAF
sustegnu .
Controllers
A lista di cuntrolli hè stata furmata nantu à a basa и . Escludemu alcuni di elli da a rivista per via di specificità o prevalenza bassa (prima fase di sviluppu). U restu hè discutitu quì sottu. Accuminciamu cù una descrizzione generale di e suluzioni è cuntinueghja cù una tavola riassuntu.
Ingressu da Kubernetes
situ:
Licenza: Apache 2.0
Questu hè u controller ufficiale per Kubernetes è hè sviluppatu da a cumunità. Ovviamente da u nome, hè basatu annantu à nginx è hè cumplementatu da un altru settore di plugins Lua utilizati per implementà funzioni supplementari. A causa di a popularità di nginx stessu è di e mudificazioni minime à questu quandu s'utilice cum'è un controller, questa opzione pò esse a più faciule è più faciule da cunfigurà per l'ingegnere mediu (cù l'esperienza web).
Ingressu da NGINX Inc.
situ:
Licenza: Apache 2.0
U pruduttu ufficiale di i sviluppatori nginx. Havi una versione pagata basatu nantu . L'idea principale hè un altu livellu di stabilità, una cumpatibilità custante in daretu, l'absenza di qualsiasi moduli estranei è a velocità aumentata dichjarata (in paragone à u controller ufficiale), ottenuta per via di u rifiutu di Lua.
A versione libera hè significativamente ridutta, ancu quandu paragunatu cù u controller ufficiale (per via di a mancanza di i stessi moduli Lua). À u listessu tempu, u pagatu hà una funziunalità addiziale abbastanza larga: metriche in tempu reale, validazione JWT, cuntrolli di salute attivi è più. Un vantaghju impurtante annantu à NGINX Ingress hè un supportu tutale per u trafficu TCP / UDP (è ancu in a versione di a cumunità!). Minus - A funzione di distribuzione di trafficu, chì, però, "hà a più alta priorità per i sviluppatori", ma piglia tempu per implementà.
Kong Ingress
situ:
Licenza: Apache 2.0
Pruduttu sviluppatu da Kong Inc. in duie versioni: cummerciale è liberu. Basatu nantu à nginx, chì hè stata allargata cù un gran numaru di moduli Lua.
Inizialmente, era focu annantu à u trattamentu è l'instradamentu di e dumande API, i.e. cum'è un API Gateway, ma à u mumentu hè diventatu un controller d'Ingress à pienu livellu. Vantaghji principali: assai moduli supplementari (cumpresi quelli di sviluppatori di terzu) chì sò faciuli d'installà è cunfigurà è cù l'aiutu di quale una larga gamma di funzioni supplementari hè implementata. Tuttavia, e funzioni integrate offrenu digià parechje pussibulità. A cunfigurazione di u travagliu hè fatta cù risorse CRD.
Una funzione impurtante di u pruduttu - travaglià in u stessu contornu (invece di spazii incruciati) hè un tema cuntruversu: per certi parerà un svantaghju (avete da pruduce entità per ogni contornu), è per qualchissia hè una funzione ( bоU più altu livellu di isolamentu, cum'è se un controller hè rottu, allora u prublema hè limitatu à u circuitu solu).
Traefic
situ:
Licenza: MIT
Un proxy chì hè statu originariamente creatu per travaglià cù a dumanda di routing per i microservizi è u so ambiente dinamicu. Dunque, parechje funzioni utili: aghjurnà a cunfigurazione senza rebooting in tuttu, supportu per un gran numaru di metudi di equilibriu, interfaccia web, trasmissioni di metriche, supportu per diversi protokolli, API REST, versioni canari, è assai di più. Un'altra bella funzione hè u supportu per i certificati Let's Encrypt fora di a scatula. U svantaghju hè chì per urganizà alta dispunibilità (HA), u controller hà bisognu di installà è cunnette u so propiu almacenamentu KV.
HAProxy
situ:
Licenza: Apache 2.0
HAProxy hè longu cunnisciutu cum'è proxy è equilibratore di trafficu. Comu parte di un cluster Kubernetes, offre un aghjurnamentu di cunfigurazione "soft" (senza perdita di trafficu), scuperta di serviziu basatu in DNS, cunfigurazione dinamica cù API. Pò esse attraente per persunalizà cumplettamente u mudellu di cunfigurazione rimpiazzendu u CM, è ancu a capacità di utilizà e funzioni di biblioteca Sprig in questu. In generale, l'enfasi principale di a suluzione hè nantu à l'alta veloce, a so ottimisazione è l'efficienza in i risorse cunsumati. U vantaghju di u controller hè u supportu di un numeru record di diversi metudi di equilibriu.
Voyager
situ:
Licenza: Apache 2.0
Basatu nantu à u controller HAproxy, chì hè posizionatu cum'è una suluzione universale chì sustene una larga gamma di funzioni nantu à un gran numaru di fornituri. L'uppurtunità hè offerta per equilibrà u trafficu in L7 è L4, è equilibrà u trafficu TCP L4 in generale pò esse chjamatu una di e caratteristiche chjave di a suluzione.
Contour
situ:
Licenza: Apache 2.0
Sta suluzione ùn hè micca solu basatu nantu à Envoy: hè statu sviluppatu da inseme cù l'autori di stu proxy populari. Una funzione impurtante hè a capacità di separà u cuntrollu di e risorse Ingress usendu risorse CRD IngressRoute. Per l'urganisazione cù parechje squadre di sviluppu chì utilizanu u stessu cluster, questu aiuta à maximizà a sicurità di travaglià cù u trafficu in i loops vicini è prutegge da l'errore quandu cambiate risorse Ingress.
Offre ancu un inseme allargatu di metudi di equilibriu (ci hè mirroring of requests, auto-repeat, limiting the rate of requests, è assai di più), monitoraghju detallatu di u flussu di trafficu è fallimenti. Forse per qualcunu serà un inconveniente significativu a mancanza di supportu per e sessioni appiccicose (ancu se u travagliu ).
Istio Ingress
situ:
Licenza: Apache 2.0
Una suluzione cumpleta di maglia di serviziu chì ùn hè micca solu un controller Ingress chì gestisce u trafficu entrante da l'esternu, ma ancu cuntrola tuttu u trafficu in u cluster. Sottu u cappucciu, Envoy hè adupratu cum'è proxy sidecar per ogni serviziu. In essenza, questu hè una grande combinazione chì "puderà fà qualcosa", è a so idea principale hè a massima gestione, estensibilità, sicurezza è trasparenza. Cù ellu, pudete fine-tune u routing di u trafficu, l'autorizazione d'accessu trà i servizii, l'equilibriu, u monitoraghju, i canarii, è assai di più. Leghjite più nantu à Istio in a serie di articuli "».
Ambasciatore
situ:
Licenza: Apache 2.0
Una altra suluzione basatu annantu à Envoy. Havi versioni gratuiti è cummerciale. Hè posizionatu cum'è "completamente nativu di Kubernetes", chì porta i vantaghji currispondenti (integrazione stretta cù i metudi è l'entità di u cluster K8s).
tabella di paraguni
Dunque, a culminazione di l'articulu hè questu tavulu enormu:
Hè clicable per una vista più vicinu, è hè ancu dispunibule in u furmatu .
Semu summatu
U scopu di stu articulu hè di furnisce una cunniscenza più cumpleta (in ogni casu, in manera micca exhaustiva!) Di quale scelta di fà in u vostru casu particulari. Comu di solitu, ogni controller hà i so vantaghji è svantaghji ...
U classicu Ingress da Kubernetes hè bonu per a so dispunibilità è a prova, ricchezza abbastanza funzioni - in u casu generale, deve esse "abbastanza per l'ochji". In ogni casu, s'ellu ci hè più esigenza per a stabilità, u livellu di funziunalità è u sviluppu, duvete attente à Ingress cù NGINX Plus è un abbonamentu pagatu. Kong hà u più riccu di plug-in (è, per quessa, l'opportunità chì furnisce), è in a versione pagata ci sò ancu più di elli. Hà ampie opportunità per travaglià cum'è un Gateway API, cunfigurazione dinamica basata nantu à risorse CRD, è ancu servizii basi Kubernetes.
Cù esigenze aumentate per i metudi di equilibriu è d'autorizazione, fighjate à Traefik è HAProxy. Quessi sò prughjetti Open Source, pruvati annantu à l'anni, assai stabili è attivamente sviluppati. Contour hè stata fora per un paru d'anni avà, ma pare sempre troppu ghjovanu è hà solu funzioni di basa aghjuntu nantu à Envoy. Se ci sò esigenze per a presenza / incrustazione di WAF davanti à l'applicazione, duvete attente à u stessu Ingress da Kubernetes o HAProxy.
È i più ricchi in termini di funziunalità sò i prudutti custruiti nantu à Envoy, in particulare Istio. Sembra esse una soluzione cumpleta chì "puderà fà qualcosa", chì, però, significa ancu un sogliu di ingressu significativamente più altu per a cunfigurazione / lanciamentu / amministrazione chè altre soluzioni.
Avemu sceltu è sempre aduprà Ingress da Kubernetes cum'è un controller standard, chì copre 80-90% di i bisogni. Hè abbastanza affidabile, faciule da cunfigurà è espansione. In generale, in mancanza di esigenze specifiche, deve esse adattatu à a maiò parte di i cluster / applicazioni. Di i stessi prudutti universali è relativamente simplici, Traefik è HAProxy ponu esse cunsigliatu.
PS
Leghjite puru nant'à u nostru blog:
- "Torna à i microservizi cù Istio": , , ;
- «";
- «».
Source: www.habr.com