Kubernetes klastrit käivitades on oluline mõista, millised nõuded selle ressursi suhtes on rakendusel, ärioludel ja arendajatel. Kui see teave on teada, saab alustada arhitektuurilise lahenduse valimist, sealhulgas konkreetse Ingress-kontrolleri valimist, kuna neid on praegu juba palju. Selleks, et saada põhipilti olemasolevatest variantidest ilma hulga artiklite/dokumendi uurimise vajaduseta, oleme koostanud selle ülevaate, lisades põhiaspekte (tootevalmid) Ingress-kontrollerite kohta.
Loodame, et see aitab kolleegidel arhitektuurilise lahenduse valimisel — vähemalt saab see olema lähtepunktiks põhjalikuma teabe ja praktiliste katsete jaoks. Varem oleme uurinud sarnaseid materjale võrgus ja, mis üllatav, ei leidnud ühtegi mõistlikult täielikku ja mis kõige tähtsam — struktureeritud — ülevaadet. Nii et täidame selle tühiku!
Kriteeriumid
Kuna võrreldakse üldiselt ja saadakse mingi kasulik tulemus, on oluline mõista mitte ainult teemat, vaid ka omada konkreetset kriteeriumide loetelu, mis suunavad uurimistööd. Mitte pretendeerides Ingress/Kubernetes kõikide võimalike kasutusjuhtude analüüsile, oleme püüdnud välja tuua kõige üldisemad nõudmised kontrollereid käsitlevalt — olge valmis, et kogu oma spetsiifilisusega tuleb igal juhul eraldi uurida.
Kuid alustan omadustest, mis on saanud nii harjumuseks, et neid on ellu viidud kõikides lahendustes ja ei käsitleta:
- dünaamiline teenuste avastamine (service discovery);
- SSL-terminatsioon;
- töötamine websocketidega.
Nüüd – võrdlemise punktidest:
Toetatud protokollid
Üks põhilisi kriteeriume valiku tegemisel. Teie tarkvara ei pruugi töötada standardse HTTP kujul või nõuda toimimist mitmesuguste protokollide kaudu. Kui teie juhtum on mittestandardne, siis kindlasti arvestage seda tegurit, et hiljem ei peaks klastrit ümber seadistama. Kõikidel kontrollereil varieerub toetatavate protokollide nimekiri.
Tarkvara aluseks
Kontroller põhineb mitmetel rakendustel. Populaarsed on nginx, traefik, haproxy, envoy. Üldiselt ei pruugi see oluliselt mõjutada seda, kuidas liiklust vastu võtetakse ja edastatakse, kuid on alati kasulik teada võimalikke nüansse ja eripärasid, mis on «kapoti all».
Liikluse suunamine
Millisel alusel saab otsustada, kuhu liiklus suunatakse? Tavalised on host ja path, kuid on ka täiendavad võimalused.
Nimi-ala klastris
Nimi-ala (namespace) on võimalus loogiliselt jagada ressursse Kubernetes'is (nt stage, production jne). On Ingress-kontrollereid, mis tuleb paigaldada eraldi igasse nimi-alasse (siis suunab see liikluse ainult selle ala pod'idesse). Samuti on olemas selliseid (ja neid on selgelt enamus), mis töötavad globaalset kogu klastris — nendesse suunatakse liiklus igasse klastri pod'i, sõltumata nimi-alast.
Proovide kontroll põhjendus
Kuidas tagatakse, et liiklus suunatakse tervetesse rakenduse ja teenuse eksemplaridesse? On võimalusi aktiivsete ja passiivsete kontrollide, uuesti katsete (retries), circuit breaker'ite kasutamiseks. (täiendavate detailide kohta vaata näiteks ), kohandatud olekupuuduste kontrollide (custom health checks) ja muu sarnase kohta. See on väga oluline parameeter, kui sul on kõrged nõudmised saadavusele ja kiirele häirete lahendamisele.
Tasakaalustamisalgoritmid
Siin on palju võimalusi: alates traditsioonilistest kuni eksootilisteni nagu , ning ka eraldi võimalused nagu .
Autentimine
Milliseid autentimiskeeme toetab kontroller? Basic, digest, oauth, external-auth — arvan, et need valikud peaksid olema tuttavad. See on oluline kriteerium, kui kasutatakse palju arendajate kontuure (ja/või lihtsalt suletud), millele pääseb ligi läbi Ingressi.
Liiklustõhusus
Kas kontroller toetab selliseid sageli kasutatavaid liikluse jaotamise mehhanisme, nagu kanarindade juurutamine (canary), A/B-testimine, liikluse peegeldamine (mirroring/shadowing)? See on tõeliselt tundlik teema rakendustele, mis vajavad täpset ja delikaatset liikluse haldamist toote testimiseks, tootmisvigade tõrkeotsimiseks mitte reaalajas (või minimeeritud kaotustega), liikluse analüüsimiseks jne.
Tasuline tellimus
Kas kontrolleril on tasuline versioon, millel on laiendatud funktsioonid ja/või tehniline tugi?
Graafiline kasutajaliides (Web UI)
Kas kontrolleri seadete haldamiseks on olemas mingi graafiline kasutajaliides? Peamiselt mugavuse tõttu ja/või neile, kes peavad tegema mingeid muudatusi Ingressi seadistustes, kuid „toorete” malli kasutamine on ebamugav. See võib osutuda kasulikuks, kui arendajad soovivad liikluse kallal katsetada.
JWT-i valideerimine
Sisseehitatud JSON web-tokenite kontroll autoriseerimiseks ja lõppkasutaja valideerimiseks.
Konfiguratsioonifaili kohandamise võimalused
Mallide laiendatavus, mis võimaldab standardsete konfiguratsioonimallide lisada oma direktiive, lippe jms.
Põhimehhanismid DDoS-i eest kaitsmiseks
Lihtsad vajaduse piiramisalgoritmid või keerulisemad võimalused liikluse filtreerimiseks aadresside, valgete nimekirjade, riikide jms alusel.
Küsimuste jälgimine
Ingress’teki belirli hizmetlere/pod’lara yönelik gözlemleme, takip etme ve hata ayıklama yetenekleri, ideal olarak hizmetler/pod’lar arasında da yapılmalıdır.
WAF
Toetamine .
Ingress Kontrolcüsü
Kontrolcülerin listesi şu temel tabloda oluşturulmuştur ja . Bazılarını, belirli bir yere özgü veya yaygın olmayan (erken aşama gelişim) olmaları nedeniyle incelemelerimizden çıkardık. Geriye kalanlar aşağıda ele alınmıştır. Genel çözümlerle başlayıp ardından özet tabloyla devam edelim.
Kubernetes Ingress’i
Veebileht:
Litsents: Apache 2.0
Bu, topluluk tarafından geliştirilen resmi bir Kubernetes kontrolcüsüdür. Adından da anlaşılacağı gibi, nginx üzerine inşa edilmiştir ve ek yetenekler sağlamak için çeşitli Lua eklentileri ile zenginleştirilmiştir. Nginx’in popülaritesinin ve bir kontrolcü olarak kullanıldığında üzerindeki minimum modifikasyonun neden olduğu, ortalama bir mühendis (web deneyimi olan) tarafından en basit ve anlaşılır yapılandırma seçeneği olabilir.
NGINX Inc. Ingress’i
Veebileht:
Litsents: Apache 2.0
Nginx geliştiricilerinin resmi ürünüdür. Ücretli bir versiyonu vardır. . Peamine idee on kõrge stabiilsuse tase, pidev tahesündmuste ühilduvus, väliste moodulite puudumine ja väidetavalt suurenenud kiirus (võrreldes ametliku kontrolleriga), mis on saavutatud Lua'ist loobumisega.
Tasuta versioon on oluliselt kärbitud, sealhulgas isegi ametliku kontrolleriga võrreldes (seoses endiste Lua-moodulite puudumisega). Tasuline versioon peab sisaldama piisaval määral täiendavat funktsionaalsust: reaalajas meetmed, JWT-sertifitseerimine, aktiivsed tervisekontrollid jne. Oluline eelis NGINX Ingress'i ees on täielik TCP/UDP liikluse tugi (ka kogukonna versioonis!). Miinus - funktsioonide osas liikluse jagamiseks, mis „on arendajatele maksimaalse prioriteediga“, kuid vajab rakendamiseks aega.
Kong Ingress
Veebileht:
Litsents: Apache 2.0
Toode, mida arendab Kong Inc. kahes variandis: kommertslik ja tasuta. Põhineb nginx'i platvormil, mille võimalusi on laiendatud suure hulga Lua-moodulitega.
Alguses keskendus see API päringute töötlemisele ja marsruutimisele, st API Gateway näol, kuid praeguseks on see saanud täieõiguslikuks sisenemisjuhtimiseks. Peamised eelised: arvukad lisamoodulid (sealhulgas ka kolmandate osapoolte arendajatelt), mida on lihtne paigaldada ja konfigureerida ning millega saab rakendada laia valikut täiendavaid võimalusi. Siiski pakuvad sisseehitatud funktsioonid juba palju võimalusi. Töö konfigureerimine toimub CRD-ressursside kaudu.
Toote oluline omadus — töö ühes piirios (cross-namespaced asemel) on vaieldav teema: mõned peavad seda puuduseks (iga piiriala jaoks tuleb luua üksused), aga kellegi jaoks on see funktsioon (suurem isolatsiooniaste, kuna kui üks kontroller rikki läheb, siis on probleem piiratud vaid ühe piirkonjaga).ogithub.com/containous/traefik
Traefik
Veebileht:
Litsents: MIT
Proksi, mis on algselt loodud töötama päringute marsruutimisega mikroteenuste ja nende dünaamilise keskkonna jaoks. Seetõttu on olemas mitmed kasulikud funktsioonid: konfigureerimise värskendamine ilma taaskäivitusteta, suur hulk tasakaalustusmeetodeid, veebiliidese toetus, mõõdikute edastamine, erinevate protokollide tugi, REST API, kanarilev release’id ja palju muud. Ka meeldivaks omaduseks on Let’s Encrypt sertifikaatide väljaandmine otse maailmas. Puuduseks on see, et kõrge kättesaadavuse (HA) korral peab kontrolleri jaoks olema installitud ja ühendatud oma KV-ladu.
HAProxy
Veebileht:
Litsents: Apache 2.0
HAProxy on juba ammu tuntud kui proksi ja liikluse tasakaalustaja. Kubernetes klastris pakub see "pehmet" konfiguratsiooniuuendust (ilma liikluse kaotamiseta), DNS-põhise teenuste avastamise ning dünaamilist konfigureerimist API abil. Atraktiivne võib olla täiendav konfiguratsioonimalli kohandamine CM-i asendamise kaudu ning võimalused kasutada selles Sprigi raamatukogu funktsioone. Üldiselt keskendub lahendus kõrgele töökiirusel, optimeeritusele ja tõhususele ressursikasutuses. Kontrolleri eeliseks on rekordarv erinevaid tasakaalustusmeetodeid.
Voyager
Veebileht:
Litsents: Apache 2.0
HAproxy põhine kontroller, mis positsioneerib end universaalse lahendusena, toetades laia valikut võimalusi paljudes teenusepakkujates. Pakub võimalust liikluse tasakaalustamiseks L7 ja L4 tasemel, kusjuures L4 TCP liikluse tasakaalustamist võib pidada lahenduse üheks peamiseks funktsiooniks.
Contour
Veebileht:
Litsents: Apache 2.0
Selle lahenduse aluseks on mitte ainult Envoy: see on välja töötatud koostöös selle populaarse proksi autoritega. Oluline omadus on Ingressi ressursihalduse jagamine CRD-ressursside IngressRoute abil. See aitab organisatsioonidel, millel on mitu arendusmeeskonda, kes kasutavad ühte klastrit, maksimeerida liikluse töötlemise turvalisust naaberkonfiguratsioonides ja kaitsta neid Ingressi ressursside muutmisest põhjustatud vigade eest.
Samuti on saadaval laiendatud tasakaalustamismeetodite komplekt (sh päringute peegeldamine, automaatsed kordused, päringute määra piiramine ja palju muud), põhjalik liikluse ja tõrgete jälgimine. Mõne jaoks võib olla oluline puudus sticky session’ite toe puudumine (kuigi tööd ).
Istio Ingress
Veebileht:
Litsents: Apache 2.0
Kohandatud teenusemeeslahendus, mis on mitte ainult sissetuleva liikluse juhtiv Ingress-kontroller, vaid kontrollib ka kogu liiklust klastris. "Kapoti all" kasutatakse iga teenuse jaoks sidecar-proksina Envoy'd. Sisuliselt on see suur kombain, mis "võib kõike", ja selle peamine mõte on maksimaalne hallatavus, laiendatavus, turvalisus ja läbipaistvus. Selle abil saate peensusteni kohandada liikluse marsruutimist, juurdepääsu autoriseerimist teenuste vahel, koormuse tasakaalustamist, jälgimist, kanarirelease ja palju muud. Lisainfot Istio kohta leiate artiklite seeriast.».
Ambassador
Veebileht:
Litsents: Apache 2.0
Veel üks lahendus Envoy põhjal. Saadaval tasuta ja kaubanduslikud versioonid. Positioneeritakse kui "täiesti Kuberneteses kodune", mis toob kaasa vastavad eelised (tihe integreeritus K8si meetodite ja üksustega).
Võrdlev tabel
Nii et artikli tipptase — see tohutu tabel:
Seda saab klikkida, et näha detailsemalt, ja see on saadaval ka vormingus .
Kokkuvõtteks
Artikli eesmärk on anda põhjalikum arusaam (kuigi mitte ammendav!) sellest, milline valik sobib teie konkreetsele olukorrale. Nagu ikka, on igal kontrolleril omad plussid ja miinused...
Kubernetes'e klassikaline Ingress on hea oma kergesti kätte saadavuse ja usaldusväärsuse poolest ning pakub piisavalt rikkalikke võimalusi — tavaliselt piisab sellest täiesti. Siiski, kui on suurenenud nõudmised stabiilsuse, funktsioonide taseme ja arenduse osas, tasub kaaluda Ingress'i, mis kasutab NGINX Plusi ja tasulist tellimust. Kongil on lai valik pluginaid (ja seega ka nende poolt pakutavaid võimalusi), ning tasulises versioonis on neid isegi rohkem. Sellel on ulatuslikud võimalused töötada API väravana, dünaamiliseks konfigureerimiseks CRD-ressursside põhjal, ja Kubernetes'e põhiteenuste haldamiseks.
Kui teil on kõrgendatud nõuded tasakaalustamise ja autoriseerimise meetodite osas, vaadake Traefiki ja HAProxy poole. Need on avatud lähtekoodiga projektid, mille usaldusväärsust on aastate jooksul testitud ning mille stabiilsus ja areng on pidev. Contour ilmus turule paar aastat tagasi, kuid näeb endiselt liiga noor välja ja omab ainult baass funktsioone, mis on lisatud Envoy põhjal. Kui on nõudmisi WAF-i olemasolu/integreerimise osas enne rakendust, tasub vaadata ka Kubernetes'i Ingressi või HAProxy poole.
Funktsioonide poolest kõige rikkamad tooted on need, mis on ehitatud Envoy põhjal, eriti Istio. See paistab olevat kompleksne lahendus, mis 'suudab kõike', mis omakorda tähendab ka oluliselt kõrgemat sisenemispiiri konfiguratsiooni/käivitamise/halduse osas võrreldes teiste lahendustega.
Meie valikuks on olnud ja endiselt kasutatakse Kubernetes'elt saadud Ingress, mis katab 80–90% vajadustest. See on piisavalt usaldusväärne, kergesti seadistatav ja laiendatav. Üldiselt peaks see sobima enamikule klastritest/rakendustest, kui pole spetsiifilisi nõudeid. Sarnastest universaalsetest ja suhteliselt lihtsatest toodetest võib soovitada ka Traefik ja HAProxy.
P.S.
Lugege ka meie blogist:
- „Tagasi mikroteenuste juurde koos Istio’ga“: , , ;
- «»;
- «».
Allikas: habr.com
