Devops

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

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

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

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