Kubernetes

Március 25-én ébredtem egy Slack üzenetre a security csapattól: “Az ingress-nginx tegnaptól EOL. Mi a terv a migrációra?” Hónapok óta halogattam. A nyugdíjazást még 2025 novemberében bejelentették, de messzinek tűnt. Most viszont valóság lett. Nincs több CVE patch. Nincs több hibajavítás. Az óra ketyeg. Mi történt pontosan március 24-én a Kubernetes SIG Network és a Security Response Committee hivatalosan nyugdíjazta az ingress-nginx-et. A projekt lezárult. A container image-ek és Helm chartok elérhetők maradnak (nem törölnek semmit), de új release nem lesz. Ha holnap jön egy kritikus sebezhetőség, magadra vagy utalva. Ez nem egy deprecation warning, amit három release-en át ignorálhatsz. Ez azt jelenti, hogy a karbantartók elmentek. ...

Minden csapat saját klasztert akart. A QA-nak kellett egy, a staging-nek egy, minden fejlesztő akart egyet feature branch-enként. Végül 12 EKS klaszterünk lett, a legtöbb 15%-os kihasználtsággal, és mind pénzbe került. Régóta hallottam a vCluster-ről a Loft Labs-tól, de mindig elnapoltam. Három hónapja végre kipróbáltam. Az ígéret túl szépnek tűnt: teljes Kubernetes klaszterek egyetlen host klaszteren belül, saját API szerverrel, saját erőforrásokkal, teljes izolációval. Extra node-ok nélkül, extra control plane-ek kezelése nélkül. ...

A múlt héten belefutottam abba, hogy a Kubernetes projekt csendben újraírta az image promotert, vagyis azt az eszközt, ami a hivatalos image-eket feltolja a registry.k8s.io alá. Nem is maga az átírás volt az érdekes, hanem az, hogy az új verzió már rendes SLSA provenance tanúsítványokat és cosign aláírásokat ad az image-ekhez minden tükörnél. Ezen a ponton be kellett vallanom magamnak valamit: a saját image-eimet már jó ideje aláírom CI-ben, de a klaszter oldalon semmit nem kényszerítettem ki. Az aláírás ott volt, csak éppen senki nem nézte. Szóval végre rászántam magam, és rendbe tettem. ...

Két évig én voltam az a fickó, aki adatbázisokat provizionál. Minden hétfő reggel ugyanaz a Slack üzenet: “Hé, kéne egy Postgres a new service-hez.” Megnyitottam a Terraformot, másolás, három változó átírása, plan, approval, apply. Húsz perc az életemből, el. Szorozd meg négy csapattal, és érezni fogod. Aztán beüzemeltem a Crossplane-t Compositions-szel, és most a fejlesztők maguk csinálják egyetlen YAML fájllal. Íme, hogyan jutottam el idáig, és mi tört el közben. ...

Múlt héten hajnali 2-kor kaptam riasztást egy payment service-re, ami eldobálta a kéréseket. Az első ösztönöm ugyanaz volt, mint mindig: elő a cluster-admin kubeconfig-gal a csapat wiki oldaláról, aztán nézzük, mi van. Tíz perc alatt megtaláltam a hibát, de másnap reggel a security csapat jelezte, hogy az audit logokban ott virít a session-öm. Jogosan. Az a “temporary” cluster-admin kubeconfig nagyjából nyolc hónapja volt használatban. Szóval végre nekiültem és összeraktam egy rendes debugging workflow-t. Olyat, ami pontosan annyi hozzáférést ad az ügyeletesnek, amennyire szüksége van, pontosan annyi időre, amennyire kell. ...

Múlt hónapban hajnali 2-kor csörgött a telefonom, mert egy éles cluster API szervere elkezdett timeoutolni. A podok nem schedulálódtak, a kubectl csak lógott, a Slack csatorna pedig addigra teljesen elszabadult. Úgy fél óra múlva jutottam el oda, hogy megint az etcd volt a hibás. Az etcd minden Kubernetes cluster közepén ott van, szóval ha neki rossz napja van, azt az egész rendszer megérzi. Pont ez benne a kellemetlen: az etcd hibái ritkán egyértelműek. Szinte soha nincs egy tiszta jelzés arról, hogy “na igen, ez most biztosan etcd”. Inkább olyan tüneteket látsz, mint a lassú API hívások, a késő scheduling vagy a furcsa timeoutok. Elég sok ilyen incidensen vagyok túl ahhoz, hogy legyen egy saját rövid ellenőrzőlistám, és mostanában az etcd-diagnosis sokat segít abban, hogy gyorsabban jussak a lényeghez. ...

A múlt hét nagy részét azzal töltöttem, hogy image pull hibákat vadásztam egy multi-tenant klaszterben. Végül kiderült, hogy a gond a privát registry mirrorunk körül van. Pull-through cache-ként használtuk, de a credentialök node szinten voltak beállítva. Az egyik csapat rotálta a saját hozzáférését, aztán rövid időn belül három másik namespace podjai is elkezdtek hibázni. Ekkor vált teljesen világossá, hogy megosztott credentialökkel próbálunk együtt élni. Innen jutottam el a CRI-O credential provideréhez registry mirrorokhoz. Miután összeraktam, elég nehéz lenne visszamenni a korábbi megoldáshoz. ...

Elegem lett abból, hogy a Grafanához, ArgoCD-hez, Harborhoz és minden más belső toolhoz külön loginokat kelljen kezelnem. Minden új csapattag öt fiók létrehozását jelentette. Minden offboarding azt, hogy reménykedtem, mindegyiket visszavontam. Szóval végre leültem és felraktam a Keycloak-ot a Kubernetes klaszterünkre. Ez az, ami tényleg történt, nem a megszépített verzió. Miért Keycloak Megnéztem a Dex-et, az Authelia-t és a Keycloak-ot. A Dex könnyű, de korlátozott, ha többre van szükséged, mint OIDC proxy. Az Authelia egyszerű setupokra kiváló, de a mi use case-ünkhöz kevés volt. A Keycloak nehezebb, viszont kezeli az OIDC-t, SAML-t, user federation-t, és van rendes admin UI-ja. Egy csapatnak, ami 8+ belső service-t futtat, a súlya indokolt. ...

Ezt a migrációt túl sokáig tologattam. Valahányszor szóba került a Gateway API, mindig ugyanazt mondtam: “igen, rajta van a listán.” Aztán múlt héten végre nem csak beszéltem róla, hanem meg is csináltam: három production clustert átvittem Ingressről Gateway API-ra. Őszintén, hamarabb kellett volna meglépnem. Miért most vágtam bele A végső lökést egy multi-tenant cluster adta, ahol két csapat ugyanazt a domaint használta, de eltérő TLS viselkedésre volt szükségük. Klasszikus Ingress-szel ez nagyon gyorsan kaotikus lesz. Jönnek a controller-specifikus annotation-ök, és simán előfordul, hogy az egyik csapat változtatása elrontja a másik routingját. ...

Két éve futtatom a Falcót runtime securityre a legtöbb klaszteremen. Tette a dolgát, de a kernelmodulos megközelítés mindig törékenynek érződött. Minden kernel frissítésnél benne volt a pakliban, hogy valami eltörik. Amikor a Cilium Tetragon elérte az 1.3-as stabil verziót, tisztán eBPF alapon, kernel modul nélkül, úgy döntöttem, élesben is adok neki egy esélyt. Ez történt. Miért váltottam a Falcóról A Falco jó eszköz, félreértés ne legyen. De újra és újra ugyanazokba a problémákba futottam: ...