Kur filloni një klaster Kubernetes për një aplikacion specifik, duhet të kuptoni cfarë kërkesash ka ky burim, aplikacioni vetë, biznesi dhe zhvilluesit. Me këtë informacion në dorë, mund të filloni të merrni vendime për arkitekturën dhe, në veçanti, të zgjidhni një Ingress-controller specifik, të cilët tani janë në numër të madh. Për të krijuar një pasqyrë bazë për opsionet e disponueshme pa pasur nevojë të studioni shumë artikuj/dokumentacion etj., ne përgatitëm këtë përmbledhje, duke përfshirë Ingress-controllerët kryesorë (të gatshëm për prodhim).
Shpresojmë se do të ndihmojë kolegët në zgjedhjen e vendimeve për arkitekturën — të paktën, do të shërbejë si një pikë fillestare për të marrë më shumë informacion dhe eksperimente praktike. Fillimisht, kemi studiuar materiale të tjera të ngjashme online dhe, çuditërisht, nuk gjetëm asnjë përmbledhje më të plotë, dhe më kryesorja — të strukturuar. Pra, le të mbushim këtë boshllëk!
Kriteret
Për të bërë krahasimin dhe të merrni ndonjë rezultat të dobishëm, duhet të kuptoni jo vetëm fushën përkatëse, por gjithashtu të keni një listë të veçantë kriteresh që do të ndihmojnë në drejtpërdrejtimin 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 kërkesat më të zakonshme për kontrolluesit — bëni mirë të jeni të gatshëm se gjithë specifikat dhe detajet e veçanta, në çdo rast, do t'ju duhet t'i studioni veç e veç.
Por, do të filloj me karakteristikat që janë bërë aq të zakonshme që janë të realizuara në të gjitha zgjidhjet dhe nuk shqyrtohen:
- zbulimi dinamik i shërbimeve (service discovery);
- terminimi i SSL;
- ndryshimi me websocket-et.
Tani — për pikat e krahasimit:
Protokollet e mbështetura
Një nga kriteret themelore për zgjedhjen. Software-i juaj mund të mos funksionojë sipas HTTP standard ose të kërkojë të punojë me shumë protokolle njëherësh. Nëse rasti juaj është jo standard, sigurohuni që të merrni parasysh këtë faktor, për të mos pasur nevojë ta rregulloni pastaj klasterin. Lista e protokolleve të mbështetur ndryshon te të gjithë kontrolluesit.
Software temel
Ka janë disa variante aplikacionesh në të cilat bazohet kontrolluesi. Popullore janë nginx, traefik, haproxy, envoy. Në përgjithësi, ndoshta nuk ka shumë ndikim në mënyrën se si pranohet dhe transmetohet trafiku, megjithatë gjithmonë është e dobishme të dihet për nuancat dhe veçoritë e asaj që "është nën kapak".
Routimi i trafikut
Në bazë të çfarë mund të merret një vendim për drejtimin e trafikut në një shërbim të caktuar? Zakonisht është host dhe path, por ka edhe mundësi të tjera shtesë.
Hapësira emri brenda klustrit
Hapësira e emrit (namespace) është mundësia për të ndarë burimet në Kubernetes në mënyrë logjike (p.sh. në skenë, prodhim etj.). Ka Ingress-kontrollues që duhet të instalohen veçmas në çdo namespace (dhe atëherë ai mund të drejtojë trafikun në pod'ët e kësaj hapësire). Ndërsa ka të tillë (dhe janë një shumicë e qartë) që punojnë globalisht për të gjithë klustrin — në to, trafiku drejtohet në çdo pod të klustrit, pavarësisht nga hapësira emri. të Në pod’ët e kësaj hapësire). Ndërkaq, ka të tjerë (dhe janë shumica e qartë) që punojnë globalisht për të gjithë klustrin — në to, trafiku drejtohet në çdo pod të klustrit, pavarësisht nga hapësira emri.
Kontrollimet për upstream'ët
Cila është mënyra për të drejtuar trafikun në instanca të shëndetshme të aplikacionit, shërbimeve? Ekzistojnë mundësi me kontrollime aktive dhe pasive, përpjekje të përsëritura (retries), circuit breakers (më shumë rreth tyre shih, për shembull, në ), realizime të veta të kontrollimeve të gjendjes (custom health checks) etj. Një parameter shumë i rëndësishëm, nëse keni kërkesa të larta për disponueshmëri dhe krijimin e shpejtë jashtë balansimit të shërbimeve që kanë dështuar.
Algoritmet e balansimit
Këtu ka shumë variante: nga ato tradicionale deri te ato ekzotike si , si dhe mundësi të veçanta si .
Autentikimi
Çfarë skemash autorizimi mbështet kontrolluesi? Basic, digest, oauth, external-auth — mendoj se këto mundësi duhet të jenë të njohura. Ky është një kriter i rëndësishëm, nëse përdoren shumë skema për zhvilluesit (dhe/ose thjesht të mbyllura), për të cilat aksesi realizohet përmes Ingress.
Shpërndarja e trafikut
A mbështet kontrolluesi mekanizmat e përdorur shpesh për shpërndarjen e trafikut, si rrotullimet kanarinë (canary), testimi A/B, ndriçimi i trafikut (mirroring/shadowing)? Kjo është me të vërtetë një temë delikate për aplikacionet që kërkojnë menaxhim të kujdesshëm dhe të saktë të trafikut për testime produktive, zhgjidhjen e gabimeve të produkteve jo në prodhim (ose me humbje minimale), analizën e trafikut etj.
Abonimi i paguar
A ka ndonjë variant të paguar për kontrolluesin, me funksionalitete të zgjeruara dhe/a ose mbështetje teknike?
Ndërfaqja grafike (Web UI)
A ekziston ndonjë ndërfaqe grafike për menaxhimin e konfigurimit të kontrolluesit? Kryesisht për "lehtësinë" dhe/a ose për ata që nevojiten për të bërë ndonjë ndryshim në konfigurimin e Ingress, por është e padrejtë të punosh me "modelët e papërpunuar". Mund të jetë e dobishme në rast se zhvilluesit duan të eksperimentojnë me trafikun në fluturim.
Validimi JWT
Prania e kontrollit të integruar të JSON web-ndihmës për autorizimin dhe validimin e përdoruesve në aplikacionin e fundit.
Mundësi për personalizimin e konfigurimit
Zgjerueshmëria e modeleve në kuptimin e pranisë së mekanizmave që lejojnë që të shtohen në modelet standarde të konfigurimit udhëzime, flagje dhe të tjera.
Mekanizmat bazë të mbrojtjes nga DDOS
Algoritme të thjeshta të kufizimit të normave ose variante më të komplikuara të filtrimit të trafikut në bazë të adresave, listeve të bardha, vendeve dhe të tjera.
Ndjekja e kërkesave
Mundësitë e vëzhgimit, ndjekjes dhe arsyetimit të kërkesave nga Ingress në shërbime/pod të caktuara, dhe idealisht — edhe midis shërbimeve/pod-ve.
WAF
Поддержка .
Kontrollerët Ingress
Lista e kontrollerëve është formuar mbi bazën e и . Disa prej tyre i kemi përjashtuar nga shqyrtimi për shkak të specifikave ose përhapjes së ulët (fazës së hershme të zhvillimit). Të tjerët janë shqyrtuar më poshtë. Le të fillojmë me një përshkrim të përgjithshëm të zgjidhjeve dhe të vazhdojmë me një tabelë përmbledhëse.
Ingress nga Kubernetes
Faqja:
Licenca: Apache 2.0
Ky është kontrolluesi zyrtar për Kubernetes, i cili zhvillohet nga komuniteti. Siç tregohet nga emri, ai është i bazuar në nginx dhe është plotësuar me një sërë plug-in-esh Lua, të përdorura për realizimin e mundësive shtesë. Falë popullaritetit të vetë nginx dhe modifikimeve minimale mbi të gjatë përdorimit si kontrollues, kjo mund të jetë opsioni më i thjeshtë dhe më i qartë për konfigurimin nga një inxhinier mesatar (me përvojë në web).
Ingress nga NGINX Inc
Faqja:
Licenca: Apache 2.0
Produkti zyrtar i zhvilluesve të nginx. Ka një version të paguar, të bazuar në . Ideja kryesore është një nivel i lartë stabiliteti, përputhje e vazhdueshme, mungesa e moduleve të jashtme dhe shpejtësia e deklaruar e rritur (krahasuar me kontrolluesin zyrtar), arritur falë braktisjes së Lua.
Versioni falas është në masë të madhe i kufizuar, përfshirë madje edhe në krahasim me kontrolluesin zyrtar (për shkak të mungesës së moduleve të njëjtë Lua). Ndërsa versioni me pagesë ka një funksionalitet shtesë të gjerë: metrika në kohë reale, validimi JWT, kontroll aktiv të shëndetit dhe më shumë. Njëavantazh i rëndësishëm në krahasim me NGINX Ingress — mbështetje e plotë për trafik TCP/UDP (edhe në versionin community!). Disavantazhi — e funksioneve për shpërndarjen e trafik, që, megjithatë, "ka prioritetin maksimal për zhvilluesit", por kërkon kohë për të realizuar.
Kong Ingress
Faqja:
Licenca: Apache 2.0
Produkti, i zhvilluar nga kompanija Kong Inc. në dy variante: komercial dhe falas. Bazohet në nginx, mundësitë e të cilit janë zgjeruar me shumë module në Lua.
Fillimisht ishte orientuar në përpunimin dhe përshkrimin e kërkesave API, pra si një API Gateway, por tani është bërë një kontrollues Ingress i plotë. Avantazhet kryesore: shumë module shtesë (përfshirë edhe nga zhvillues të tretë), të cilat janë të lehta për t'u instaluar dhe konfiguruar dhe me anë të të cilave ofrohen një gamë e gjerë mundësish shtesë. Megjithatë, funksionet e ndërtuara ofrojnë tashmë shumë mundësi. Konfigurohet puna përmes burimeve CRD.
Një tipar i rëndësishëm i produktit — puna brenda një konturi (në vend të cross-namespaced) është një temë e diskutueshme: dikujt do t'i duket si një mangësi (duhet të krijosh entitete për çdo kontur), ndersa për dikë tjetër — një tipar (boniveli më i lartë i izolimit, pasi, nëse dështon një kontrollues, problemi është i kufizuar në një kontur të vetëm).
Traefik
Faqja:
Licenca: MIT
Proksi, i cili është krijuar fillimisht për të punuar me drejtpeshimin e kërkesave për mikroshërbimet dhe ambientin e tyre dinamik. Prandaj, ofron shumë mundësi të dobishme: përditësimi i konfiguracionit pa nevojën e ritrillimit, mbështetje për një numër të madh metodash të balancimit, ndërfaqe web, kalimi i metrikeve, mbështetje për protokolle të ndryshme, REST API, lëshime kanarinë dhe shumë të tjera. Një karakteristikë e këndshme është gjithashtu mbështetja për certifikatat Let’s Encrypt direkt nga kutia. Disavantazhi është se për të organizuar disponueshmërinë e lartë (HA), kontrolluesi do të kërkojë të instalojë dhe lidhet me depovitin e tij KV.
HAProxy
Faqja:
Licenca: Apache 2.0
HAProxy është njohur prej kohësh si proksi dhe balancues trafiku. Në kuadër të klasterit Kubernetes, ofron një përditësim të «butë» të konfiguracionit (pa humbjen e trafikut), zbulim shërbimi bazuar në DNS, konfigurim dinamik përmes API. Një faktor tërheqës mund të jetë mundësia e personalizimit të plotë të shabllonit të konfiguratave duke zëvendësuar CM-në, si dhe mundësitë për të përdorur funksionet e bibliotekës Sprig. Në tërësi, theksi kryesor i zgjidhjes është në shpejtësinë e lartë të operimit, optimizimin e saj dhe efikasitetin në përdorimin e burimeve. Avantazhi i kontrolluesit është mbështetja për një numër rekord metodash të ndryshme të balancimit.
Voyager
Faqja:
Licenca: Apache 2.0
Një kontrollues i bazuar në HAproxy, i cili pozicionohet si një zgjidhje universale që mbështet mundësi të gjera në një numër të madh ofruesish. Ofron mundësinë për balancimin e trafikut në L7 dhe L4, ndërsa balancimi i trafikut TCP L4 mund të përmendet si një nga karakteristikat kryesore të zgjidhjes.
Contour
Faqja:
Licenca: Apache 2.0
Ky zgjidhje është zhvilluar jo vetëm lehtë nga Envoy: bashkë me autorët e këtij proksi të njohur. Një veçori e rëndësishme është mundësia e ndarjes së menaxhimit të burimeve Ingress përmes burimeve CRD IngressRoute. Për organizatat me shumë ekipe zhvillimi që përdorin një klaster të vetëm, kjo ndihmon për të siguruar maksimalisht punën me trafikun në kontura fqinj dhe për t'i mbrojtur ata nga gabimet gjatë ndryshimit të burimeve Ingress.
Po ofertë gjithashtu një set të zgjeruar metodash të balancimit (janë të pranishme pasqyrimi i kërkesave, ripërsëritjet automatikisht, kufizimi i shkallës së kërkesave dhe shumë të tjera), monitorim të detajuar të trafikut dhe dështimeve. Mund të jetë një disavantazh i rëndësishëm për disa mungesa e mbështetjes për seancat e ngjitura (edhe pse janë të angazhuar) ).
Istio Ingress
Faqja:
Licenca: Apache 2.0
Një zgjidhje e plotë e service mesh, e cila nuk është vetëm një kontrollues Ingress që menaxhon trafikun e pranuar nga jashtë, por gjithashtu kontrollon të gjithë trafikun brenda klasterit. "Nën kapak", si proxy anësor për çdo shërbim, përdoret Envoy. Në thelb, kjo është një makinë e madhe që "mund gjithçka", dhe ideja e saj kryesore është menaxhueshmëria maksimale, zgjerueshmëria, siguria dhe transparenca. Me të, mund të konfiguroni me detaje rrugëtimin e trafikut, autorizimin e aksesit mes shërbimeve, balancimin, monitorimin, lëshimet e kanarinës dhe shumë të tjera. Më shumë rreth Istio lexoni në serinë e artikujve "».
Ambassador
Faqja:
Licenca: Apache 2.0
Një tjetër zgjidhje e bazuar në Envoy. Ka një version falas dhe një version komerciale. Pozicionohet si "plotësisht nativo për Kubernetes", që sjell përfitime përkatëse (integrim i ngushtë me metodat dhe entitetet e klasterit K8s).
Tabela krahasuese
Pra, kulminimi i artikullit është kjo tabelë e madhe:
Ajo është klikueshme për mundësi shikimi më të detajuar, si dhe e disponueshme në formatin .
Të tërheqim përfundimet
Qëllimi i artikullit është të ofrojë një kuptim më të plotë (me të vërtetë, jo plotësisht të gjerë!) se çfarë zgjedhje të bëni në rastin tuaj të veçantë. Si zakonisht, çdo kontrollues ka përfitimet dhe mangësitë e tij...
Ingress-i klasifikuesit nga Kubernetes është i njohur për disponueshmërinë dhe provueshmërinë e tij, si dhe për mundësitë e tij relativisht të pasura - në shumicën e rasteve, duhet të jetë "mjaft". Sidoqoftë, nëse keni kërkesa të larta për stabilitet, nivelin e veçorive dhe zhvillimin, duhet të shqyrtoni Ingress me NGINX Plus dhe një abonim të paguar. Kong ka një set të pasur plugins (dhe, për pasojë, mundësish që i ofron), dhe versioni i paguar ka ende më shumë. Ai ka mundësi të gjera për t'u përdorur si API Gateway, konfigurim dinamik mbi bazën e burimeve CRD, si dhe shërbime bazë të Kubernetes.
Nëse keni kërkesa të larta për balancimin dhe metodat e autorizimit, shqyrtoni Traefik dhe HAProxy. Këto janë projekte me burim të hapur, të provuara për vite, shumë stabile dhe që po zhvillohen aktivisht. Contour u shfaq disa vite më parë, por ende duket tepër i ri dhe ka vetëm mundësi themelore, të shtuara mbi Envoy. Nëse ka kërkesa për praninë/integrimin e WAF para aplikacionit, vlen të shqyrtoni Ingress nga Kubernetes ose HAProxy.
Produktet më të pasura me funksione janë ato të ndërtuara mbi bazën e Envoy, veçanërisht Istio. Ai paraqitet si një zgjidhje komplekse, që "mund gjithçka", që, megjithatë, do të thotë gjithashtu një prag shumë më të lartë për konfigurimin/lansimin/administrimin sesa zgjidhjet e tjera.
Për standardin tonë të kontrolluesit, ne zgjodhëm dhe ende përdorim Ingress nga Kubernetes, i cili mbulon 80-90% të nevojave. Ai është mjaft i besueshëm, lehtësisht i konfigurueshëm dhe i zgjerueshëm. Në përgjithësi, në mungesë të kërkesave specifike, ai duhet të jetë i përshtatshëm për shumicën e grupeve/aplikacioneve. Midis produkteve të tjera universale dhe relativisht të thjeshta, mund të rekomandojmë Traefik dhe HAProxy.
P.S.
Lexoni gjithashtu në blogun tonë:
- "Kthehu në mikroshërbime me Istio": , , ;
- «»;
- «».
Burimi: habr.com
