Infrastruktúra, ami
ma stabil, holnap is az marad

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

Múlt kedden az egyik Go szolgáltatásom egy nap alatt 14 Dependabot PR-t kapott. Ugyanahhoz az egy CVE-hez tartoztak, de a mi futó kódunkat valójában nem érintették. Ettől még végig kellett nézni az alertet, reviewzni a PR-eket, megvárni a CI-t, majd mergelni. Itt döntöttem el, hogy ebben a folyamatban nálunk ennyi volt a Dependabot. Mi volt az utolsó csepp A konkrét eset a CVE-2026-26958 volt a filippo.io/edwards25519 modulban. A sebezhetőség a (*Point).MultiScalarMult metódust érintette, amit a legtöbb projekt nem hív. A javítás is pici volt. Ennek ellenére a Dependabot rengeteg PR-t nyitott Go repókban, még olyanokban is, ahol csak a modul más részeit használták. ...

A múlt héten elveszítettem egy 45 perces Codex sessiont, mert a hüvelykujjam hozzáért egy tab bezáró gombjához. Semmi figyelmeztetés. Semmi megerősítő ablak. Csak eltűnt. A session kontextusa, a gondolatmenet és az addig felépített iteratív finomítások egyetlen rossz kattintás miatt elszálltak. Ha dolgoztál már AI coding agentekkel (Codex, Claude Code, Cursor, bármi), valószínűleg ismerős ez az érzés. Ezek az eszközök beszélgetés közben építik a kontextust. Ha ez menet közben elvész, az nem csak idegesítő, hanem komoly idő- és energiaveszteség. ...

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

Múlt hónapban jött az Artifactory megújítás: 40%-kal drágább, mint tavaly. Semmi új feature amit használnánk, csak a szokásos “enterprise tier” szorítás. Vulnerability scanning? Fizess többet. Replikáció? Fizess többet. SSO ami nem csak SAML? Na, találd ki. Két hetet szántam rá, hogy lecseréljem. Ez lett belőle — mi működött, mi nem, és milyen csapdák vannak amiket senki nem említ. Amit Futtatunk Az Artifactory-nk ezt kezelte: Docker image-ek (~800 image, ~12TB összesen) npm csomagok (privát registry, ~200 belső csomag) Helm chartok Generikus binárisok (build outputok, firmware blob-ok) A fő követelmények: vulnerability scan push-ra, OIDC SSO, és cross-region replikáció a DR site-ra. ...

Az open source közösséghez való hozzájárulás olyan, mintha egy virtuális társadalomban szereznél állampolgárságot. Így néz ki ez belülről.

Ha Kubernetes-t uzemeltetek az EU-ban, a NIS2 ram is vonatkozik. Az iranyelvek 2024 oktobere ota hatalyosak, es a tagallamok azota ultetik at a nemzeti jogba. Az elmult honapokban tobb klasztert is atneztem megfeleles szempontbol, es ebbol osszeraktam, mi az, ami tenyleg szamit a gyakorlatban. Ez nem jogi elemzes. Inkabb az a technikai checklista, amit en is sokkal hamarabb szerettem volna kezbe kapni. Mit jelent a NIS2 K8s uzemeltetoknek (roviden) A NIS2 boviti az eredeti NIS iranyelv hatalyat. Ha a ceg, ahol dolgozom, “alapveto” vagy “fontos” szervezetnek minosul (energia, kozlekedes, egeszsegugy, digitalis infrastruktura es meg sok mas), akkor tudnom kell igazolni: ...

Múlt hónapban végre rendesen megnéztem a GPU kihasználtsági dashboardot. Amit láttam, az fizikailag rosszul esett: 14 darab A100-as a klaszterben, átlagos kihasználtság 15% körül. Olyan hardverért fizettünk, ami az ideje nagy részében semmit sem csinált. Ez kínosan gyakori jelenség. A csapatok kérnek egy teljes GPU-t olyan workloadhoz, ami 20 perces training burst-öknél használja, aztán órákig üresen áll. A Kubernetes integer erőforrásként kezeli a GPU-kat — vagy van egy egész, vagy nincs. Natívan nincs megosztás. ...

Ezt a félreértést rendszeresen látom csapatoknál. Beállítanak CPU limitet, az app elkezd furán viselkedni, és mindenki azt nézi, hogy újraindult-e a pod. Nem indul újra. Az a memóriás sztori. A CPU limit nem öli meg a podot, hanem fojtja. Throttling lesz belőle. És ez a különbség sokkal fontosabb, mint elsőre tűnik. A félreértés Sokan így gondolkodnak: Memória limit túllépve → pod meghal (OOMKill) ✅ CPU limit túllépve → pod meghal ❌ Az első igaz. A második nem. A hivatalos Kubernetes dokumentáció teljesen egyértelmű: ...

A múlt héten pont belefutottam egy klasszikus szívásba: podok kerültek olyan node-okra, ahol a CNI plugin még nem állt készen. Ismerős helyzet. A node feljön, a kubelet szerint Ready, aztán a pod szépen beragad ContainerCreating állapotban, mert a Calico még matat a háttérben. Ezt én is kerülgettem már mindenféle init containeres és postStart-os trükkel. Aztán szembejött velem a Node Readiness Controller a Kubernetes blogon. Ez egy friss SIG projekt (v0.1.1), és pont azt adja, ami rég hiányzott: egyedi readiness kapuk node-okhoz, deklaratívan, CRD-vel. ...