Quan inicieu un clúster de Kubernetes per a una aplicació específica, heu d'entendre què representen l'aplicació, l'empresa i els desenvolupadors per a aquest recurs. Amb aquesta informació es pot començar a prendre una decisió arquitectònica i, en particular, escollir un controlador d'Ingress concret, del qual ja n'hi ha un gran nombre actualment. Per tenir una idea bàsica de les opcions disponibles sense haver de passar per molts articles / documentació, etc., hem preparat aquesta visió general, incloent els controladors d'entrada principals (preparats per a la producció).
Esperem que ajudi els companys a triar una solució arquitectònica, almenys esdevindrà un punt de partida per obtenir informació més detallada i experiments pràctics. Prèviament, vam estudiar altres materials similars a la xarxa i, curiosament, no vam trobar cap ressenya més o menys completa i, sobretot, estructurada. Així que omplim aquest buit!
criteris
En principi, per fer una comparació i obtenir qualsevol resultat útil, cal entendre no només l'àrea temàtica, sinó també tenir una llista específica de criteris que establiran el vector de recerca. Sense pretendre analitzar tots els casos possibles d'ús d'Ingress / Kubernetes, hem intentat destacar els requisits més generals dels controladors: estigueu preparats que, en tot cas, haureu d'estudiar tots els vostres detalls i particulars per separat.
Però començaré amb les característiques que s'han tornat tan familiars que s'implementen en totes les solucions i no es tenen en compte:
- descobriment dinàmic de serveis (descoberta de serveis);
- Terminació SSL;
- treballant amb websockets.
Ara per als punts de comparació:
Protocols suportats
Un dels criteris fonamentals de selecció. És possible que el vostre programari no funcioni amb l'HTTP estàndard o pot requerir treballar en diversos protocols alhora. Si el vostre cas no és estàndard, assegureu-vos de tenir en compte aquest factor perquè no hàgiu de tornar a configurar el clúster més endavant. Per a tots els controladors, la llista de protocols admesos varia.
programari al nucli
Hi ha diverses variacions d'aplicacions en què es basa el controlador. Els populars són nginx, traefik, haproxy, enviat. En el cas general, pot ser que no tingui gaire efecte sobre com es rep i es transmet el trànsit, però sempre és útil conèixer els possibles matisos i característiques del que hi ha "sota el capó".
Encaminament del trànsit
Sobre la base de què és possible prendre una decisió sobre la direcció del trànsit a un servei concret? Normalment són host i ruta, però hi ha possibilitats addicionals.
Espai de noms dins d'un clúster
Espai de noms (espai de noms): la capacitat de dividir lògicament els recursos a Kubernetes (per exemple, a l'escenari, producció, etc.). Hi ha controladors d'entrada que s'han d'instal·lar per separat a cada espai de noms (i després pot dirigir el trànsit només a les beines d'aquest espai). I n'hi ha (i la seva clara majoria) que funcionen globalment per a tot el clúster: en ells el trànsit es dirigeix a qualsevol pod del clúster, independentment de l'espai de noms.
Mostres per a aigües amunt
Com es dirigeix el trànsit a instàncies saludables de l'aplicació, serveis? Hi ha opcions amb comprovacions actives i passives, reintents, interruptors automàtics (Per a més detalls, vegeu, per exemple, ), controls de salut personalitzats, etc. Un paràmetre molt important si teniu alts requisits de disponibilitat i eliminació oportuna dels serveis fallits de l'equilibri.
Algoritmes d'equilibri
Hi ha moltes opcions: de tradicional a l'exòtic , així com característiques individuals com .
Autenticació
Quins esquemes d'autorització admet el controlador? Basic, digest, oauth, external-auth - Crec que aquestes opcions haurien de ser familiars. Aquest és un criteri important si hi ha molts bucles de desenvolupadors (i/o només privats) als quals s'accedeix mitjançant Ingress.
Distribució del trànsit
El controlador admet mecanismes de distribució de trànsit que s'utilitzen habitualment, com ara llançaments canaris (canari), proves A/B, rèplica de trànsit (replicació / ombra)? Aquest és un tema realment dolorós per a aplicacions que requereixen una gestió precisa i precisa del trànsit per a proves productives, depuració d'errors de producte fora de línia (o amb pèrdues mínimes), anàlisi de trànsit, etc.
Subscripció de pagament
Hi ha una opció de pagament per al controlador, amb funcionalitat ampliada i/o suport tècnic?
Interfície gràfica d'usuari (interfície d'usuari web)
Hi ha alguna GUI per gestionar la configuració del controlador? Principalment per "manabilitat" i/o per a aquells que necessiten fer alguns canvis a la configuració d'Ingress'a, però treballar amb plantilles "crues" és inconvenient. Pot ser útil si els desenvolupadors volen dur a terme alguns experiments amb trànsit sobre la marxa.
Validació JWT
La presència de validació integrada de fitxes web JSON per a l'autorització i validació de l'usuari a l'aplicació final.
Possibilitats de personalització de la configuració
Extensibilitat de plantilles en el sentit de disposar de mecanismes que permeten afegir les vostres pròpies directives, senyaladors, etc. a les plantilles de configuració estàndard.
Mecanismes bàsics de protecció DDOS
Algoritmes simples de límit de tarifa o opcions de filtratge de trànsit més complexes basades en adreces, llistes blanques, països, etc.
Demana traça
La capacitat de supervisar, fer un seguiment i depurar les sol·licituds d'Ingresses a serveis/pods específics, i idealment també entre serveis/pods.
WAF
suport .
Controladors
La llista de controladors es va formar a partir de и . Alguns d'ells en vam excloure de la revisió a causa de l'especificitat o de la baixa prevalença (etapa primerenca de desenvolupament). La resta es comenten a continuació. Comencem amb una descripció general de les solucions i continuem amb una taula resum.
Entrada des de Kubernetes
Pàgina Web:
Llicència: Apache 2.0
Aquest és el controlador oficial de Kubernetes i està sent desenvolupat per la comunitat. Òbviament, pel nom, es basa en nginx i es complementa amb un conjunt diferent de connectors Lua utilitzats per implementar funcions addicionals. A causa de la popularitat del propi nginx i de les modificacions mínimes que s'hi fan quan s'utilitza com a controlador, aquesta opció pot ser la més fàcil i fàcil de configurar per a l'enginyer mitjà (amb experiència web).
Entrada de NGINX Inc.
Pàgina Web:
Llicència: Apache 2.0
El producte oficial dels desenvolupadors nginx. Té una versió de pagament basada en . La idea principal és un alt nivell d'estabilitat, retrocompatibilitat constant, l'absència de mòduls estranys i l'augment de la velocitat declarada (en comparació amb el controlador oficial), aconseguit a causa del rebuig de Lua.
La versió gratuïta es redueix significativament, fins i tot en comparació amb el controlador oficial (a causa de la manca dels mateixos mòduls Lua). Al mateix temps, el de pagament té una funcionalitat addicional força àmplia: mètriques en temps real, validació JWT, controls de salut actius i molt més. Un avantatge important respecte a NGINX Ingress és el suport total per al trànsit TCP / UDP (i també a la versió de la comunitat!). Menys - funció de distribució del trànsit, que, tanmateix, "té la màxima prioritat per als desenvolupadors", però que necessita temps per implementar-se.
Kong Ingress
Pàgina Web:
Llicència: Apache 2.0
Producte desenvolupat per Kong Inc. en dues versions: comercial i gratuïta. Basat en nginx, que s'ha estès amb un gran nombre de mòduls Lua.
Inicialment, es va centrar en processar i encaminar les sol·licituds d'API, és a dir. com a API Gateway, però de moment s'ha convertit en un controlador d'entrada complet. Avantatges principals: molts mòduls addicionals (inclosos els de desenvolupadors de tercers) que són fàcils d'instal·lar i configurar i amb l'ajuda dels quals s'implementa una àmplia gamma de funcions addicionals. Tanmateix, les funcions integrades ja ofereixen moltes possibilitats. La configuració del treball es fa amb recursos CRD.
Una característica important del producte: treballar dins del mateix contorn (en lloc d'espais de nom creuats) és un tema controvertit: per a alguns semblarà un desavantatge (cal produir entitats per a cada contorn) i per a algú és una característica ( bоMajor nivell d'aïllament, com si un controlador està trencat, el problema es limita només al circuit).
Traefik
Pàgina Web:
Llicència: MIT
Un proxy que es va crear originalment per treballar amb l'encaminament de sol·licituds per a microserveis i el seu entorn dinàmic. Per tant, moltes funcions útils: actualització de la configuració sense reiniciar en absolut, suport per a un gran nombre de mètodes d'equilibri, interfície web, reenviament de mètriques, suport per a diversos protocols, API REST, versions canàries i molt més. Una altra característica agradable és la compatibilitat amb els certificats Let's Encrypt des de la caixa. El desavantatge és que per organitzar l'alta disponibilitat (HA), el controlador haurà d'instal·lar i connectar el seu propi emmagatzematge KV.
HAProxy
Pàgina Web:
Llicència: Apache 2.0
HAProxy fa temps que es coneix com a intermediari i equilibrador de trànsit. Com a part d'un clúster de Kubernetes, ofereix una actualització de configuració "suau" (sense pèrdua de trànsit), descobriment de serveis basat en DNS, configuració dinàmica mitjançant API. Pot ser atractiu personalitzar completament la plantilla de configuració substituint el CM, així com la possibilitat d'utilitzar-hi les funcions de la biblioteca Sprig. En general, el principal èmfasi de la solució està en l'alta velocitat, la seva optimització i eficiència en els recursos consumits. L'avantatge del controlador és el suport d'un nombre rècord de mètodes d'equilibri diferents.
Viatger
Pàgina Web:
Llicència: Apache 2.0
Basat en el controlador HAproxy, que es posiciona com una solució universal que admet una àmplia gamma de funcions en un gran nombre de proveïdors. S'ofereix una oportunitat per equilibrar el trànsit a L7 i L4, i l'equilibri del trànsit TCP L4 en conjunt es pot anomenar una de les característiques clau de la solució.
contorn
Pàgina Web:
Llicència: Apache 2.0
Aquesta solució no només es basa en Envoy: va ser desenvolupada per conjuntament amb els autors d'aquest popular proxy. Una característica important és la capacitat de separar el control dels recursos d'Ingress mitjançant recursos CRD d'IngressRoute. Per a les organitzacions amb molts equips de desenvolupament que utilitzen el mateix clúster, això ajuda a maximitzar la seguretat de treballar amb trànsit en bucles veïns i protegir-los dels errors en canviar els recursos d'entrada.
També ofereix un conjunt estès de mètodes d'equilibri (hi ha rèplica de sol·licituds, repetició automàtica, limitació de velocitat de sol·licitud i molt més), control detallat del flux de trànsit i errors. Potser per a algú serà un inconvenient important la manca de suport per a les sessions enganxades (tot i que el treball ).
Istio Ingress
Pàgina Web:
Llicència: Apache 2.0
Una solució de malla de servei integral que no només és un controlador d'entrada que gestiona el trànsit entrant des de l'exterior, sinó que també controla tot el trànsit dins del clúster. Sota el capó, Envoy s'utilitza com a proxy sidecar per a cada servei. En essència, es tracta d'una gran combinació que "pot fer qualsevol cosa", i la seva idea principal és la màxima manejabilitat, extensibilitat, seguretat i transparència. Amb ell, podeu ajustar l'encaminament del trànsit, l'autorització d'accés entre serveis, l'equilibri, la supervisió, els llançaments canaris i molt més. Llegeix més sobre Istio a la sèrie d'articles "».
Ambaixador
Pàgina Web:
Llicència: Apache 2.0
Una altra solució basada en Envoy. Té versions gratuïtes i comercials. Es posiciona com a "totalment natiu de Kubernetes", la qual cosa aporta els avantatges corresponents (integració estreta amb els mètodes i entitats del clúster K8s).
Taula de comparació
Per tant, la culminació de l'article és aquesta gran taula:
Es pot fer clic per a una visualització més propera i també està disponible en el format .
per resumir
L'objectiu d'aquest article és proporcionar una comprensió més completa (no obstant això, de cap manera exhaustiva!) de quina tria fer en el vostre cas particular. Com és habitual, cada controlador té els seus propis avantatges i desavantatges...
El clàssic Ingress de Kubernetes és bo per la seva disponibilitat i prova, amb funcions prou riques; en el cas general, hauria de ser "prou per als ulls". Tanmateix, si hi ha més requisits d'estabilitat, nivell de funcions i desenvolupament, hauríeu de prestar atenció a Ingress amb NGINX Plus i una subscripció de pagament. Kong té el conjunt de complements més ric (i, en conseqüència, les oportunitats que ofereixen), i a la versió de pagament encara n'hi ha més. Té àmplies oportunitats per treballar com a API Gateway, configuració dinàmica basada en recursos CRD, així com serveis bàsics de Kubernetes.
Amb els requisits més elevats per als mètodes d'equilibri i d'autorització, feu una ullada a Traefik i HAProxy. Es tracta de projectes de codi obert, provats al llarg dels anys, molt estables i en desenvolupament actiu. Contour fa un parell d'anys que està disponible, però encara sembla massa jove i només té funcions bàsiques afegides a la part superior d'Envoy. Si hi ha requisits per a la presència/incrustació de WAF davant de l'aplicació, hauríeu de prestar atenció al mateix Ingress de Kubernetes o HAProxy.
I els més rics quant a característiques són els productes construïts sobre Envoy, especialment Istio. Sembla ser una solució integral que "pot fer qualsevol cosa", la qual cosa, però, també significa un llindar d'entrada significativament més alt per a la configuració / llançament / administració que altres solucions.
Hem escollit i seguim utilitzant Ingress de Kubernetes com a controlador estàndard, que cobreix el 80-90% de les necessitats. És bastant fiable, fàcil de configurar i ampliar. En general, en absència de requisits específics, hauria d'adaptar-se a la majoria de clústers/aplicacions. Dels mateixos productes universals i relativament simples, es poden recomanar Traefik i HAProxy.
PS
Llegeix també al nostre blog:
- "Torna als microserveis amb Istio": , , ;
- «»;
- «».
Font: www.habr.com