A Kubernetes cluster for a specific application should consider the requirements from the application, the business, and the developers. With this information, one can start making architectural decisions, particularly in choosing a specific Ingress controller, of which there are already many available today. To provide a basic overview of the available options without having to study numerous articles/documentation, we have prepared this review, including the main (production ready) Ingress controllers.
We hope this will assist colleagues in selecting an architectural solution — at the very least, it will serve as a starting point for obtaining more detailed information and practical experiments. We initially researched similar materials online and, strangely enough, found not a single reasonably complete, let alone structured, review. So let's fill this gap!
Criteria
To conduct a comparison and obtain any useful results, one must understand not only the subject area but also have a specific list of criteria that will guide the research focus. Without claiming to analyze all possible use cases for Ingress/Kubernetes, we have attempted to highlight the most common requirements for controllers — be prepared that specific details will need to be studied separately.
But I will start with characteristics that have become so common that they are implemented in all solutions and are not discussed:
- dynamic service discovery;
- SSL termination;
- working with websockets.
Now — on the comparison points:
Supported protocols
One of the fundamental criteria for selection. Your software may not operate on standard HTTP or may require functioning with multiple protocols simultaneously. If your case is non-standard, be sure to consider this factor to avoid having to reconfigure the cluster later. The list of supported protocols varies among all controllers.
Software at its core
Többféle alkalmazás létezik, amelyen a vezérlő alapul. A legnépszerűbbek közé tartozik a nginx, traefik, haproxy, envoy. Általában nem befolyásolja túlságosan, hogy a forgalmat hogyan fogadják és továbbítják, de mindig hasznos tudni a potenciális finomságokat és jellemzőket, ami a „motorháztető alatt” található.
Forgalomirányítás
Milyen alapokon lehet dönteni a forgalom irányításáról egy adott szolgáltatás felé? Általában ez a host és a path, de vannak további lehetőségek is.
Névtér a klaszteren belül
A névtér (namespace) a Kubernetes erőforrások logikai felosztásának lehetősége (például stage, production stb.). Vannak Ingress-vezérlők, amelyeket külön kell telepíteni minden névtérbe (és így forgalmat irányíthatnak az adott térbe tartozó podokba). Vannak olyanok is (és ezek a többség), amelyek globálisan működnek az egész klaszterre — a forgalmat bármely podhoz irányítják a klaszteren belül, függetlenül a névtől. a fő DB példányhoz a podokba az adott térbe). Vannak olyan vezérlők is (és ezek a többség), amelyek globálisan működnek az egész klaszterre — az ilyen vezérlők bármely podhoz irányítják a forgalmat, függetlenül a névtértől.
Kérdések az upstreamokhoz
Hogyan biztosítják a forgalom irányítását az egészséges alkalmazás- és szolgáltatásminták felé? Vannak lehetőségek aktív és passzív ellenőrzésekre, újrapróbálkozásokra (retries), áramkörmegszakítókra. (további információkért lásd például a ), saját állapotellenőrzési megoldásaikkal (custom health checks) stb. Ez egy nagyon fontos paraméter, ha magas elérhetőségi és időben történő kivezetési követelmények vannak a hibás szolgáltatásokból.
Kiegyensúlyozási algoritmusok
Itt számos lehetőség van: a hagyományos módszerektől egészen egzotikusakig, mint például , valamint különböző lehetőségek, mint például .
Hitelesítés
Milyen hitelesítési sémákat támogat a vezérlő? Basic, digest, oauth, external-auth — gondolom, hogy ezek az opciók ismerősek. Ez egy fontos kritérium, ha sok fejlesztői (és/vagy egyszerűen zárt) kör működik, amelyekhez az Ingress-en keresztül lehet hozzáférni.
Forgalomelosztás
Támogatja-e a vezérlő az olyan gyakran használt forgalomelosztási mechanizmusokat, mint a kanáriváltoztatások (canary), A/B-tesztelés, forgalom tükörzése (mirroring/shadowing)? Ez valóban fájdalmas téma az alkalmazások számára, amelyek pontos és precíz forgalomkezelést igényelnek a termék teszteléséhez, termékhibák debuggolásához (vagy minimális veszteségek mellett), a forgalom elemzéséhez stb.
Fizetős előfizetés
Van-e fizetős verzió a vezérlőből, kiterjesztett funkciókkal és/vagy technikai támogatással?
Grafikus felület (Web UI)
Van-e valamilyen grafikus felület a vezérlő konfigurációjának kezelésére? Főként a „könnyebb használat” érdekében és/vagy azok számára, akik módosításokat kívánnak végrehajtani az Ingress konfigurációban, de kényelmetlen a „nyers” sablonokkal dolgozni. Hasznos lehet, ha a fejlesztők kísérleteket szeretnének végezni a forgalommal.
JWT-érvényesítés
Beépített JSON web-tokenek ellenőrzésének megléte a felhasználói alkalmazás hitelesítésére és érvényesítésére.
Konfiguráció testreszabási lehetőségek
A sablonok bővíthetősége abban az értelemben, hogy mechanizmusokat tartalmaz, amelyek lehetővé teszik saját direktívák, zászlók stb. hozzáadását a standard konfigurációs sablonokhoz.
Alapvető védelmi mechanizmusok a DDoS ellen
Egyszerű sebességkorlátozó algoritmusok, vagy bonyolultabb megoldások, amelyek a forgalom szűrésére szolgálnak címek, fehérlisták, országok stb. alapján.
Kérésnyomozás
Megfigyelési, nyomon követési és hibakeresési lehetőségek az Ingress-től egyes szolgáltatások/pod-okhoz, és ideális esetben a szolgáltatások/pod-ok közötti nyomon követésre is.
WAF
Támogatás .
Ingress vezérlők
A vezérlők listája az alábbiak alapján készült és . Néhányat a specifikussága vagy kis elterjedtsége (korai fejlesztési szakasz) miatt kizártunk a betekintésből. A fennmaradókat alább tárgyaljuk. Kezdjük az általános megoldások leírásával, és folytatjuk egy összefoglaló táblázattal.
Ingress a Kubernetes-től
Weboldal:
Licenc: Apache 2.0
Ez a Kubernetes hivatalos vezérlője, amelyet a közösség fejleszt. A nevéből egyértelműen kiderül, hogy nginx alapú, és kiegészítették különböző Lua bővítményekkel, amelyeket további lehetőségek megvalósítására használnak. Az nginx népszerűsége és a néhány minimális módosítás miatt, amikor vezérlőként használják, ez a verzió a legkönnyebben érthető és konfigurálható középkategóriás mérnök számára (webes tapasztalattal).
Ingress az NGINX Inc-től
Weboldal:
Licenc: Apache 2.0
Az nginx fejlesztőinek hivatalos terméke. Fizetős verzióval rendelkezik, amelyen alapul. A fő elképzelés a magas stabilitás, a folyamatos visszafelé kompatibilitás, mindenféle külső modul hiánya és a hivatalos vezérlőhöz képest elért fokozott sebesség (amelyet a Lua elhagyásával értek el).
A ingyenes változat jelentősen korlátozott, még a hivatalos vezérlőhöz képest is (a Lua modulok hiánya miatt). A fizetős változat ezzel szemben elég széleskörű kiegészítő funkciókkal rendelkezik: valós idejű metrikák, JWT-érvényesítés, aktív állapotellenőrzések és mások. Fontos előnye az NGINX Ingress-szel szemben a TCP/UDP forgalom teljes körű támogatása (és a közösségi verzióban is!). Hátrány — a forgalom elosztásának funkcióinak, ami azonban "maximális prioritást élvez a fejlesztők számára", de időt igényel a megvalósításhoz.
Kong Ingress
Weboldal:
Licenc: Apache 2.0
A Kong Inc. által kifejlesztett termék, két változatban: kereskedelmi és ingyenes. Az nginx alapjain készült, amelynek lehetőségeit sok Lua modul bővíti.
Eredetileg API-kérések feldolgozására és irányítására volt orientálva, azaz API Gateway-ként működött, azonban mára teljes értékű Ingress-vezérlővé vált. Fő előnyök: számos kiegészítő modul (többek között harmadik féltől származó fejlesztők által is) könnyen telepíthető és konfigurálható, amelyeken keresztül széles spektrumú kiegészítő lehetőségek valósíthatók meg. Azonban az alapfunkciók már számos lehetőséget kínálnak. A munka konfigurálása CRD-erőforrások segítségével történik.
A termék fontos jellemzője — egy konténer keretei között való működés (a cross-namespaced helyett) vitatott téma: valakinek hátrányként tűnhet (mivel entitások tömkelegét kell létrehozni minden konténerhez), míg másnak előnyként (bóiztosítva van a nagyobb szintű elszigeteltség, mivel ha egy vezérlő meghibásodik, a probléma egyetlen konténerre korlátozódik).
Traefik
Weboldal:
Licenc: MIT
Proxy, amelyet eredetileg a kérések irányítására terveztek mikroszolgáltatások és dinamikus környezetük számára. Innen következik számos hasznos lehetőség: konfiguráció frissítés teljes újraindítás nélkül, rengeteg terheléselosztási módszer támogatása, webes felület, metrika továbbítása, különböző protokollok támogatása, REST API, kanáris kiadások és még sok más. Kellemes jellemzője, hogy a Let’s Encrypt tanúsítványok támogatása natívan be van építve. Hátránya, hogy a magas rendelkezésre állás (HA) megvalósításához a vezérlő saját KV-tárolót igényel.
HAProxy
Weboldal:
Licenc: Apache 2.0
A HAProxy régóta ismert proxyként és forgalomterhelés-elosztóként. A Kubernetes klaszter keretein belül a konfiguráció "lágy" frissítését (forgalomveszteség nélkül) kínálja, DNS alapú szolgáltatáskeresést, dinamikus konfigurálást API-n keresztül. A megoldás vonzó lehetősége a konfigurációs sablon teljes testreszabása, CM cseréjével és a Sprig könyvtár funkcionalitásának használatával. Összességében az alapvető hangsúly a gyors működésen, optimalizáltságon és a felhasználások hatékonyságán van. A vezérlő előnye a rekordmennyiségű különféle terheléselosztási mód támogatása.
Voyager
Weboldal:
Licenc: Apache 2.0
A HAProxy alapú vezérlő, amelyet univerzális megoldásként pozicionálnak, széleskörű lehetőségeket támogat számos szolgáltatónál. Lehetővé teszi a forgalom terheléselosztását L7 és L4 szinten, míg a TCP L4 forgalom terheléselosztása egyértelműen a megoldás egyik kulcsfontosságú funkciója.
Contour
Weboldal:
Licenc: Apache 2.0
Ennek a megoldásnak az alapját nemcsak az Envoy képezi: közösen készítették a népszerű proxy szerzőivel. Fontos jellemzője a forgalom Ingress erőforrásainak CRD erőforrásokon keresztüli kezelése. Az olyan szervezetek számára, ahol több fejlesztőcsapat dolgozik egy klaszteren, ez segít maximalizálni a forgalom kezelésének biztonságát a szomszédos kontúrokban, és megvédi őket az Ingress erőforrások módosításából eredő hibáktól.
Egy kiterjesztett terheléselosztási módszerek készlete is elérhető (tartalmazza a kérés tükörözést, automatikus újrapróbálkozásokat, kérés rate-limitinget és sok mást), részletes forgalomfigyelés és hibafigyelés. Lehetséges, hogy néhányak számára jelentős hátrányt jelent a sticky sessions támogatásának hiánya (bár a munka ).
Istio Ingress
Weboldal:
Licenc: Apache 2.0
Egy átfogó service mesh megoldás, amely nemcsak mint Ingress vezérlő működik a bejövő forgalom irányításában, hanem az egész klaszter keretein belül is kezeli a forgalmat. A háttérben, mint sidecar proxy minden szolgáltatás számára, az Envoy alkalmazás található. Valójában egy nagy kombájn, amely "mindent tud", és alapvető ötlete a maximális kezelhetőség, skálázhatóság, biztonság és átláthatóság. Segítségével finomra tudja hangolni a forgalom irányítását, a szolgáltatások közötti hozzáférés engedélyezését, terheléselosztását, figyelését, kanáris kiadásokat és még sok mást. Több információt az Istióról a "».
Ambassador
Weboldal:
Licenc: Apache 2.0
Egy másik Envoy alapú megoldás. Ingyenes és kereskedelmi verziók is rendelkezésre állnak. Olyan megoldásként pozicionálják, mint a "teljesen natív Kubernetes számára", ami megfelelő előnyöket biztosít (szoros integráció a K8s klaszter módszereivel és entitásaival).
Összehasonlító táblázat
Így a cikk csúcspontja ez az óriási táblázat:
Kattintható, hogy lehetővé tegye a részletesebb nézetet, és elérhető .
Összegzés
A cikk célja, hogy átfogóbb megértést nyújtson (bár nem teljeskörű!) arról, hogy melyik választást válassza az Ön konkrét esetében. Mint általában, minden vezérlőnek megvannak a maga előnyei és hátrányai…
A klasszikus Ingress a Kubernetestől jónak számít elérhetősége és megbízhatósága miatt, és elég gazdag funkciókban — általában véve, ez elég is szokott lenni. Azonban, ha a stabilitással, a funkciók szintjével és a fejlesztéssel kapcsolatban magasabb követelmények vannak, érdemes figyelmet fordítani az NGINX Plus-szal és előfizetéssel rendelkező Ingress-re. A Kong számos pluginnal rendelkezik (és így a biztosított funkciókkal), ráadásul a fizetős verzióban még több van belőlük. Széleskörű lehetőségeket kínál API Gateway-ként, dinamikus konfigurálásra CRD-erőforrások alapján, valamint az alap Kubernetes szolgáltatások számára.
Magasabb követelmények esetén a terheléselosztással és az engedélyezési módszerekkel kapcsolatban érdemes figyelni a Traefik-re és a HAProxy-ra. Ezek nyílt forráskódú projektek, amelyeket éveken át teszteltek, nagyon stabilak és aktívan fejlődnek. A Contour már pár éve jelen van, de még mindig fiatalnak tűnik, és csak az Envoy-ra épülő alapvető funkciókkal rendelkezik. Ha WAF használatára/védelmére van szükség az alkalmazás előtt, akkor érdemes figyelni a Kubernetes Ingress-re vagy a HAProxy-ra is.
A legfunkciógazdagabb termékek az Envoy alapú megoldások, különösen az Istio. Ez egy átfogó megoldásként jelenik meg, ami "mindent tud", ami viszont magasabb belépési küszöböt jelent a konfigurálásra/indításra/adminisztrációra, mint a többi megoldás.
Mi az Ingress-t választottuk standard vezérlőként, és ez még mindig használatban van, amely 80-90% -os igényt elégít ki. Elég megbízható, könnyen konfigurálható, bővíthető. Általában, specifikus követelmények hiányában, ez megfelelő a legtöbb klaszterhez/alkalmazáshoz. Hasonló univerzális és viszonylag egyszerű termékekként a Traefik-et és a HAProxy-t lehet ajánlani.
P.S.
Olvasson további információkat a blogunkban:
- „Vissza a mikroszolgáltatásokhoz az Istióval”: , , ;
- «»;
- «».
Forrás: habr.com
