Při nasazení clustera Kubernetes pro konkrétní aplikaci je důležité pochopit, jaké požadavky ta aplikace, podnik a vývojáři kladou na tento zdroj. S těmito informacemi lze přistoupit k architektonickému rozhodnutí, konkrétně k výběru konkrétního Ingress kontroléru, kterých dnes existuje velké množství. Abychom vytvořili základní představu o dostupných možnostech bez nutnosti studovat množství článků/dokumentace apod., připravili jsme tento přehled, který zahrnuje hlavní (produkčně připravené) Ingress kontroléry.
Doufáme, že pomůže kolegům při výběru architektonického řešení — alespoň poslouží jako výchozí bod pro získání podrobnějších informací a praktických experimentů. Předem jsme prozkoumali jiné podobné materiály na internetu a, světe div se, nenalezli jsme ani jeden více méně úplný, a především — strukturovaný — přehled. Tak pojďme tedy tento prostor zaplnit!
Kritéria
Aby bylo možné provést srovnání a získat nějaký užitečný výsledek, je třeba rozumět nejen předmětné oblasti, ale mít také konkrétní seznam kritérií, která nastaví směr výzkumu. Bez nároku na analýzu všech možných případů použití Ingress/Kubernetes jsme se snažili vyzdvihnout nejběžnější požadavky na kontroléry — buďte připraveni, že veškeré své specifické detaily budete muset studovat samostatně.
Ale začnu s charakteristikami, které se staly natolik běžnými, že jsou realizovány ve všech řešeních a není jich třeba řešit:
- dynamické objevování služeb (service discovery);
- SSL terminace;
- práce s websockety.
Nyní — o bodech srovnání:
Podporované protokoly
Jedním z klíčových kritérií pro výběr. Váš software může fungovat na nestandardním HTTP nebo vyžadovat práci s mnoha protokoly současně. Pokud je váš případ nestandardní, určitě vezměte tento faktor v úvahu, abyste se vyhnuli nutnosti pozdějšího přepracování clustera. U všech kontrolérů se seznam podporovaných protokolů liší.
Software v základu
Existuje několik variant aplikací, na kterých je postavený kontrolér. Obvyklé jsou nginx, traefik, haproxy, envoy. Obecně to nemusí příliš ovlivnit, jak se přijímá a předává provoz, nicméně je vždy užitečné znát potenciální nuance a vlastnosti toho, co se skrývá "pod kapotou".
Směrování provozu
Na základě čeho se rozhoduje o směrování provozu k určitému službě? Obvykle to jsou host a cesta, ale mohou existovat i další možnosti.
Jmenný prostor v rámci clustera
Jmenný prostor (namespace) — možnost logicky rozdělit zdroje v Kubernetes (například na stage, production atd.). Existují Ingress kontroléry, které je třeba nainstalovat zvlášť do každého jmenného prostoru (a pak může směrovat provoz pouze do podů tohoto prostoru). A existují takové (a ty jsou jasnou většinou), které fungují globálně na celý cluster — v nich je provoz směrován do jakéhokoli podu clusteru, bez ohledu na jmenný prostor.
Kontrola pro upstreamy
Jakým způsobem je zajištěno směrování provozu k zdravým instancím aplikace, služeb? Existují varianty s aktivními a pasivními kontrolami, opakovanými pokusy (retries), obvody přerušení (circuit breakers) (podrobněji o nich viz například ), vlastním implementacím kontrol zdraví (custom health checks) atd. Velmi důležitý parametr, pokud máte vysoké požadavky na dostupnost a včasné vyřazení nefungujících služeb z vyvažování.
Algoritmy vyvažování
Tady je mnoho variant: od tradičních po exotičtější, jako je , a také samostatné možnosti, jako .
Autentizace
Jaké autorizační schémata podporuje kontrolér? Basic, digest, oauth, external-auth — myslím, že tyto možnosti by měly být známé. To je důležitý kriterium, pokud se používá mnoho kontur pro vývojáře (a/nebo jednoduše uzavřených), přístup k nimž se realizuje přes Ingress.
Distribuce provozu
Podporuje kontrolér tak často používané mechanismy pro distribuci provozu, jako jsou canary deploy, A/B testování, zrcadlení provozu (mirroring/shadowing)? To je skutečně bolestivé téma pro aplikace, které vyžadují precizní a přesné řízení provozu pro produktové testování, ladění produktových chyb nikoli v boji (nebo s minimálními ztrátami), analýzu provozu atd.
Placené předplatné
Existuje placená varianta řadiče s rozšířenými funkčními možnostmi a/nebo technickou podporou?
Grafické uživatelské rozhraní (Web UI)
Existuje nějaké grafické uživatelské rozhraní pro správu konfigurace řadiče? Hlavně pro "pohodlí" a/nebo pro ty, kteří potřebují provést nějaké změny v konfiguraci Ingressu, ale práce s "syrovými" šablonami je nepohodlná. Může být užitečné, pokud vývojáři chtějí experimentovat s provozem na místě.
JWT validace
Přítomnost vestavěné kontroly JSON web tokenů pro autorizaci a validaci uživatele pro koncovou aplikaci.
Možnosti přizpůsobení konfigurace
Rozšiřitelnost šablon co do přítomnosti mechanismů, které umožňují přidávat vlastní direktivy, příznaky atd. do standardních šablon konfigurace.
Základní mechanismy ochrany proti DDOS
Jednoduché algoritmy pro omezení návštěvnosti nebo složitější možnosti filtrování provozu na základě adres, bílých seznamů, zemí atd.
Sledování dotazů
Možnosti sledování, monitorování a ladění dotazů od Ingressů k konkrétním službám/podům, ideálně také mezi službami/podmi.
WAF
Podpora .
Řadiče Ingress
Seznam řadičů byl sestaven na základě a . Některé z nich jsme vyloučili z přehledu vzhledem k jejich specifikům nebo malé rozšířenosti (rané fáze vývoje). Zbývající byly popsány níže. Začneme se všeobecným popisem řešení a pokračujeme shrnující tabulkou.
Ingress od Kubernetes
Web:
Licence: Apache 2.0
Toto je oficiální řadič pro Kubernetes, který vyvíjí komunita. Jak je z názvu zřejmé, je založen na nginx a doplněn různými sadami Lua pluginů, které se používají k implementaci dalších možností. Díky popularitě samotného nginx a minimálním modifikacím, které jsou potřeba při jeho používání jako řadiče, může být tato varianta nejjednodušší a nejvíce srozumitelná pro průměrného inženýra (s webovým zkušenostmi).
Ingress od NGINX Inc
Web:
Licence: Apache 2.0
Oficiální produkt vývojářů nginx. Má placenou verzi, která je založena na Hlavní myšlenkou je vysoká úroveň stability, stálá zpětná kompatibilita, absence jakýchkoli cizích modulů a deklarované zvýšení rychlosti (ve srovnání s oficiálním řadičem), dosažené díky odmítnutí Lua.
Bezplatná verze je značně ořezaná, včetně srovnání s oficiálním řadičem (kvůli absenci těch samých Lua-modulů). Placená verze má přitom dost širokou dodatečnou funkcionalitu: metriky v reálném čase, JWT-validaci, aktivní kontroly zdraví a další. Důležité výhody oproti NGINX Ingress — plná podpora TCP/UDP provozu (a to i ve community verzi!). Nevýhodou je, funkcí pro rozdělování provozu, což je však "prioritou pro vývojáře", ale vyžaduje čas na implementaci.
Kong Ingress
Web:
Licence: Apache 2.0
Produkt vyvíjený společností Kong Inc. ve dvou variantách: komerční a bezplatná. Je založen na nginx, jehož možnosti jsou rozšířeny velkým množstvím modulů na Lua.
Původně byl orientován na zpracování a směrování API požadavků, tj. jako API Gateway, avšak v současnosti se stal plnohodnotným Ingress kontrolerem. Hlavní výhody: mnoho dodatečných modulů (včetně těch od třetích stran), které se snadno instalují a konfiguruje a s jejichž pomocí lze realizovat širokou škálu dodatečných funkcí. Nicméně, vestavěné funkce již nabízejí mnohé možnosti. Konfigurace probíhá pomocí CRD zdrojů.
Důležitou zvláštností produktu je, že práce v rámci jednoho obrysu (namísto cross-namespaced) je sporným tématem: někomu se to může zdát jako nevýhoda (musí se vytvářet entity pro každý obrys), ale pro někoho jako funkce (vyšší úroveň izolace, protože pokud je jeden kontroler poškozen, je problém omezen jen na jeden obrys).oTraefik
github.com/containous/traefik
Web:
Licence: MIT
Proxy, který byl původně vytvořen pro efektivní směrování požadavků pro mikroslužby a jejich dynamické prostředí. Odtud také řada užitečných funkcí: aktualizace konfigurace bez restartování, podpora mnoha metod vyvažování, webové rozhraní, přenos metrik, podpora různých protokolů, REST API, kanárové vydání a mnohem více. Příjemným rysem je také podpora certifikátů Let’s Encrypt out-of-the-box. Nevýhodou je, že pro zajištění vysoké dostupnosti (HA) bude pro kontroler potřeba nainstalovat a připojit vlastní KV úložiště.
Dále klientský dotaz vcházel do HAProxy, které řešilo následující úkoly:
Web:
Licence: Apache 2.0
HAProxy je již dlouho znám jako proxy a vyvažovač provozu. V rámci Kubernetes clusteru nabízí "jemnou" aktualizaci konfigurace (bez ztráty provozu), objevování služeb na základě DNS a dynamickou konfiguraci pomocí API. Atraktivní může být plná přizpůsobitelnost šablon konfigurací pomocí nahrazení CM, stejně jako možnosti použití funkcí knihovny Sprig. Celkově se hlavní důraz této řešení klade na vysokou rychlost, optimalizaci a efektivitu v využívaných zdrojích. Výhodou kontroleru je podpora rekordního počtu různých metod vyvažování.
Voyager
Web:
Licence: Apache 2.0
Kontroler založený na HAProxy, který se prezentuje jako univerzální řešení, podporující široké možnosti na mnoha poskytovatelích. Nabízí možnosti pro vyvažování provozu na L7 a L4, přičemž vyvažování TCP L4-provozu lze považovat za jednu z klíčových funkcí řešení.
Contour
Web:
Licence: Apache 2.0
Toto řešení bylo vyvinuto nejen s využitím Envoy: společně s autory tohoto populárního proxy. Důležitou vlastností je schopnost oddělit správu zdrojů Ingress pomocí CRD zdrojů IngressRoute. Pro organizace s množstvím vývojových týmů, které používají jeden cluster, to pomáhá maximálně zabezpečit práci s provozem v sousedních obvodech a chránit je před chybami při změnách zdrojů Ingress.
K dispozici je také rozšířená sada metod vyvažování (včetně zrcadlení požadavků, automatických opakování, omezení rychlosti požadavků a mnoha dalších), podrobný monitoring toku provozu a výpadků. Pro někoho může být významnou nevýhodou absence podpory sticky sessions (i když práce ).
Istio Ingress
Web:
Licence: Apache 2.0
Komplexní řešení service mesh, které není jen Ingress kontrolerem spravujícím příchozí provoz zvenčí, ale také kontroluje veškerý provoz v rámci klastru. „Pod kapotou“ je jako sidecar proxy pro každou službu použit Envoy. V podstatě se jedná o velký kombinátor, který „může vše“, a jeho hlavní myšlenkou je maximální spravovatelnost, rozšiřitelnost, zabezpečení a transparentnost. Pomocí něj můžete podrobně nastavovat směrování provozu, autorizaci přístupu mezi službami, vyvažování, monitoring, kanárkové vydání a mnohé další. Více o Istio si můžete přečíst v sérii článků „».
Ambassador
Web:
Licence: Apache 2.0
Další řešení založené na Envoy. Má bezplatné a komerční verze. Představuje se jako „plně nativní pro Kubernetes“, což přináší odpovídající výhody (úzká integrace s metodami a entitami klastru K8s).
Srovnávací tabulka
Takže, vyvrcholením článku je tato obrovská tabulka:
Je klikací pro možnost podrobnějšího zobrazení a také je dostupná ve formátu .
Shrňme to
Cílem článku je poskytnout komplexnější porozumění (ale rozhodně ne vyčerpávající!) tomu, jakou volbu učinit ve vašem konkrétním případě. Jak už to bývá, každý kontroler má své výhody a nevýhody...
Klasický Ingress od Kubernetes je dobrý svou dostupností a prověřeností, dostatečně bohatými funkcemi – obecně by měl "stačit na oči". Pokud však existují zvýšené požadavky na stabilitu, úroveň funkcí a vývoj, stojí za to zaměřit se na Ingress s NGINX Plus a placeným předplatným. Kong má velmi bohatou sadu pluginů (a tím pádem také vlastností, které poskytují), přičemž v placené verzi je jich dokonce ještě víc. Nabízí široké možnosti pro fungování jako API Gateway, dynamickou konfiguraci na základě CRD zdrojů, a také základní služby Kubernetes.
Při vyšších požadavcích na vyvažování a metody autorizace se podívejte na Traefik a HAProxy. Jsou to projekty Open Source, které byly prověřeny léty, jsou velmi stabilní a aktivně se vyvíjejí. Contour je na trhu už pár let, ale stále vypadá příliš mladě a má pouze základní funkce přidané nad Envoy. Pokud máte požadavky na existenci/integraci WAF před aplikací, stojí za to se podívat na Ingress od Kubernetes nebo HAProxy.
Nejbohatší na funkce jsou produkty postavené na Envoy, zejména Istio. Představuje komplexní řešení, které "může všechno", což však znamená také výrazně vyšší prah pro konfiguraci/spuštění/administraci než u jiných řešení.
Jako standardní ovladač jsme vybrali a stále používáme Ingress od Kubernetes, který pokrývá 80—90% potřeb. Je dostatečně spolehlivý, snadno se konfiguruje a rozšiřuje. V obecném případě, při nepřítomnosti specifických požadavků, by měl vyhovovat většině clusterů/aplikací. Z podobně univerzálních a relativně jednoduchých produktů bych doporučil Traefik a HAProxy.
P.S.
Přečtěte si také náš blog:
- „Zpět k mikroslužbám s Istio“: , , ;
- «»;
- «».
Zdroj: habr.com
