Ha egy adott alkalmazáshoz Kubernetes-fürtöt indít, meg kell értenie, hogy maga az alkalmazás, a vállalkozás és a fejlesztők mit jelentenek ennek az erőforrásnak. Ezen információk birtokában megkezdheti az építészeti döntések meghozatalát, és különösen a konkrét Ingress vezérlő kiválasztását, amelyekből ma már nagy számban van. Annak érdekében, hogy alapötletet kapjunk a rendelkezésre álló lehetőségekről anélkül, hogy sok cikken / dokumentáción stb. kellene átmenni, elkészítettük ezt az áttekintést, beleértve a fő (gyártásra kész) Ingress vezérlőket.
Reméljük, hogy segítségére lesz a kollégáknak az építészeti megoldás kiválasztásában - legalább kiindulópontja lesz a részletesebb információk megszerzésének, gyakorlati kísérleteknek. Korábban más hasonló anyagokat tanulmányoztunk a neten, és furcsa módon egyetlen többé-kevésbé teljes, és ami a legfontosabb - strukturált - áttekintést nem találtunk. Tehát pótoljuk ezt a hiányt!
kritériumok
Elvileg ahhoz, hogy összehasonlítást végezhessen és bármilyen hasznos eredményt kapjon, nemcsak a témakört kell megértenie, hanem egy konkrét kritériumlistával is kell rendelkeznie, amely meghatározza a kutatási vektort. Anélkül, hogy elemeznénk az Ingress / Kubernetes használatának minden lehetséges esetét, megpróbáltuk kiemelni a vezérlőkkel szemben támasztott legáltalánosabb követelményeket - készüljön fel arra, hogy minden esetben külön-külön kell tanulmányoznia az összes sajátosságát és adatait.
De kezdem azokkal a jellemzőkkel, amelyek annyira ismertté váltak, hogy minden megoldásban megvalósulnak, és nem veszik figyelembe:
- szolgáltatások dinamikus felfedezése (szolgáltatás-felderítés);
- SSL megszüntetése;
- websocketekkel való munkavégzés.
És most az összehasonlítási pontok:
Támogatott protokollok
Az egyik alapvető kiválasztási kritérium. Előfordulhat, hogy szoftvere nem működik szabványos HTTP-n, vagy egyszerre több protokollon is kell dolgozni. Ha az eset nem szabványos, mindenképpen vegye figyelembe ezt a tényezőt, hogy ne kelljen később újrakonfigurálnia a fürtöt. A támogatott protokollok listája minden vezérlő esetében eltérő.
szoftver az alapja
Számos alkalmazási változat létezik, amelyeken a vezérlő alapul. Népszerűek az nginx, traefik, haproxy, envoy. Általánosságban elmondható, hogy nem sok hatása van a forgalom fogadására és továbbítására, de mindig hasznos ismerni a „burkolat alatt” lévő dolgok lehetséges árnyalatait és jellemzőit.
Forgalomirányítás
Mi alapján lehet döntést hozni egy adott szolgáltatás forgalmi irányáról? Általában ezek a gazdagép és az útvonal, de vannak további lehetőségek is.
Névtér egy fürtön belül
Névtér (névtér) - az erőforrások logikai felosztásának képessége a Kubernetesben (például színpadon, produkcióban stb.). Vannak bemeneti vezérlők, amelyeket minden névtérben külön kell telepíteni (és akkor irányíthatják a forgalmat csak ennek a térnek a hüvelyéhez). És vannak olyanok (és egyértelmű többségük), amelyek globálisan működnek a teljes fürtre vonatkozóan – ezekben a forgalom a fürt bármely podjára irányul, a névtértől függetlenül.
Minták az upstreamhez
Hogyan irányítják a forgalmat az alkalmazások, szolgáltatások egészséges példányaihoz? Vannak aktív és passzív ellenőrzések, újrapróbálkozások, megszakítók opciói (További részletekért lásd pl. ), egészségügyi ellenőrzések saját megvalósítása (egyedi állapotfelmérés) stb. Nagyon fontos paraméter, ha magas követelményeket támaszt a rendelkezésre állásra és a meghibásodott szolgáltatások kiegyenlítésből való időben történő eltávolítására.
Kiegyensúlyozó algoritmusok
Sok lehetőség van: a hagyományostól az egzotikumhoz , valamint az egyéni funkciók, mint pl .
Hitelesítés
Milyen engedélyezési sémákat támogat az adatkezelő? Basic, digest, oauth, external-auth – szerintem ezeknek a lehetőségeknek ismerősnek kell lenniük. Ez fontos kritérium, ha sok fejlesztői (és/vagy csak privát) hurok érhető el az Ingressen keresztül.
Forgalomelosztás
Támogatja-e a vezérlő az olyan gyakran használt forgalomelosztási mechanizmusokat, mint a canary rollouts (kanári), az A/B tesztelés, a forgalom tükrözése (tükrözés/árnyékolás)? Ez egy nagyon fájó téma az olyan alkalmazások esetében, amelyek pontos és precíz forgalomkezelést igényelnek a hatékony teszteléshez, a termékhibák off-line (vagy minimális veszteséggel történő) hibakereséséhez, forgalomelemzéshez stb.
Fizetett előfizetés
Van-e fizetős opció a vezérlőhöz, fejlett funkciókkal és/vagy műszaki támogatással?
Grafikus felhasználói felület (webes felhasználói felület)
Van valamilyen grafikus felület a vezérlő konfigurációjának kezelésére? Főleg a "kényelmességnek" és/vagy azoknak, akiknek módosítaniuk kell az Ingress'a konfigurációt, de a "nyers" sablonokkal dolgozni kényelmetlen. Hasznos lehet, ha a fejlesztők kísérleteket szeretnének végezni a forgalommal menet közben.
JWT érvényesítés
A JSON webes tokenek beépített érvényesítésének jelenléte a felhasználó hitelesítéséhez és érvényesítéséhez a végalkalmazáshoz.
Lehetőségek a konfiguráció testreszabására
Sablonbővíthetőség abban az értelemben, hogy olyan mechanizmusok vannak, amelyek lehetővé teszik saját direktívák, jelzők stb. hozzáadását a szabványos konfigurációs sablonokhoz.
Alapvető DDOS védelmi mechanizmusok
Egyszerű sebességkorlátozási algoritmusok vagy bonyolultabb forgalomszűrési lehetőségek címek, fehérlisták, országok stb. alapján.
Nyomkövetés kérése
Képes figyelni, nyomon követni és hibakeresési kéréseket az Ingresses-től bizonyos szolgáltatásokhoz/podokhoz, és ideális esetben a szolgáltatások/pod-ok között is.
WAF
támogatás .
Vezérlők
alapján alakult ki az irányítók listája и . Néhányukat kizártuk az áttekintésből specifitás vagy alacsony prevalencia (a fejlődés korai szakasza) miatt. A többit alább tárgyaljuk. Kezdjük a megoldások általános leírásával, és folytassuk egy összefoglaló táblázattal.
Belépés a Kubernetestől
Honlap:
Licenc: Apache 2.0
Ez a Kubernetes hivatalos vezérlője, amelyet a közösség fejleszt. A névből nyilvánvaló, hogy az nginx-en alapul, és egy másik Lua bővítmény egészíti ki, amelyek további funkciók megvalósítására szolgálnak. Maga az nginx népszerűsége és minimális módosítása miatt, ha vezérlőként használják, ez az opció lehet a legegyszerűbb és legkönnyebben konfigurálható egy átlagos (webes tapasztalattal rendelkező) mérnök számára.
Ingress by NGINX Inc.
Honlap:
Licenc: Apache 2.0
Az nginx fejlesztők hivatalos terméke. alapján fizetett változata van . A fő ötlet a magas szintű stabilitás, az állandó visszafelé kompatibilitás, az idegen modulok hiánya és a bejelentett megnövelt sebesség (a hivatalos vezérlőhöz képest), ami a Lua elutasítása miatt érhető el.
Az ingyenes verzió jelentősen csökkent, még a hivatalos vezérlővel összehasonlítva is (azonos Lua modulok hiánya miatt). Ugyanakkor a fizetős meglehetősen széles kiegészítő funkcióval rendelkezik: valós idejű mérőszámok, JWT érvényesítés, aktív állapotellenőrzés stb. Egy fontos előny az NGINX Ingress-szel szemben a TCP / UDP forgalom teljes támogatása (és a közösségi verzióban is!). Mínusz - forgalomelosztási funkció, amely azonban „a fejlesztők számára a legmagasabb prioritást élvezi”, de megvalósítása időbe telik.
Kong Ingress
Honlap:
Licenc: Apache 2.0
A terméket a Kong Inc. fejlesztette ki. két változatban: kereskedelmi és ingyenes. Az nginx-en alapul, amelyet számos Lua modullal bővítettek.
Kezdetben az API kérések feldolgozására és útválasztására összpontosított, azaz. API Gatewayként, de jelenleg teljes értékű Ingress vezérlővé vált. Főbb előnyök: sok további modul (beleértve a külső fejlesztőktől származó modulokat is), amelyek könnyen telepíthetők és konfigurálhatók, és amelyek segítségével további funkciók széles skálája valósul meg. A beépített funkciók azonban már számos lehetőséget kínálnak. A feladat konfigurálása CRD-erőforrások használatával történik.
A termék egyik fontos jellemzője - az azonos kontúron belüli munkavégzés (a keresztnévterek helyett) vitatott téma: egyesek számára ez hátránynak tűnik (minden kontúrhoz entitásokat kell készíteni), valakinek pedig jellemző ( bоNagyobb fokú elszigeteltség, mint pl ha az egyik vezérlő elromlott, akkor a probléma csak az áramkörre korlátozódik).
Traefik
Honlap:
Engedély: MIT
Egy proxy, amelyet eredetileg a mikroszolgáltatások és dinamikus környezetük kérés-útválasztásával való együttműködésre hoztak létre. Ezért számos hasznos szolgáltatás: a konfiguráció frissítése újraindítás nélkül, számos egyensúlyozási módszer támogatása, webes felület, metrikák továbbítása, különféle protokollok támogatása, REST API, kanári kiadások és még sok más. Egy másik jó szolgáltatás a Let's Encrypt tanúsítványok azonnali támogatása. Hátránya, hogy a magas rendelkezésre állás (HA) megszervezéséhez a vezérlőnek saját KV tárolót kell telepítenie és csatlakoztatnia kell.
HAProxy
Honlap:
Licenc: Apache 2.0
A HAProxy régóta ismert proxy és forgalomelosztó. A Kubernetes-fürt részeként „puha” konfigurációfrissítést kínál (forgalomveszteség nélkül), DNS-alapú szolgáltatásfelderítést, dinamikus konfigurációt API segítségével. Vonzó lehet a konfigurációs sablon teljes testreszabása a CM cseréjével, valamint a Sprig könyvtári funkciók használatának lehetősége. Általánosságban elmondható, hogy a megoldás fő hangsúlya a nagy sebességen, annak optimalizálásán és a felhasznált erőforrások hatékonyságán van. A vezérlő előnye, hogy rekordszámú különböző kiegyensúlyozási módot támogat.
Hajóutas
Honlap:
Licenc: Apache 2.0
A HAproxy vezérlőn alapul, amely egy univerzális megoldás, amely számos szolgáltatást támogat számos szolgáltatónál. Lehetőség kínálkozik az L7 és L4 forgalmának kiegyenlítésére, a TCP L4 forgalom egészének kiegyenlítése pedig a megoldás egyik kulcsfontosságú jellemzőjének nevezhető.
Körvonal
Honlap:
Licenc: Apache 2.0
Ez a megoldás nem csak az Envoy-n alapul: fejlesztette ki közösen ennek a népszerű proxynak a szerzőivel. Fontos funkció az Ingress-erőforrások vezérlésének elkülönítése az IngressRoute CRD-erőforrások segítségével. Az ugyanazt a fürtöt használó több fejlesztőcsapattal rendelkező szervezetek számára ez segít maximalizálni a szomszédos hurkok forgalmával való munka biztonságát, és megvédi őket a hibáktól az Ingress erőforrások módosításakor.
Kibővített kiegyensúlyozási módszereket is kínál (van kéréstükrözés, automatikus ismétlés, kérések gyakoriságának korlátozása és még sok más), a forgalom és a hibák részletes figyelése. Talán valaki számára jelentős hátrányt jelent a ragadós munkamenetek támogatásának hiánya (bár a munka ).
Istio Ingress
Honlap:
Licenc: Apache 2.0
Átfogó szervizháló-megoldás, amely nem csak egy Ingress vezérlő, amely kívülről kezeli a bejövő forgalmat, hanem a fürtön belüli összes forgalmat is. A motorháztető alatt az Envoy oldalkocsis proxyként szolgál minden szolgáltatáshoz. Lényegében egy nagy kombájnról van szó, ami „bármire képes”, fő gondolata a maximális kezelhetőség, bővíthetőség, biztonság és átláthatóság. Ezzel finomhangolhatja a forgalomirányítást, a szolgáltatások közötti hozzáférési jogosultságot, az egyensúlyozást, a megfigyelést, a Canary kiadásokat és még sok mást. Tudjon meg többet Istióról a cikksorozatban "".
Nagykövet
Honlap:
Licenc: Apache 2.0
Egy másik megoldás az Envoy alapján. Ingyenes és kereskedelmi verziója van. Úgy helyezték el, hogy "teljesen natív a Kubernetesben", ami a megfelelő előnyökkel jár (szoros integráció a K8s-fürt módszereivel és entitásaival).
Összehasonlító táblázat
Tehát a cikk csúcspontja ez a hatalmas táblázat:
A közelebbi megtekintéshez kattintható, és formátumban is elérhető .
Összefoglalva
Ennek a cikknek az a célja, hogy teljesebb megértést nyújtson (azonban semmiképpen sem teljes körű!) arról, hogy az Ön konkrét esetben milyen döntést kell hoznia. Szokás szerint minden vezérlőnek megvannak a maga előnyei és hátrányai…
A Kubernetes klasszikus Ingress jó elérhetősége és beváltsága miatt, elég gazdag funkciókkal - általános esetben "elég a szemnek". Ha azonban megnövekedett követelmények vannak a stabilitás, a szolgáltatások szintje és a fejlesztés terén, akkor érdemes figyelni az Ingressre NGINX Plus-szal és fizetős előfizetéssel. Kong rendelkezik a leggazdagabb beépülő modulokkal (és ennek megfelelően az általuk nyújtott lehetőségekkel), és a fizetős verzióban még több van belőlük. Bőséges lehetőségekkel rendelkezik API-átjáróként, CRD-erőforrásokon alapuló dinamikus konfigurációval, valamint alapvető Kubernetes-szolgáltatásokkal.
A kiegyensúlyozási és engedélyezési módszerekre vonatkozó fokozott követelmények miatt vessen egy pillantást a Traefikre és a HAProxyra. Ezek nyílt forráskódú projektek, amelyek az évek során beváltak, nagyon stabilak és aktívan fejlődnek. A Contour már pár éve megjelent, de még mindig túl fiatalnak tűnik, és csak az alapvető funkciókat adta hozzá az Envoyhoz. Ha követelmények vannak a WAF jelenlétére / beágyazására az alkalmazás előtt, akkor figyeljen ugyanarra a Kubernetes vagy HAProxy bemenetére.
A funkciókban pedig a leggazdagabbak az Envoy tetejére épített termékek, különösen az Istio. Átfogó megoldásnak tűnik, amely „mindent megtehet”, ami azonban lényegesen magasabb belépési küszöböt jelent a konfigurációhoz / indításhoz / adminisztrációhoz, mint más megoldások.
A Kubernetes Ingress-jét választottuk és használjuk standard vezérlőnek, amely az igények 80-90%-át fedezi. Megbízható, könnyen konfigurálható és bővíthető. Általánosságban elmondható, hogy speciális követelmények hiányában a legtöbb klaszternek/alkalmazásnak meg kell felelnie. Ugyanezen univerzális és viszonylag egyszerű termékek közül a Traefik és a HAProxy ajánlható.
PS
Olvassa el blogunkon is:
- "Vissza a mikroszolgáltatásokhoz az Istióval": , , ;
- «";
- «".
Forrás: will.com