🥇Kubernetes'e Ingress'i kontrollerite ülevaade ja võrdlus

Kubernetes'e klastri käivitamisel konkreetse rakenduse jaoks tuleks mõista, millised nõudmised see rakendus koos äri ja arendajatega sellele ressursile esitab. Kui see teave on olemas, saab alustada arhitektuurilise otsuse tegemist, sealhulgas valida konkreetse Ingress-kontrolleri, mida tänaseks on juba palju. Selle ülevaate koostamiseks, et anda baasteave olemasolevate variantide kohta ilma paljude artiklite / dokumentatsiooni jms uurimiseta, oleme selle ülevaate ette valmistanud, kaasates peamised (tootmiskõlbulikud) Ingress-kontrollerid.

Loodame, et see aitab kolleegidel arhitektuurilise lahenduse valimisel — vähemalt on see alguspunkt, et saada üksikasjalikumat teavet ja praktilisi katsetusi. Oleme eelnevalt uurinud teisi sarnaseid materjale veebis ning, imelik küll, ei leidnud ühtegi rohkem-või-vähem täielikku, ja mis kõige tähtsam — struktureeritud — ülevaadet. Nii et lükakem see puudujääk täide!

Kriteeriumid

Kuna võrreldavate tulemuste saamiseks tuleb mõista mitte ainult teemat, vaid ka omada konkreetset kriteeriumide loetelu, mis suunavad uurimist. Ilma et püüdleksime kõigi võimalike Ingress / Kubernetes'e kasutusjuhtumite analüüsi poole, püüdsime esile tuua kõige üldisemad nõuded kontrolleritele — olge valmis, et kogu oma eripära ja detailid tuleb siiski eraldi uurida.

Kuid alustame omadustest, mis on muutunud nii levinuks, et need on teostatud kõigis lahendustes ja neid ei käsitleta:

dünaamiline teenuste avastamine (service discovery);
SSL-i terminatsioon;
töötamine websocket'idega.

Nüüd — võrreldavad punktid:

Toetatud protokollid

Üks põhikriteeriumidest valiku jaoks. Teie tarkvara ei pruugi töötada standardse HTTP kaudu või nõuda koos töötamist mitmete protokollidega. Kui teie juhtum on ebatavaline, võtke kindlasti arvesse seda tegurit, et teil hiljem ei peaks kloorimise klastrit üle seadistama. Kõikide kontrollerite toetatud protokollide nimekiri varieerub.

Tarkvara aluseks

On erinevaid rakendusi, millel põhinevad kontrollerid. Populaarsed on nginx, traefik, haproxy, envoy. Üldiselt ei pruugi see tugevalt mõjutada, kuidas liiklus vastu võetakse ja edastatakse, kuid alati on kasulik teada võimalikke nüansse ja omadusi, mis on "kapoti all".

Liikluse marsruutimine

Mille alusel saab otsustada, kuhu suunata liiklus teatud teenusesse? Tüüpiliselt on selleks host ja path, kuid võivad olla ka täiendavad võimalused.

Nimeala klastris

Nimeala (namespace) — võimalus loogiliselt jaotada ressursse Kuberneteses (näiteks stseeni, tootmise jne järgi). On Ingress-kontrollereid, mida tuleb igasse nimealasse eraldi installeerida (ja siis suudavad nad liiklust suunata seda selle nimeala pod'idesse). Kuid on ka teisi (ja neid on selgelt enamuses), mis töötavad globaalselt kogu klastris — neid kasutades suunatakse liiklus igasse klastris asuvasse pod'i, sõltumata nimealast.

Ülesvoolu proovid

Kuidas tagatakse liikluse suunamine tervetesse rakenduste, teenuste eksemplaridesse? On variante aktiivsete ja passiivsete kontrollidega, korduvate katsetega (retries), circuit breakeri (rohkem neist vt näiteks, artikkel Istio'st), kohandatud olekute kontrollide (custom health checks) jne. See on väga oluline parameeter, kui teie nõudmised kättesaadavuse ja katkestustega välja langemise vajaduste osas on kõrged.

Tasakaalustamisalgoritmid

Siin on mitmeid variante: alates traditsioonilisest round-robin kuni eksootiliseni nagu rdp-cookie, samuti eraldi võimalused nagu sticky sessions.

Ahnikeerimine

Milliseid autoriseerimise skeeme toetab kontroller? Basic, digest, oauth, external-auth — ma arvan, et need valikud peaksid olema tuttavad. See on oluline kriteerium, kui kasutatakse palju kontuure arendajatele (ja/või lihtsalt suletud), millele pääseb ligi läbi Ingressi.

Liikluse jaotamine

Kas kontroller toetab selliseid sageli kasutatavaid mehhanisme liikluse jaotamiseks nagu kanarisüsteemid (canary), A/B-testimine, liikluse peegeldamine (mirroring/shadowing)? See on tõeliselt probleemne teema rakenduste jaoks, mis vajavad delikaatset ja täpset liikluse juhtimist tootetestimise, tootmisvigade silumise (või minimaalsete kadudega), liikluse analüüsi jne jaoks.

Tasuline tellimus

Kas on olemas tasuline versioon kontrollerist, millel on laiendatud funktsionaalsus ja/või tehniline tugi?

Graafiline liides (Web UI)

Kas kontrolleri konfiguratsiooni haldamiseks on olemas mõni graafiline liides? Peamiselt mugavuse huvides ja/või neile, kes peavad tegema muudatusi Ingress'i konfiguratsioonis, kuid on ebamugav töötada "toorete" šabloonidega. See võib osutuda kasulikuks juhul, kui arendajad soovivad reaalajas katsetada liiklust.

JWT-valiidatsioon

Sisseehitatud JSON web-tokenite kontrollimise võimalus kasutaja autentimiseks ja valideerimiseks lõpprakenduses.

Konfiguratsiooni kohandamise võimalused

Šabloonide laiendatavus, et võimaldada standardsete konfiguratsioonimudelite kohandamist oma direktiivide, lippude jne lisamise mehhanismide kaudu.

Põhimehhanismid DDOS-i kaitseks

Lihtsad kiiruspiirangute algoritmid või keerukamad versioonid liikluse filtreerimiseks aadresside, lubatud loendite, riikide jne alusel.

Küsimuste jälgimine

Võimalused Ingress'ide ja konkreetsete teenuste/pod'ide vaheliste päringute jälgimiseks, jälgimiseks ja tõrkeotsinguks ning ideaaljuhul – ka teenuste/pod'ide vahel.

WAF

Tugi rakendusfirewall.

Ingress'i kontrollerid

Kontrollerite nimekiri on koostatud Kubernetes'e ametlikust dokumentatsioonist ja sellest tabelist. Mõned neist oleme erandeid teinud spetsiifilisuse või väikese leviku (arengufaasi) tõttu. Järelejäänud on allpool arutatud. Alustame üldise ülevaate kirjeldusest ja jätkame koondtabeliga.

Ingress Kubernetes'elt

Veebisait: github.com/kubernetes/ingress-nginx
Litsents: Apache 2.0

See on ametlik kontroller Kubernetes'e jaoks, mille on välja töötanud kogukond. Nimi annab selgelt mõista, et see põhineb nginx'il ning on varustatud erinevate Lua-pluginatega, mida kasutatakse täiendavate võimaluste rakendamiseks. Tänu nginx'i populaarsusele ja minimaalsetele muudatustele selle kasutamisel kontrollerina on see variant keskmise inseneri (web-kogemusega) jaoks kõige lihtsam ja arusaadavam konfigureerida.

Ingress NGINX Inc'ilt

Veebisait: github.com/nginxinc/kubernetes-ingress
Litsents: Apache 2.0

Ametlik toode nginx'i arendajatelt. Omab tasulist versiooni, mis põhineb NGINX PlusPeamine idee on kõrge stabiilsuse tase, pidev tagasipööratavus, kõrvaliste moodulite puudumine ja väidetav suurenenud kiirus (võrreldes ametliku kontrolleriga), mis on saavutatud Lua loobumise tõttu.

Tasuta versioon on oluliselt kärbitud, sealhulgas isegi ametliku kontrolleriga võrreldes (kuna puuduvad jälle need samad Lua-moodulid). Tasuline versioon omab samas piisavalt laia lisafunktsionaalsust: reaalajas mõõdikud, JWT-aktiveerimine, aktiivsed health check'id ja muud. Oluline eelis NGINX Ingress'i ees on täielik TCP/UDP liikluse tugi (ka community versioonis!). Miinus - puuduvad funktsioonid liikluse jagamiseks, mis, muide, on "arendajate jaoks maksimaalse prioriteediga", kuid nõuab selle elluviimiseks aega.

Kong Ingress

Veebisait: github.com/Kong/kubernetes-ingress-controller
Litsents: Apache 2.0

Toode, mida arendab ettevõte Kong Inc. kahes versioonis: kommerts- ja tasuta. See põhineb nginx'il, mille võimalusi on laiendatud suure hulga Lua moodulitega.

Esialgu oli see suunatud API päringute töötlemiseks ja marsruutimiseks, st kui API Gateway, kuid hetkel on sellest saanud täieõiguslik Ingress-kontroller. Peamised eelised: mitmed lisamoodulid (ka kolmandate osapoolte arendajatelt), mida on lihtne installida ja konfigureerida ning millega saab realiseerida laia spektri täiendavaid võimalusi. Samas pakuvad sisseehitatud funktsioonid juba palju võimalusi. Töö konfiguratsioon toimub CRD-resursside kaudu.

Toote oluline omadus - töötamine ühes kontuuris (asemel cross-namespaced) on vaieldav teema: kellelegi võib see tunduda puudusena (kuna tuleb igas kontuuris luua üksused), kuid kellelegi on see omadus (bilotkasuurem isolatsioonitase, kuna kui üks kontroller on rikutud, siis probleem on piiratud vaid ühe kontuuriga).

Traefik

Veebisait: github.com/containous/traefik
Litsents: MIT

Proxii, mis loodi algselt mikroteenuste ja nende dünaamilise keskkonna päringute suunamiseks. Seetõttu on sellel palju kasulikke funktsioone: seadistuste värskendamine ilma taaskäivitusteta, mitmekesiste tasakaalustusmeetodite tugi, veebiliides, mõõdikute edastamine, erinevate protokollide toimetamine, REST API, kanaroude väljalasked ja palju muud. Meeldiv omadus on ka Let’s Encrypti sertifikaatide tugi otse karbist. Puuduseks on, et kõrge kättesaadavuse (HA) korral peab kontrollerile olema seatud ja ühendatud oma KV-lao.

Edasi läks kliendi päring HAProxy-sse, mis lahendas järgmised ülesanded:

Veebisait: github.com/jcmoraisjr/haproxy-ingress
Litsents: Apache 2.0

HAProxy on tuntud kui proksi ja liikluse tasakaalustaja. Kubernetes'i klastris pakub see "pehmet" seadistuste värskendust (ilma liiklust kaotamata), DNS-põhist teenuse avastamist, dünaamilist konfiguratsiooni API abil. Atraktiivne võib olla täielik konfigureerimise mallide isikupärastamine CM-i asendamise kaudu, samuti Sprigi raamatukogu funktsioonide kasutamise võimalused. Üldiselt keskendub lahenduse põhitähelepanu töö kiirus, optimeeritus ja ressursikasutuse efektiivsus. Kontrolleri eeliseks on rekordiliselt palju erinevaid tasakaalustusviise.

Voyager

Veebisait: github.com/appscode/voyager
Litsents: Apache 2.0

HAproxy'le põhinev kontroller, mis positsioneeritakse universaalse lahendusena, pakkudes laia valikut võimalusi paljude pakkujate seas. Pakub võimalust liikluse tasakaalustamiseks L7 ja L4 tasemel ning TCP L4-liikluse tasakaalustamist võib pidada lahenduse üheks põhifunktsiooniks.

Contour

Veebisait: github.com/heptio/contour
Litsents: Apache 2.0

Selle lahenduse aluseks ei ole mitte ainult Envoy: see on välja töötatud koosluses selle populaarse proksi autoritega. Oluline omadus on Ingress'i ressursside haldamise eristamine IngressRoute CRD-resursside kaudu. Organisatsioonide jaoks, kus paljud arendusmeeskonnad kasutavad ühte klastrit, aitab see maksimaalselt kaitsta liiklust naaberpiirides ja kaitsta neid vigu Ingress'i ressursside muutmisel.

Pakutavakse laiem komplekt koormuse tasakaalustamise meetodeid (sh päringute peegeldamine, automaatsed kordused, päringute kiiruspiirangud ja palju muud), detailne liikluse ja tõrgete jälgimine. Võib-olla mõne jaoks on märkimisväärne miinus sticky sessions toe puudumine (kuigi tööd on juba käimas).

Istio Ingress

Veebisait: istio.io/docs/tasks/traffic-management/ingress
Litsents: Apache 2.0

Kohandatud teenuste mesh-lahendus, mis ei ole mitte ainult sissepääsukontroller, mis haldab väljastpoolt tulevat liiklust, vaid kontrollib ka kogu liiklust klastris. 'Kapoti all' kasutatakse iga teenuse jaoks sidecar-proksi, milleks on Envoy. Essentsilt on see suur kombain, mis 'oskab kõike', ja selle põhieesmärk on maksimaalne hallatavus, laiendatavus, turvalisus ja läbipaistvus. Selle abil saate detailselt seadistada liikluse marsruutimist, juurdepääsu autoriseerimist teenuste vahel, koormuse jaotamist, jälgimist, kanarrelease ja palju muud. Lisainfot Istio kohta loe sarjast artikleid 'Tagasi mikroteenustele koos Istio».

Ambassador

Veebisait: github.com/datawire/ambassador
Litsents: Apache 2.0

Veel üks lahendus, mis põhineb Envoy. Saadaval on tasuta ja kommertsversioon. Positiivne, et see on 'täielikult Kubernetesele kohandatud', mis kinnitab sellega seonduvaid eeliseid (tihe integreeritus K8s klastrite meetodite ja entiteetidega).

Võrdlustabel

Nii et artikli tipuks on see suur tabel:

See on klikatav, et saaksite selgemalt vaadata, ja saadaval ka vormingus Google Sheets.

Kokkuvõtteks

Artikli eesmärk on anda põhjalikum arusaam (kuigi mitte ammendav!), milline valik teha just teie konkreetses olukorras. Nagu tavaliselt, on iga kontrolleril omad plusse ja miinuseid...

Kubernetes'i klassikaline Ingress on hea oma kättesaadavuse ja usaldusväärsuse poolest, samuti piisava hulga funktsioonide poolest — see peaks enamasti piisama. Kuid kui on kõrgendatud nõuded stabiilsusele, funktsioonide tasemele ja arengule, tasub tähelepanu pöörata NGINX Plus Ingress'ile ja tasulisele tellimusele. Kongil on rikkalik pluginakogum (ja vastavalt seeläbi pakutavad võimalused), ning tasulisest versioonist leiab neid isegi rohkem. Sellel on laiad võimalused API Gateway'na töötamiseks, dünaamiliseks konfigureerimiseks CRD-resursside põhjal ning ka Kubernetes'i põhiteenuste jaoks.

Kui teil on suuremad nõuded koormuse tasakaalustamise ja autentimismeetodite osas, uurige Traefiki ja HAProxy. Need on avatud lähtekoodiga projektid, mis on aastate jooksul tõestatud, väga stabiilsed ja aktiivselt arenevad. Contour ilmus juba paar aastat tagasi, kuid näeb endiselt liiga noor välja ja sellel on vaid põhifunktsioonid, mis on lisatud Envoy'i peale. Kui on nõuded WAF'i olemasolu / integreerimise osas rakenduse ette, tasub tähelepanu pöörata ka Kubernetes'i või HAProxy Ingress'ile.

Kõige rikkamad funktsioonide poolest on tooted, mis põhinevad Envoy'l, eriti Istio. See esindab komplekset lahendust, mis "suudab kõike", mis tähendab samuti oluliselt kõrgemat õppimiskõverat konfiguratsiooni / käivitamise / haldamise osas võrreldes teiste lahendustega.

Me valisime standardsete kontrolleritena Ingress'i Kubernetes'ilt, mis katab 80–90% vajadustest. See on täiesti usaldusväärne, lihtne konfigureerida ja laiendada. Üldiselt peaks see sobima enamiku klastrite / rakenduste jaoks, välja arvatud juhul, kui on spetsiifilisi nõudmisi. Samadest universaalsetest ja suhteliselt lihtsatest toodetest võib soovitada Traefiki ja HAProxy.