Kubernetes

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

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

Detecting Kubernetes Nodes Running Only DaemonSet Pods, A Deep Dive A real-world story about PromQL struggles, Helm templating, alert design, and operational savings by Dedico Servers. Executive Summary At Dedico Servers, we specialize in building efficient, cost-optimized Kubernetes clusters. In this article, we engineer a Prometheus-based alert to detect nodes running only DaemonSet pods, an operational and financial risk. By tackling this hidden inefficiency, we help our clients save thousands of dollars annually while improving the resilience of their clusters. ...

Managing Kubernetes applications with ArgoCD is already a game-changer, but what if you need to deploy the same app across 10 clusters, or generate dynamic app configs based on Git branches or Helm values? That’s where ApplicationSets step in. 🚀 What is an ApplicationSet? An ApplicationSet is a Kubernetes custom resource that tells ArgoCD how to automatically generate multiple Application resources from a template. It’s like templating your ArgoCD apps, letting you define how they should be generated and where they should go. ...