Kur lëshoni një grup Kubernetes për një aplikacion specifik, duhet të kuptoni se çfarë paraqesin vetë aplikacioni, biznesi dhe zhvilluesit për këtë burim. Me këtë informacion, mund të filloni të merrni një vendim arkitektonik dhe, në veçanti, të zgjidhni një kontrollues specifik Ingress, i cili tashmë ka një numër të madh sot. Për të marrë një ide bazë të opsioneve të disponueshme pa pasur nevojë të kalojmë nëpër shumë artikuj / dokumentacion, etj., Ne kemi përgatitur këtë përmbledhje, duke përfshirë kontrollorët kryesorë (gati për prodhimin) Ingress.
Shpresojmë që do t'i ndihmojë kolegët në zgjedhjen e një zgjidhjeje arkitekturore - të paktën do të bëhet një pikënisje për marrjen e informacionit më të detajuar dhe eksperimenteve praktike. Më parë, ne studiuam materiale të tjera të ngjashme në rrjet dhe, çuditërisht, nuk gjetëm një përmbledhje të vetme pak a shumë të plotë, dhe më e rëndësishmja - e strukturuar. Pra, le ta mbushim atë boshllëk!
kriteret
Në parim, për të bërë një krahasim dhe për të marrë ndonjë rezultat të dobishëm, duhet të kuptoni jo vetëm fushën e lëndës, por gjithashtu të keni një listë specifike të kritereve që do të përcaktojnë vektorin e kërkimit. Pa pretenduar të analizojmë të gjitha rastet e mundshme të përdorimit të Ingress / Kubernetes, ne u përpoqëm të nxjerrim në pah kërkesat më të përgjithshme për kontrollorët - jini të përgatitur që në çdo rast do t'ju duhet të studioni veçmas të gjitha specifikat dhe veçoritë tuaja.
Por unë do të filloj me karakteristikat që janë bërë aq të njohura saqë ato zbatohen në të gjitha zgjidhjet dhe nuk merren parasysh:
- zbulimi dinamik i shërbimeve (zbulimi i shërbimit);
- Përfundimi SSL;
- duke punuar me fole në internet.
Tani për pikat e krahasimit:
Protokollet e mbështetura
Një nga kriteret themelore të përzgjedhjes. Softueri juaj mund të mos funksionojë në HTTP standarde ose mund të kërkojë punë në protokolle të shumta njëherësh. Nëse rasti juaj është jo standard, sigurohuni që ta merrni parasysh këtë faktor në mënyrë që të mos keni nevojë të rikonfiguroni grupin më vonë. Për të gjithë kontrollorët, lista e protokolleve të mbështetur ndryshon.
softueri në thelb
Ekzistojnë disa variacione aplikacionesh në të cilat bazohet kontrolluesi. Të njohurat janë nginx, traefik, haproxy, i dërguar. Në rastin e përgjithshëm, mund të mos ketë shumë ndikim në mënyrën se si merret dhe transmetohet trafiku, por është gjithmonë e dobishme të njihni nuancat dhe veçoritë e mundshme të asaj që është "nën kapuç".
Drejtimi i trafikut
Në bazë të asaj që është e mundur të merret një vendim për drejtimin e trafikut në një shërbim të caktuar? Zakonisht këto janë host dhe rrugë, por ka mundësi shtesë.
Hapësira e emrave brenda një grupi
Hapësira e emrave (hapësira e emrave) - aftësia për të ndarë logjikisht burimet në Kubernetes (për shembull, në skenë, prodhim, etj.). Ka kontrollues Ingress që duhet të instalohen veçmas në çdo hapësirë emri (dhe më pas mund të drejtojë trafikun vetëm te bishtajat e kësaj hapësire). Dhe ka nga ata (dhe shumica e tyre e qartë) që funksionojnë globalisht për të gjithë grupimin - në to trafiku drejtohet në çdo grup të grupit, pavarësisht nga hapësira e emrave.
Mostrat për rrjedhat e sipërme
Si drejtohet trafiku në raste të shëndetshme të aplikacionit, shërbimeve? Ka opsione me kontrolle aktive dhe pasive, riprovime, ndërprerës (Për më shumë detaje, shihni, për shembull, ), kontrolle shëndetësore me porosi, etj. Një parametër shumë i rëndësishëm nëse keni kërkesa të larta për disponueshmërinë dhe heqjen në kohë të shërbimeve të dështuara nga balancimi.
Algoritmet e balancimit
Ka shumë opsione: nga tradicionale tek ekzotiku , si dhe veçoritë individuale si .
vërtetim
Çfarë skemash autorizimi mbështet kontrolluesi? Basic, digest, oauth, external-auth - Unë mendoj se këto opsione duhet të jenë të njohura. Ky është një kriter i rëndësishëm nëse ka shumë unaza zhvilluesish (dhe/ose thjesht private) që arrihen përmes Ingress.
Shpërndarja e trafikut
A i mbështet kontrolluesi mekanizma të tillë të shpërndarjes së trafikut të përdorur zakonisht si lansimi i kanarinave (kanarinat), testimi A/B, pasqyrimi i trafikut (pasqyrimi / hijezimi)? Kjo është një temë vërtet e dhimbshme për aplikacionet që kërkojnë menaxhim të saktë dhe të saktë të trafikut për testime produktive, korrigjimin e gabimeve të produktit jashtë linje (ose me humbje minimale), analiza të trafikut, etj.
Abonim me pagesë
A ka një opsion me pagesë për kontrolluesin, me funksionalitet të avancuar dhe/ose mbështetje teknike?
Ndërfaqja grafike e përdoruesit (Ueb UI)
A ka ndonjë GUI për të menaxhuar konfigurimin e kontrolluesit? Kryesisht për "përshtatshmëri" dhe/ose për ata që duhet të bëjnë disa ndryshime në konfigurimin e Ingress'a, por puna me shabllone "të papërpunuara" është e papërshtatshme. Mund të jetë e dobishme nëse zhvilluesit duan të kryejnë disa eksperimente me trafikun në fluturim.
Vleresimi JWT
Prania e vlefshmërisë së integruar të argumenteve në internet JSON për autorizimin dhe vlefshmërinë e përdoruesit deri në aplikacionin përfundimtar.
Mundësitë për personalizimin e konfigurimit
Zgjerimi i shabllonit në kuptimin e të paturit mekanizma që ju lejojnë të shtoni direktivat tuaja, flamujt, etj. në shabllonet standarde të konfigurimit.
Mekanizmat bazë të mbrojtjes DDOS
Algoritme të thjeshta të kufirit të normës ose opsione më komplekse të filtrimit të trafikut bazuar në adresat, listat e bardha, vendet, etj.
Kërkoni gjurmë
Mundësia për të monitoruar, gjurmuar dhe korrigjuar kërkesat nga Ingresses në shërbime / pods specifike, dhe në mënyrë ideale edhe midis shërbimeve / pods.
WAF
Mbështetje .
Kontrollorët
Lista e kontrollorëve është formuar në bazë të и . Ne i përjashtuam disa prej tyre nga rishikimi për shkak të specifikës ose prevalencës së ulët (faza e hershme e zhvillimit). Pjesa tjetër diskutohet më poshtë. Le të fillojmë me një përshkrim të përgjithshëm të zgjidhjeve dhe të vazhdojmë me një tabelë përmbledhëse.
Hyrja nga Kubernetes
Website:
Licenca: Apache 2.0
Ky është kontrolluesi zyrtar për Kubernetes dhe po zhvillohet nga komuniteti. Natyrisht nga emri, ai bazohet në nginx dhe plotësohet nga një grup i ndryshëm shtojcash Lua të përdorura për të zbatuar veçori shtesë. Për shkak të popullaritetit të vetë nginx dhe modifikimeve minimale të tij kur përdoret si kontrollues, ky opsion mund të jetë më i lehtë dhe më i kuptueshëm për t'u konfiguruar nga inxhinieri mesatar (me përvojë në internet).
Ingress nga NGINX Inc.
Website:
Licenca: Apache 2.0
Produkti zyrtar i zhvilluesve nginx. Ka një version të paguar bazuar në . Ideja kryesore është një nivel i lartë stabiliteti, pajtueshmëri konstante prapa, mungesa e ndonjë moduli të jashtëm dhe shpejtësia e shtuar e deklaruar (krahasuar me kontrolluesin zyrtar), e arritur për shkak të refuzimit të Lua.
Versioni falas është reduktuar ndjeshëm, përfshirë edhe kur krahasohet me kontrolluesin zyrtar (për shkak të mungesës së të njëjtave module Lua). Në të njëjtën kohë, ai me pagesë ka një funksionalitet shtesë mjaft të gjerë: metrikë në kohë reale, vërtetim JWT, kontrolle aktive shëndetësore dhe më shumë. Një avantazh i rëndësishëm ndaj NGINX Ingress është mbështetja e plotë për trafikun TCP / UDP (dhe në versionin e komunitetit gjithashtu!). Minus - funksioni i shpërndarjes së trafikut, i cili, megjithatë, "ka përparësinë më të lartë për zhvilluesit", por kërkon kohë për t'u zbatuar.
Kong Ingress
Website:
Licenca: Apache 2.0
Produkt i zhvilluar nga Kong Inc. në dy versione: komerciale dhe falas. Bazuar në nginx, i cili është zgjeruar me një numër të madh modulesh Lua.
Fillimisht, ai u fokusua në përpunimin dhe drejtimin e kërkesave API, d.m.th. si një portë API, por për momentin është bërë një kontrollues i plotë i Ingress. Përparësitë kryesore: shumë module shtesë (përfshirë ato nga zhvilluesit e palëve të treta) që instalohen dhe konfigurohen lehtë dhe me ndihmën e të cilave zbatohet një gamë e gjerë funksionesh shtesë. Megjithatë, funksionet e integruara tashmë ofrojnë shumë mundësi. Konfigurimi i punës bëhet duke përdorur burimet CRD.
Një tipar i rëndësishëm i produktit - të punosh brenda të njëjtit kontur (në vend të hapësirës ndër-emërore) është një temë e diskutueshme: për disa do të duket si një disavantazh (duhet të prodhosh entitete për çdo kontur), dhe për dikë është një veçori ( bоNiveli më i madh i izolimit, si nëse një kontrollues është i prishur, atëherë problemi kufizohet vetëm në qark).
Traefik
Website:
Licenca: MIT
Një përfaqësues që u krijua fillimisht për të punuar me drejtimin e kërkesave për mikroshërbimet dhe mjedisin e tyre dinamik. Prandaj, shumë veçori të dobishme: përditësimi i konfigurimit pa rindezje fare, mbështetje për një numër të madh metodash balancimi, ndërfaqe në internet, përcjellje metrike, mbështetje për protokolle të ndryshme, API REST, lëshime kanarëshe dhe shumë më tepër. Një veçori tjetër e këndshme është mbështetja për certifikatat Let's Encrypt jashtë kutisë. Disavantazhi është se për të organizuar disponueshmërinë e lartë (HA), kontrolluesi do të duhet të instalojë dhe lidhë ruajtjen e vet KV.
HAProxy
Website:
Licenca: Apache 2.0
HAProxy ka qenë prej kohësh i njohur si një përfaqësues dhe balancues i trafikut. Si pjesë e një grupi Kubernetes, ai ofron një përditësim "të butë" të konfigurimit (pa humbje të trafikut), zbulim shërbimi bazuar në DNS, konfigurim dinamik duke përdorur API. Mund të jetë tërheqëse të personalizoni plotësisht shabllonin e konfigurimit duke zëvendësuar CM, si dhe aftësinë për të përdorur funksionet e bibliotekës Sprig në të. Në përgjithësi, theksi kryesor i zgjidhjes është në shpejtësinë e lartë, optimizimin dhe efikasitetin e saj në burimet e konsumuara. Avantazhi i kontrolluesit është mbështetja e një numri rekord të metodave të ndryshme të balancimit.
Eksplorator
Website:
Licenca: Apache 2.0
Bazuar në kontrolluesin HAproxy, i cili pozicionohet si një zgjidhje universale që mbështet një gamë të gjerë funksionesh në një numër të madh ofruesish. Ofrohet një mundësi për balancimin e trafikut në L7 dhe L4, dhe balancimi i trafikut TCP L4 në tërësi mund të quhet një nga tiparet kryesore të zgjidhjes.
kontur
Website:
Licenca: Apache 2.0
Kjo zgjidhje nuk bazohet vetëm në Envoy: ajo u zhvillua nga bashkërisht me autorët e kësaj prokure popullore. Një veçori e rëndësishme është aftësia për të ndarë kontrollin e burimeve Ingress duke përdorur burimet e IngressRoute CRD. Për organizatat me shumë ekipe zhvillimi që përdorin të njëjtin grup, kjo ndihmon për të maksimizuar sigurinë e punës me trafikun në unazat fqinje dhe për t'i mbrojtur ata nga gabimet gjatë ndryshimit të burimeve të Ingress.
Ai gjithashtu ofron një grup të zgjeruar metodash balancimi (ekziston pasqyrimi i kërkesës, përsëritja automatike, kufizimi i shkallës së kërkesës dhe shumë më tepër), monitorim i detajuar i rrjedhës së trafikut dhe dështimeve. Ndoshta për dikë do të jetë një pengesë e rëndësishme mungesa e mbështetjes për seancat ngjitëse (megjithëse puna ).
Istio Ingress
Website:
Licenca: Apache 2.0
Një zgjidhje gjithëpërfshirëse rrjetë shërbimi që nuk është vetëm një kontrollues Ingress që menaxhon trafikun në hyrje nga jashtë, por gjithashtu kontrollon të gjithë trafikun brenda grupit. Nën kapuçin, Envoy përdoret si përfaqësues për çdo shërbim. Në thelb, ky është një kombinim i madh që “mund të bëjë gjithçka”, dhe ideja kryesore e tij është menaxhueshmëria maksimale, shtrirja, siguria dhe transparenca. Me të, ju mund të rregulloni imtësisht drejtimin e trafikut, të aksesoni autorizimin ndërmjet shërbimeve, balancimin, monitorimin, lëshimet e kanarinave dhe shumë më tepër. Lexoni më shumë për Istio në serinë e artikujve "'.
Ambasador
Website:
Licenca: Apache 2.0
Një zgjidhje tjetër e bazuar në të Dërguarin. Ka versione falas dhe komerciale. Ai pozicionohet si "plotësisht vendas në Kubernetes", i cili sjell avantazhet përkatëse (integrim i ngushtë me metodat dhe entitetet e grupit K8s).
tabela e krahasimit
Pra, kulmi i artikullit është kjo tabelë e madhe:
Mund të klikohet për një pamje më të afërt dhe është gjithashtu i disponueshëm në format .
për të përmbledhur
Qëllimi i këtij artikulli është të sigurojë një kuptim më të plotë (megjithatë, aspak shterues!) se çfarë zgjedhje duhet të bëni në rastin tuaj të veçantë. Si zakonisht, çdo kontrollues ka avantazhet dhe disavantazhet e veta…
Ingress klasik nga Kubernetes është i mirë për disponueshmërinë dhe provën e tij, veçori mjaft të pasura - në rastin e përgjithshëm, duhet të jetë "mjaftueshëm për sytë". Sidoqoftë, nëse ka kërkesa të shtuara për stabilitetin, nivelin e veçorive dhe zhvillimin, duhet t'i kushtoni vëmendje Ingress me NGINX Plus dhe një abonim me pagesë. Kong ka grupin më të pasur të shtojcave (dhe, në përputhje me rrethanat, mundësitë që ato ofrojnë), dhe në versionin e paguar ka edhe më shumë prej tyre. Ka mundësi të bollshme për të punuar si një API Gateway, konfigurim dinamik i bazuar në burimet CRD, si dhe shërbimet bazë të Kubernetes.
Me kërkesat e shtuara për metodat e balancimit dhe autorizimit, hidhini një sy Traefik dhe HAProxy. Këto janë projekte me kod të hapur, të provuara ndër vite, shumë të qëndrueshme dhe në zhvillim aktiv. Contour ka dalë prej disa vitesh, por ende duket shumë i ri dhe ka vetëm veçori bazë të shtuara në krye të Envoy. Nëse ka kërkesa për praninë / futjen e WAF përpara aplikacionit, duhet t'i kushtoni vëmendje të njëjtit Ingress nga Kubernetes ose HAProxy.
Dhe më të pasurit për nga karakteristikat janë produktet e ndërtuara në krye të Envoy, veçanërisht Istio. Duket se është një zgjidhje gjithëpërfshirëse që "mund të bëjë gjithçka", e cila, megjithatë, nënkupton gjithashtu një prag hyrje dukshëm më të lartë për konfigurim / nisje / administrim sesa zgjidhjet e tjera.
Ne kemi zgjedhur dhe përdorim ende Ingress nga Kubernetes si një kontrollues standard, i cili mbulon 80-90% të nevojave. Është mjaft i besueshëm, i lehtë për t'u konfiguruar dhe zgjeruar. Në përgjithësi, në mungesë të kërkesave specifike, ai duhet t'i përshtatet shumicës së grupimeve / aplikacioneve. Nga të njëjtat produkte universale dhe relativisht të thjeshta, mund të rekomandohen Traefik dhe HAProxy.
PS
Lexoni edhe në blogun tonë:
- "Kthehu te mikroshërbimet me Istio": , , ;
- «"?
- «'.
Burimi: www.habr.com