Kubernetes

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: ...

Múlt héten örököltem egy klasztert, amin nagyjából 40 mikroszerviz futott. Observability gyakorlatilag nem volt: alap Prometheus metrikák és pár elszórt logsor. A csapat “a következő sprintre” akart distributed tracinget. Két hét alatt, tucatnyi repót érintve, kódmódosítással? Teljesen irreális. Ezért az OpenTelemetry Operator auto-instrumentációját választottam. Ez történt a gyakorlatban. A kiindulás Kubernetes 1.31 fut EKS-en. A cél egyszerű volt: trace-ek és metrikák minden szervizből Grafana Tempóba és Mimirbe, alkalmazáskód-módosítás nélkül. A szervizek vegyesek voltak: Python (FastAPI), Node.js (Express), Go, és pár Java Spring Boot alkalmazás. ...

Nagyjából két éve üzemeltetünk olyan klasztereket, ahol ML training jobok futnak a sima service-ek mellett. A legfájóbb pont mindig az ütemezés volt. Egy elosztott trainingből pár pod elindult, a többi meg Pendingben ragadt, közben a GPU-k csak vitték a pénzt. A Kubernetes 1.35 múlt héten jött ki, ezért a hétvégén rászántam az időt, és végigteszteltem stagingen. Több újdonság is olyan, amit tényleg vártam. Gang Scheduling, Végre A legnagyobb változás a workload-aware scheduling, benne a gang scheduling támogatással. Ez még alpha, tehát productionbe most még nem raknám be, de az irány nagyon jó: egy podcsoport vagy együtt ütemeződik be, vagy sehogy. ...

Nehany Kubernetes klasztert uzemeltetek bare metalon, Cluster API-val es BYOH (Bring Your Own Host) providerrel. Eddig minden upgrade ugyanarra a forgatokonyvre epult: node drain, machine torles, ujraprovisionalas, varakozas. Mukodik, de 40+ node es szuk tartalek kapacitas mellett ez brutal lassu. A Cluster API v1.12 par hete jelent meg, es nekem az in-place update volt a legfontosabb ujdonsag. Nem kell minden valtozasnal uj gepeket epiteni, bizonyos modositasok mehetnek a mar futo machine-okra is. A mult heten ezt teszteltem a staging klaszterunkon, es meglepoen jo eredmenyt kaptam. ...

Tegnap kijött a Kyverno 1.17, a lényeg pedig az, hogy a CEL-alapú policy típusok mostantól GA státuszúak. Ha eddig JMESPath-os ClusterPolicy erőforrásokkal dolgoztál, készülj. Hivatalosan deprecated-ek, és a v1.20-ban (2026 október) kikerülnek. Ma egy teljes napot rászántam egy éles cluster migrálására, amiben kb. 60 szabályzat volt. Így nézett ki a gyakorlatban. Miért fontos ez? A Kyverno évek óta JMESPath kifejezéseket használ. Működnek, de Kyverno-specifikusak. A CEL (Common Expression Language) az, amit maga a Kubernetes is használ a ValidatingAdmissionPolicy-hoz az 1.30-as verzió óta. A CEL-re váltással a Kyverno igazodik az upstreamhez, és érezhetően jobb teljesítményt kap. ...