Při spouštění clusteru Kubernetes pro konkrétní aplikaci musíte pochopit, co pro tento prostředek představuje samotná aplikace, firma a vývojáři. S těmito informacemi se můžete pustit do architektonického rozhodování a zejména výběru konkrétního Ingress controlleru, kterých je dnes již velké množství. Abyste si udělali základní představu o dostupných možnostech, aniž byste museli procházet množství článků/dokumentace atd., připravili jsme tento přehled včetně hlavních (výrobně připravených) regulátorů Ingress.
Doufáme, že pomůže kolegům při výběru architektonického řešení – minimálně se stane východiskem pro získání podrobnějších informací a praktických experimentů. Dříve jsme na netu studovali další podobné materiály a kupodivu jsme nenašli jedinou víceméně kompletní a hlavně – strukturovanou – recenzi. Pojďme tedy vyplnit tuto mezeru!
kritéria
Aby bylo možné provést srovnání a získat jakýkoli užitečný výsledek, musíte v zásadě porozumět nejen oblasti předmětu, ale také mít konkrétní seznam kritérií, která určí vektor výzkumu. Aniž bychom předstírali, že analyzujeme všechny možné případy použití Ingress / Kubernetes, pokusili jsme se zdůraznit nejobecnější požadavky na controllery – připravte se, že v každém případě budete muset všechna svá specifika a podrobnosti nastudovat samostatně.
Ale začnu charakteristikami, které se staly tak známými, že jsou implementovány ve všech řešeních a nejsou brány v úvahu:
- dynamické zjišťování služeb (objevování služeb);
- ukončení SSL;
- práce s websockety.
Nyní ke srovnávacím bodům:
Podporované protokoly
Jedno ze základních výběrových kritérií. Váš software nemusí fungovat na standardním HTTP nebo může vyžadovat práci na více protokolech najednou. Pokud je váš případ nestandardní, nezapomeňte vzít tento faktor v úvahu, abyste později nemuseli znovu konfigurovat cluster. U všech řadičů se seznam podporovaných protokolů liší.
software v jádru
Existuje několik variant aplikací, na kterých je regulátor založen. Populární jsou nginx, traefik, haproxy, envoy. V obecném případě to nemusí mít velký vliv na to, jak je provoz přijímán a přenášen, ale vždy je užitečné znát potenciální nuance a vlastnosti toho, co je „pod kapotou“.
Směrování dopravy
Na základě čeho je možné se rozhodnout o směru provozu na konkrétní službu? Obvykle jsou to hostitel a cesta, ale existují další možnosti.
Jmenný prostor v rámci clusteru
Namespace (namespace) - možnost logického rozdělení zdrojů v Kubernetes (například na scéně, produkci atd.). Existují řadiče Ingress, které musí být instalovány samostatně v každém jmenném prostoru (a pak mohou řídit provoz pouze do lusků tohoto prostoru). A jsou takové (a jejich jasná většina), které fungují globálně pro celý cluster – v nich je provoz směrován do libovolného modulu clusteru bez ohledu na jmenný prostor.
Vzorky pro upstreamy
Jak je provoz směrován do zdravých instancí aplikace, služeb? Existují možnosti s aktivními a pasivními kontrolami, opakování, jističe (Podrobnější informace viz např. ), vlastní realizace zdravotních prohlídek (vlastní zdravotní prohlídky) atp. Velmi důležitý parametr, pokud máte vysoké požadavky na dostupnost a včasné odstranění neúspěšných služeb z balancování.
Algoritmy vyvažování
Existuje mnoho možností: od tradičních do exotiky , stejně jako jednotlivé funkce jako .
Ověřování
Jaká autorizační schémata ovladač podporuje? Basic, digest, oauth, external-auth – myslím, že tyto možnosti by měly být známé. Toto je důležité kritérium, pokud existuje mnoho vývojářských (a/nebo jen soukromých) smyček, které jsou přístupné přes Ingress.
Rozložení dopravy
Podporuje kontrolér takové běžně používané mechanismy distribuce provozu, jako je kanárkové zavádění (canary), testování A/B, zrcadlení provozu (zrcadlení / stínování)? Toto je opravdu bolestivé téma pro aplikace, které vyžadují přesné a přesné řízení provozu pro produktivní testování, ladění chyb produktu off-line (nebo s minimální ztrátou), analýzu provozu a tak dále.
Placené předplatné
Existuje placená možnost ovladače s pokročilými funkcemi a / nebo technickou podporou?
Grafické uživatelské rozhraní (Web UI)
Existuje nějaké GUI pro správu konfigurace řadiče? Hlavně pro "šikovnost" a/nebo pro ty, kteří potřebují provést nějaké změny v konfiguraci Ingress'a, ale práce s "raw" šablonami je nepohodlná. Může to být užitečné, pokud chtějí vývojáři provádět nějaké experimenty s provozem za běhu.
JWT validace
Přítomnost vestavěné validace webových tokenů JSON pro autorizaci a validaci uživatele do koncové aplikace.
Možnosti přizpůsobení konfigurace
Rozšiřitelnost šablon ve smyslu mechanismů, které vám umožňují přidávat vlastní direktivy, příznaky atd. do standardních konfiguračních šablon.
Základní ochranné mechanismy DDOS
Jednoduché algoritmy omezení rychlosti nebo složitější možnosti filtrování provozu na základě adres, seznamů povolených, zemí atd.
Vyžádejte si sledování
Schopnost monitorovat, sledovat a ladit požadavky z Ingresses na konkrétní služby / pody a ideálně také mezi službami / pody.
WAF
Podpora .
Ovladače
Seznam kontrolorů byl vytvořen na základě и . Některé z nich jsme z přehledu vyloučili kvůli specifičnosti nebo nízké prevalenci (rané stadium vývoje). Zbytek je diskutován níže. Začneme obecným popisem řešení a pokračujeme souhrnnou tabulkou.
Ingress od Kubernetes
Webové stránky:
Licence: Apache 2.0
Toto je oficiální ovladač pro Kubernetes a je vyvíjen komunitou. Z názvu je zřejmé, že je založen na nginx a je doplněn jinou sadou Lua pluginů používaných k implementaci dalších funkcí. Vzhledem k popularitě samotného nginx a jeho minimálním úpravám při použití jako kontroléru může být tato možnost nejjednodušší a nejsnadněji konfigurovatelná pro průměrného inženýra (se zkušenostmi s webem).
Ingress od NGINX Inc.
Webové stránky:
Licence: Apache 2.0
Oficiální produkt vývojářů nginx. Má placenou verzi založenou na . Hlavní myšlenkou je vysoká úroveň stability, konstantní zpětná kompatibilita, absence jakýchkoliv cizích modulů a deklarovaná zvýšená rychlost (ve srovnání s oficiálním ovladačem), dosažená díky odmítnutí Lua.
Bezplatná verze je výrazně omezena, a to i ve srovnání s oficiálním ovladačem (kvůli nedostatku stejných modulů Lua). Ten placený má zároveň poměrně širokou doplňkovou funkcionalitu: metriky v reálném čase, validaci JWT, aktivní kontroly stavu a další. Důležitou výhodou oproti NGINX Ingress je plná podpora TCP/UDP provozu (a to i v komunitní verzi!). Mínus - funkce distribuce návštěvnosti, která však „má pro vývojáře nejvyšší prioritu“, ale její implementace vyžaduje čas.
Kong Ingress
Webové stránky:
Licence: Apache 2.0
Produkt vyvinutý společností Kong Inc. ve dvou verzích: komerční a zdarma. Založeno na nginx, který byl rozšířen o velké množství Lua modulů.
Zpočátku byl zaměřen na zpracování a směrování API požadavků, tzn. jako API Gateway, ale v tuto chvíli se stal plnohodnotným Ingress controllerem. Hlavní výhody: mnoho doplňkových modulů (včetně modulů od vývojářů třetích stran), které se snadno instalují a konfigurují a s jejichž pomocí je implementována široká škála doplňkových funkcí. Vestavěné funkce však již nabízejí mnoho možností. Konfigurace úlohy se provádí pomocí prostředků CRD.
Důležitá vlastnost produktu - práce v rámci stejné kontury (místo cross-namespaced) je kontroverzní téma: pro někoho to bude vypadat jako nevýhoda (musíte pro každou konturu vyrobit entity), pro někoho je to vlastnost ( bоVyšší úroveň izolace, např pokud je jeden ovladač rozbitý, pak je problém omezen na samotný obvod).
Traefik
Webové stránky:
Licence: MIT
Proxy, který byl původně vytvořen pro práci se směrováním požadavků pro mikroslužby a jejich dynamické prostředí. Proto mnoho užitečných funkcí: aktualizace konfigurace bez restartu vůbec, podpora velkého množství balancovacích metod, webové rozhraní, předávání metrik, podpora různých protokolů, REST API, verze canary a mnoho dalšího. Další příjemnou funkcí je podpora certifikátů Let's Encrypt ihned po vybalení. Nevýhodou je, že aby bylo možné uspořádat vysokou dostupnost (HA), ovladač bude muset nainstalovat a připojit vlastní úložiště KV.
HAProxy
Webové stránky:
Licence: Apache 2.0
HAProxy je dlouho známý jako proxy a vyvažovač provozu. Jako součást clusteru Kubernetes nabízí „měkkou“ aktualizaci konfigurace (bez ztráty provozu), zjišťování služeb na základě DNS, dynamickou konfiguraci pomocí API. Atraktivní může být úplné přizpůsobení konfigurační šablony nahrazením CM, stejně jako možnost používat v ní funkce knihovny Sprig. Obecně je hlavní důraz řešení kladen na vysokou rychlost, její optimalizaci a efektivitu ve spotřebovávaných zdrojích. Výhodou regulátoru je podpora rekordního počtu různých způsobů vyvažování.
Cestovatel
Webové stránky:
Licence: Apache 2.0
Založeno na ovladači HAproxy, který je umístěn jako univerzální řešení, které podporuje širokou škálu funkcí u velkého počtu poskytovatelů. Nabízí se příležitost pro vyvážení provozu na L7 a L4 a vyvážení TCP L4 provozu jako celku lze nazvat jednou z klíčových vlastností řešení.
Obrys
Webové stránky:
Licence: Apache 2.0
Toto řešení není založeno pouze na Envoy: bylo vyvinuto společností společně s autory této oblíbené proxy. Důležitou funkcí je možnost oddělit řízení zdrojů Ingress pomocí prostředků IngressRoute CRD. Organizacím s mnoha vývojovými týmy používajícími stejný cluster to pomáhá maximalizovat bezpečnost práce s provozem v sousedních smyčkách a chránit je před chybami při změně prostředků Ingress.
Nabízí také rozšířenou sadu balancovacích metod (je zde zrcadlení požadavků, automatické opakování, omezení rychlosti požadavků a mnoho dalšího), podrobné sledování toku provozu a poruch. Možná pro někoho bude významnou nevýhodou nedostatek podpory pro lepivé relace (i když práce ).
Istio Ingress
Webové stránky:
Licence: Apache 2.0
Komplexní řešení service mesh, které není pouze Ingress kontrolérem, který spravuje příchozí provoz zvenčí, ale také řídí veškerý provoz v rámci clusteru. Pod kapotou se Envoy používá jako zástupce postranního vozíku pro každou službu. V podstatě se jedná o velký kombajn, který „umí cokoliv“ a jeho hlavní myšlenkou je maximální ovladatelnost, rozšiřitelnost, bezpečnost a transparentnost. S ním můžete doladit směrování provozu, autorizaci přístupu mezi službami, vyvažování, monitorování, kanárková vydání a mnoho dalšího. Přečtěte si více o Istio v sérii článků "".
Velvyslanec
Webové stránky:
Licence: Apache 2.0
Další řešení založené na Envoy. Má bezplatné a komerční verze. Je umístěn jako „plně nativní pro Kubernetes“, což přináší odpovídající výhody (těsná integrace s metodami a entitami clusteru K8s).
srovnávací tabulka
Takže vyvrcholením článku je tato obrovská tabulka:
Lze na něj kliknout pro bližší zobrazení a je k dispozici také ve formátu .
Shrnout
Účelem tohoto článku je poskytnout úplnější pochopení (avšak v žádném případě ne vyčerpávající!), jakou volbu zvolit ve vašem konkrétním případě. Jako obvykle má každý ovladač své výhody a nevýhody…
Klasický Ingress od Kubernetes je dobrý svou dostupností a osvědčeností, dostatečně bohatými funkcemi - v obecném případě by měl „stačit pro oči“. Pokud však existují zvýšené požadavky na stabilitu, úroveň funkcí a vývoj, měli byste věnovat pozornost Ingress s NGINX Plus a placeným předplatným. Kong má nejbohatší sadu zásuvných modulů (a podle toho i příležitosti, které poskytují) a v placené verzi je jich ještě více. Má dostatek příležitostí pracovat jako API Gateway, dynamickou konfiguraci založenou na zdrojích CRD a také základní služby Kubernetes.
Se zvýšenými požadavky na metody vyvažování a autorizace se podívejte na Traefik a HAProxy. Jedná se o Open Source projekty, osvědčené léty, velmi stabilní a aktivně se rozvíjející. Contour je venku už pár let, ale stále vypadá příliš mladě a má jen základní funkce přidané nad Envoy. Pokud existují požadavky na přítomnost / vložení WAF před aplikací, měli byste věnovat pozornost stejnému Ingress od Kubernetes nebo HAProxy.
A nejbohatší na funkce jsou produkty postavené na Envoy, zejména Istio. Zdá se, že jde o komplexní řešení, které „umí cokoliv“, což však také znamená výrazně vyšší vstupní práh pro konfiguraci / spuštění / správu než jiná řešení.
Jako standardní ovladač jsme zvolili a stále používáme Ingress od Kubernetes, který pokrývá 80-90 % potřeb. Je poměrně spolehlivý, snadno se konfiguruje a rozšiřuje. Obecně platí, že při absenci specifických požadavků by měl vyhovovat většině clusterů/aplikací. Ze stejných univerzálních a relativně jednoduchých produktů lze doporučit Traefik a HAProxy.
PS
Přečtěte si také na našem blogu:
- "Zpět na mikroslužby s Istio": , , ;
- «";
- «".
Zdroj: www.habr.com