Čo po ingress-nginx-controlleri? Traefik ako záchrana existujúcich Ingress konfigurácií
Kubernetes sa za posledné roky stal štandardom pre prevádzku moderných cloudových aplikácií. Ponúka automatizáciu, škálovateľnosť, prenositeľnosť medzi prostrediami a rozsiahly ekosystém nástrojov.
Jeho rýchly vývoj však môže byť v konzervatívnejších produkčných prostrediach problémom. Menia sa API, komponenty sa označujú ako deprecated a niektoré projekty postupne končia. Organizácie tak musia meniť riešenia, ktoré ešte donedávna fungovali bez problémov.
Dobrým príkladom je situácia okolo ingress-nginx-controllera.
Keď spoľahlivý komponent prestane byť samozrejmosťou
Ingress controller patrí medzi kľúčové komponenty Kubernetes infraštruktúry. Rozhoduje o tom, ako sa externý používateľ alebo systém dostane k aplikáciám bežiacim v Kubernetes.
Typická cesta požiadavky vyzerá takto:
Internet → Ingress Controller → Kubernetes Service → aplikácia
Preto jeho výmena nie je len nahradením jedného softvéru iným. Súvisí priamo s dostupnosťou, bezpečnosťou a konfiguráciou aplikácií.
Používatelia ingress-nginx navyše často využívajú množstvo NGINX annotations pre redirecty, timeouty, limity požiadaviek, veľkosť requestov či ďalšie parametre routingu. V multitenantnom prostredí tak môžu existovať stovky až tisíce Ingress manifestov spravovaných rôznymi tímami a zákazníkmi.
Otázka teda znie: čo s nimi, ak už nechceme alebo nemôžeme pokračovať s pôvodným ingress controllerom?
Dve očividné možnosti – ani jedna ideálna
Prvou možnosťou je migrácia na Kubernetes Gateway API.
Gateway API predstavuje modernejší spôsob konfigurácie sieťovej komunikácie v Kubernetes a pracuje napríklad s objektmi Gateway, GatewayClass
alebo HTTPRoute.
Technicky ide o správny smer. V multitenantnom prostredí však migrácia znamená zmeny konfigurácií aplikácií, testovanie, koordináciu s viacerými tímami a postupné nasadenie.
Pre infraštruktúrneho architekta je to projekt. Pre projektového manažéra to môže byť veľmi dlhý projekt.
Druhou možnosťou je pokračovať s existujúcim controllerom bez ďalších aktualizácií. To je síce prevádzkovo jednoduchšie, ale iba do chvíle, kým sa neobjaví bezpečnostná zraniteľnosť.
Prevádzkovať komponent vystavený internetu bez bezpečnostných opráv nie je riziko, ktoré chcete dlhodobo akceptovať.
Prečo nestačí jednoducho vymeniť NGINX za iný ingress controller?
Pretože samotný Kubernetes Ingress je iba časť konfigurácie.
Veľká časť správania ingress-nginx je definovaná pomocou annotations špecifických pre NGINX, napríklad:
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: "100m"
nginx.ingress.kubernetes.io/proxy-read-timeout: "300"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
Nový ingress controller týmto anotáciám nemusí rozumieť.
Výsledkom môže byť manifest, ktorý je syntakticky validný a aplikácia na prvý pohľad funguje, no správa sa inak než pred migráciou. Takéto rozdiely sa často prejavia až pri konkrétnych typoch požiadaviek alebo vyššej záťaži.
Automatická konverzia? Technicky zaujímavá, prevádzkovo riskantná
Uvažovali sme aj nad vlastným mutating controllerom, ktorý by existujúce Ingress konfigurácie automaticky transformoval na zdroje Gateway API.
Teoreticky elegantné riešenie, prakticky však pridáva ďalšiu vrstvu logiky do kritického miesta, ktoré rozhoduje o expozícii aplikácií.
Controller by musel správne interpretovať rôzne kombinácie annotations a garantovať funkčne ekvivalentné správanie. Pri chybe v routingu pritom môže byť výsledkom nedostupná služba alebo nesprávne exponovaná aplikácia.
Pre produkčné prostredie sme preto hľadali konzervatívnejšiu cestu.
Traefik ako prechod medzi dvoma svetmi
Po testovaní viacerých možností sme ako application proxy zvolili Traefik.
Traefik je moderný cloud-native reverse proxy navrhnutý pre dynamické prostredia, kontajnery a Kubernetes. Pre nás však bola rozhodujúca najmä možnosť minimalizovať zásahy do existujúcich konfigurácií a zároveň pripraviť prostredie na postupný prechod ku Gateway API.
V nami testovaných scenároch bolo možné zachovať existujúci spôsob práce s Ingress konfiguráciami vrátane potrebného správania naviazaného na súčasné manifesty bez toho, aby sme museli naraz meniť všetky aplikácie.
Namiesto migrácie typu:
„V deň D musia všetci zákazníci prejsť na nový spôsob konfigurácie.“
môžeme použiť model:
„Najskôr bezpečne vymeníme infraštruktúrny komponent a aplikácie budeme migrovať postupne.“
To je z prevádzkového pohľadu zásadný rozdiel.
Ingress dnes, Gateway API zajtra
Veľkou výhodou Traefiku je možnosť pracovať s viacerými spôsobmi konfigurácie routingu.
To umožňuje vytvoriť prechodné obdobie, počas ktorého môžu v jednom Kubernetes prostredí existovať:
- existujúce aplikácie používajúce Ingress,
- nové aplikácie využívajúce modernejšie mechanizmy,
- a postupne aj služby postavené na Gateway API.
Nemusíte teda robiť „big bang“ migráciu.
Staršie aplikácie môžu zostať dočasne bez zmien, zatiaľ čo nové služby už vznikajú podľa cieľovej architektúry.
Postup migrácie môže vyzerať napríklad takto:
Z technickej migrácie sa tým stáva kontrolovaný evolučný proces.
Prečo je to dôležité najmä v multitenantnom prostredí
V jednom clustri, ktorý spravuje jeden DevOps tím a desať aplikácií, môže byť kompletná migrácia relatívne jednoduchá.
Situácia je úplne iná, keď platformu používajú desiatky tímov alebo zákazníkov.
Každý môže mať:
- vlastný release cyklus,
- inú technologickú úroveň,
- rozdielne požiadavky na dostupnosť,
- vlastné Ingress konfigurácie,
- špecifické annotations,
- alebo aplikácie, ktorých konfiguráciu nie je možné okamžite meniť.
Platformový tím preto nemôže vždy jednoducho oznámiť:
,,Od budúceho mesiaca prestávame podporovať Ingress. Prepíšte si všetky manifesty."
Technicky je to možné. Organizačne často nie.
Práve preto má kompatibilita počas prechodného obdobia takú vysokú hodnotu.
Modernizácia bez revolúcie
Gateway API podľa nás predstavuje správny smer ďalšieho vývoja Kubernetes networkingu. To však neznamená, že všetko založené na klasickom Ingress musí byť okamžite prepracované.
V enterprise prostredí nie je cieľom používať najnovšie API za každú cenu. Cieľom je prevádzkovať služby bezpečne, stabilne a predvídateľne a zároveň mať realistickú cestu k modernejšej architektúre.
Traefik nám umožnil oddeliť dve rozhodnutia, ktoré by inak museli prísť naraz:
- nahradiť existujúci ingress controller,
- postupne prejsť z Ingress na Gateway API.
Práve rozdelenie jednej veľkej a rizikovej migrácie na viac menších krokov môže byť najdôležitejším architektonickým rozhodnutím.
Záver
Pri migrácii ingress vrstvy sme hľadali riešenie, ktoré splní tri základné požiadavky:
bezpečnosť, spätnú kompatibilitu a možnosť postupnej modernizácie.
Traefik nám umožnil minimalizovať okamžité zmeny na strane aplikácií a zákazníkov a zároveň pripraviť cestu k postupnému využívaniu Gateway API.
A presne tak podľa nás majú vyzerať dobré infraštruktúrne migrácie.
Nie ako jednorazová revolúcia, pri ktorej musíte naraz zmeniť celý ekosystém, ale ako kontrolovaná evolúcia, počas ktorej zostáva produkcia stabilná.
