Lanĉante Kubernetes-grupon por specifa aplikaĵo, vi devas kompreni, kion la aplikaĵo mem, la komerco kaj la programistoj prezentas al ĉi tiu rimedo. Kun ĉi tiuj informoj, vi povas komenci fari arkitekturan decidon kaj, precipe, elekti specifan Ingress-regilon, el kiu jam ekzistas granda nombro hodiaŭ. Por havi bazan ideon pri la disponeblaj elektoj sen devi trarigardi multajn artikolojn / dokumentaron ktp., ni preparis ĉi tiun superrigardon, inkluzive de la ĉefaj (produktadaj pretaj) Ingress-regiloj.
Ni esperas, ke ĝi helpos kolegojn elekti arkitekturan solvon - almenaŭ ĝi fariĝos deirpunkto por akiri pli detalajn informojn kaj praktikajn eksperimentojn. Antaŭe ni studis aliajn similajn materialojn en la reto kaj, strange, ne trovis eĉ unu pli-malpli kompletan, kaj plej grave - strukturitan - recenzon. Do ni plenigu tiun mankon!
Kriterioj
Principe, por fari komparon kaj akiri ajnan utilan rezulton, vi devas kompreni ne nur la temon, sed ankaŭ havi specifan liston de kriterioj, kiuj starigos la esplorvektoron. Sen ŝajnigi analizi ĉiujn eblajn kazojn de uzado de Ingress / Kubernetes, ni provis reliefigi la plej ĝeneralajn postulojn por regiloj - estu preta, ke ĉiukaze vi devos studi ĉiujn viajn specifaĵojn kaj detalojn aparte.
Sed mi komencos kun la trajtoj, kiuj fariĝis tiel konataj, ke ili estas efektivigitaj en ĉiuj solvoj kaj ne estas konsiderataj:
- dinamika malkovro de servoj (serva malkovro);
- SSL-fino;
- laborante kun websockets.
Nun por la komparpunktoj:
Subtenataj protokoloj
Unu el la fundamentaj elektkriterioj. Via programaro eble ne funkcias sur norma HTTP, aŭ ĝi povas postuli laboron sur pluraj protokoloj samtempe. Se via kazo estas ne-norma, nepre konsideru ĉi tiun faktoron por ke vi ne devu reagordi la areton poste. Por ĉiuj regiloj, la listo de subtenataj protokoloj varias.
programaro ĉe la kerno
Estas pluraj varioj de aplikoj, sur kiuj baziĝas la regilo. Popularaj estas nginx, traefik, haproxy, sendito. En la ĝenerala kazo, ĝi eble ne havas multe da efiko al kiel trafiko estas ricevita kaj transdonita, sed ĉiam utilas scii la eblajn nuancojn kaj trajtojn de tio, kio estas "sub la kapuĉo".
Trafikvojigo
Surbaze de kio eblas fari decidon pri la direkto de trafiko al aparta servo? Kutime ĉi tiuj estas gastiganto kaj vojo, sed estas pliaj eblecoj.
Nomspaco ene de areto
Nomspaco (nomspaco) - la kapablo logike dividi rimedojn en Kubernetes (ekzemple, sur scenejo, produktado, ktp.). Estas Ingress-regiloj, kiuj devas esti instalitaj aparte en ĉiu nomspaco (kaj tiam ĝi povas direkti trafikon nur al la balgoj de ĉi tiu spaco). Kaj estas tiuj (kaj ilia klara plimulto) kiuj funkcias tutmonde por la tuta areto - en ili trafiko estas direktita al iu ajn pod de la areto, sendepende de la nomspaco.
Specimenoj por kontraŭfluoj
Kiel trafiko estas direktita al sanaj okazoj de la aplikaĵo, servoj? Estas ebloj kun aktivaj kaj pasivaj kontroloj, reprovoj, ŝaltiloj (Por pliaj detaloj, vidu, ekzemple, ), kutimaj sankontroloj, ktp. Tre grava parametro se vi havas altajn postulojn por havebleco kaj ĝustatempa forigo de malsukcesaj servoj de ekvilibro.
Balancigoritmoj
Estas multaj ebloj: de tradicia al la ekzotikulo , same kiel individuaj trajtoj kiel .
Aŭtentigo
Kiajn rajtigajn skemojn la regilo subtenas? Basic, digest, oauth, external-auth - mi pensas, ke ĉi tiuj opcioj devus esti konataj. Ĉi tio estas grava kriterio se ekzistas multaj programistoj (kaj/aŭ nur privataj) bukloj alireblaj per Ingress.
Distribuo de trafiko
Ĉu la regilo subtenas tiajn ofte uzatajn trafikajn distribuajn mekanismojn kiel kanariajn landojn (kanarian), A/B-testadon, trafikan speguladon (spegulado/ombrigado)? Ĉi tio estas vere dolora temo por aplikoj, kiuj postulas precizan kaj precizan trafikan administradon por produktiva testado, sencimigi produktajn cimojn eksterrete (aŭ kun minimuma perdo), trafika analizo ktp.
Pagita abono
Ĉu ekzistas pagita opcio por la regilo, kun altnivela funkcieco kaj/aŭ teknika subteno?
Grafika uzantinterfaco (Web UI)
Ĉu ekzistas iu GUI por administri regilo-agordon? Ĉefe por "manĝemo" kaj/aŭ por tiuj, kiuj bezonas fari kelkajn ŝanĝojn al la agordo de Ingress'a, sed labori kun "krudaj" ŝablonoj estas maloportuna. Ĝi povas esti utila se programistoj volas fari kelkajn eksperimentojn kun trafiko sur la flugo.
JWT-validigo
La ĉeesto de enkonstruita validigo de JSON-retaj ĵetonoj por rajtigo kaj validumado de la uzanto al la fina aplikaĵo.
Ebloj por agorda personigo
Ŝablona etendebleco en la senco de havi mekanismojn, kiuj ebligas al vi aldoni viajn proprajn direktivojn, flagojn, ktp al normaj agordaj ŝablonoj.
Bazaj DDOS-protektaj mekanismoj
Simplaj tariflimaj algoritmoj aŭ pli kompleksaj trafikfiltrilaj opcioj bazitaj sur adresoj, blanklistoj, landoj ktp.
Petu spuron
La kapablo kontroli, spuri kaj sencimigi petojn de Eniroj al specifaj servoj/podoj, kaj ideale ankaŭ inter servoj/podoj.
WAF
subteno .
Regiloj
La listo de regiloj estis formita surbaze de и . Ni ekskludis kelkajn el ili de la revizio pro specifeco aŭ malalta tropezo (frua etapo de evoluo). La ceteraj estas diskutitaj sube. Ni komencu per ĝenerala priskribo de la solvoj kaj daŭrigu kun resuma tabelo.
Eniro de Kubernetes
retejo:
Licenco: Apache 2.0
Ĉi tiu estas la oficiala regilo por Kubernetes kaj estas disvolvita de la komunumo. Evidente de la nomo, ĝi baziĝas sur nginx kaj estas kompletigita per malsama aro de Lua-kromaĵoj uzataj por efektivigi pliajn funkciojn. Pro la populareco de nginx mem kaj minimumaj modifoj al ĝi kiam uzata kiel regilo, ĉi tiu opcio povas esti la plej facila kaj plej facila por agordi por la averaĝa inĝeniero (kun interreta sperto).
Eniro de NGINX Inc.
retejo:
Licenco: Apache 2.0
La oficiala produkto de la programistoj nginx. Havas pagitan version bazitan sur . La ĉefa ideo estas alta nivelo de stabileco, konstanta malantaŭa kongruo, la foresto de eksteraj moduloj kaj la deklarita pliigita rapideco (kompare kun la oficiala regilo), atingita pro la malakcepto de Lua.
La senpaga versio estas signife reduktita, inkluzive se komparite kun la oficiala regilo (pro la manko de la samaj Lua-moduloj). Samtempe, la pagita havas sufiĉe larĝan kroman funkcion: realtempaj metrikoj, JWT-validigo, aktivaj sankontroloj kaj pli. Grava avantaĝo super NGINX Ingress estas plena subteno por TCP / UDP-trafiko (kaj ankaŭ en la komunuma versio!). Minuso - trafika distribua funkcio, kiu tamen "havas la plej altan prioritaton por programistoj", sed bezonas tempon por efektivigi.
Kong Ingress
retejo:
Licenco: Apache 2.0
Produkto evoluigita fare de Kong Inc. en du versioj: komerca kaj senpaga. Bazita sur nginx, kiu estis etendita kun granda nombro da Lua-moduloj.
Komence, ĝi temis pri prilaborado kaj vojigo de API-petoj, t.e. kiel API-Enirejo, sed nuntempe ĝi fariĝis plenrajta Ingress-regilo. Ĉefaj avantaĝoj: multaj aldonaj moduloj (inkluzive de tiuj de triaj programistoj), kiuj estas facile instaleblaj kaj agordaj kaj kun la helpo de kiuj ampleksa gamo de aldonaj funkcioj estas efektivigita. Tamen, enkonstruitaj funkcioj jam ofertas multajn eblecojn. Laboragordo estas farita per CRD-resursoj.
Grava trajto de la produkto - labori ene de la sama konturo (anstataŭ krucnomspaciga) estas polemika temo: por iuj ĝi ŝajnos malavantaĝo (vi devas produkti entojn por ĉiu konturo), kaj por iu ĝi estas trajto ( bоPli granda izoliteco, kiel se unu regilo estas rompita, tiam la problemo estas limigita al la cirkvito sole).
Traefik
retejo:
Licenco: MIT
Prokurilo, kiu estis origine kreita por labori kun petovojigo por mikroservoj kaj ilia dinamika medio. Sekve, multaj utilaj funkcioj: ĝisdatigi la agordon sen rekomenci entute, subteno por granda nombro da ekvilibraj metodoj, retinterfaco, metriksendo, subteno por diversaj protokoloj, REST API, kanariaj eldonoj kaj multe pli. Alia bela funkcio estas subteno por Let's Encrypt atestiloj el la skatolo. La malavantaĝo estas, ke por organizi altan haveblecon (HA), la regilo devos instali kaj konekti sian propran KV-stokadon.
HAProxy
retejo:
Licenco: Apache 2.0
HAProxy estas delonge konata kiel prokurilo kaj trafikbalancilo. Kiel parto de Kubernetes-areo, ĝi ofertas "molan" agordan ĝisdatigon (sen perdo de trafiko), servo-malkovron bazitan sur DNS, dinamikan agordon uzante API. Povas esti alloga komplete personecigi la agordan ŝablonon anstataŭigante la CM, kaj ankaŭ la kapablon uzi Sprig-bibliotekfunkciojn en ĝi. Ĝenerale, la ĉefa emfazo de la solvo estas sur alta rapido, ĝia optimumigo kaj efikeco en konsumitaj rimedoj. La avantaĝo de la regilo estas la subteno de rekorda nombro da malsamaj ekvilibraj metodoj.
Voyager
retejo:
Licenco: Apache 2.0
Bazita sur HAproxy-regilo, kiu estas poziciigita kiel universala solvo, kiu subtenas larĝan gamon de funkcioj sur granda nombro da provizantoj. Ŝanco estas ofertita por ekvilibrigi trafikon sur L7 kaj L4, kaj ekvilibrigi TCP L4-trafikon entute povas esti nomita unu el la ĉefaj trajtoj de la solvo.
Konturo
retejo:
Licenco: Apache 2.0
Ĉi tiu solvo ne baziĝas nur sur Envoy: ĝi estis evoluigita de kune kun la aŭtoroj de ĉi tiu populara prokurilo. Grava trajto estas la kapablo apartigi kontrolon de Ingress-resursoj uzante IngressRoute CRD-resursojn. Por organizoj kun multaj evoluigaj teamoj uzantaj la saman areton, ĉi tio helpas maksimumigi la sekurecon labori kun trafiko en najbaraj bukloj kaj protekti ilin kontraŭ eraroj dum ŝanĝado de Ingress-resursoj.
Ĝi ankaŭ ofertas plilongigitan aron de ekvilibraj metodoj (estas spegulo de peto, aŭtomata ripeto, peto-limigo kaj multe pli), detala monitorado de trafikfluo kaj fiaskoj. Eble por iu estos grava malavantaĝo la manko de subteno por gluiĝemaj sesioj (kvankam la laboro ).
Istio Eniro
retejo:
Licenco: Apache 2.0
Ampleksa serva maŝsolvo, kiu ne nur estas Ingress-regilo, kiu administras envenantan trafikon de ekstere, sed ankaŭ kontrolas la tutan trafikon ene de la areto. Sub la kapuĉo, Envoy estas utiligita kiel kromĉara prokurilo por ĉiu servo. Esence, ĉi tio estas granda kombinaĵo, kiu "povas fari ion ajn", kaj ĝia ĉefa ideo estas maksimuma regebla, etendebleco, sekureco kaj travidebleco. Per ĝi, vi povas agordi trafikan vojigon, aliri rajtigon inter servoj, ekvilibron, monitoradon, kanariajn eldonojn kaj multe pli. Legu pli pri Istio en la serio de artikoloj "".
Ambasadoro
retejo:
Licenco: Apache 2.0
Alia solvo bazita sur Envoy. Ĝi havas senpagajn kaj komercajn versiojn. Ĝi estas poziciigita kiel "plene indiĝena al Kubernetes", kio alportas la ekvivalentajn avantaĝojn (streĉa integriĝo kun la metodoj kaj unuoj de la K8s-areto).
Komparo tablo
Do, la kulmino de la artikolo estas ĉi tiu grandega tablo:
Ĝi estas klakebla por pli proksima vido, kaj ankaŭ haveblas en la formato .
Ni resumu
La celo de ĉi tiu artikolo estas doni pli kompletan komprenon (tamen, tute ne ĝisfunda!) pri kia elekto fari en via aparta kazo. Kiel kutime, ĉiu regilo havas siajn proprajn avantaĝojn kaj malavantaĝojn...
La klasika Ingress de Kubernetes estas bona por sia havebleco kaj pruvo, sufiĉe riĉaj trajtoj - en la ĝenerala kazo, ĝi devus esti "sufiĉa por la okuloj". Tamen, se estas pliigitaj postuloj por stabileco, la nivelo de funkcioj kaj evoluo, vi devus atenti Ingress kun NGINX Plus kaj pagita abono. Kong havas la plej riĉan aron da kromprogramoj (kaj, sekve, la ŝancojn, kiujn ili provizas), kaj en la pagita versio estas eĉ pli da ili. Ĝi havas ampleksajn ŝancojn labori kiel API Gateway, dinamika agordo bazita sur CRD-resursoj, same kiel bazaj Kubernetes-servoj.
Kun pliigitaj postuloj por ekvilibraj kaj rajtigaj metodoj, rigardu Traefik kaj HAProxy. Ĉi tiuj estas Open Source projektoj, pruvitaj tra la jaroj, tre stabilaj kaj aktive evoluantaj. Konturo estas ekstere de kelkaj jaroj, sed ĝi ankoraŭ aspektas tro juna kaj havas nur bazajn funkciojn aldonitajn sur Envoy. Se estas postuloj por la ĉeesto / enkonstruado de WAF antaŭ la aplikaĵo, vi devas atenti la saman Eniron de Kubernetes aŭ HAProxy.
Kaj la plej riĉaj laŭ funkcioj estas produktoj konstruitaj sur Envoy, precipe Istio. Ŝajnas esti ampleksa solvo, kiu "povas fari ion ajn", kio tamen signifas ankaŭ signife pli altan enirsojlon por agordo / lanĉo / administrado ol aliaj solvoj.
Ni elektis kaj ankoraŭ uzas Ingress de Kubernetes kiel norma regilo, kiu kovras 80-90% de bezonoj. Ĝi estas sufiĉe fidinda, facile agordi kaj vastigi. Ĝenerale, sen specifaj postuloj, ĝi devus konveni al la plej multaj aretoj / aplikoj. El la samaj universalaj kaj relative simplaj produktoj, Traefik kaj HAProxy povas esti rekomenditaj.
PS
Legu ankaŭ en nia blogo:
- "Reen al mikroservoj kun Istio": , , ;
- «»;
- «".
fonto: www.habr.com