Kubernetes - Ki hogy kezeli?

Közösségi kerekasztal

Kb masfel , egy eve kezdtem el behatobban foglalkozni Kubernetes-el (elotte otthon Docker volt, illetve munkaban Swarm )

Azt irnam le, jelenleg hogyan zajlik a managent. Illetve erdekel, ki hogy csinalja, hatha okulok belole ... :)

  • A cluster K3s (3 node) , foleg az miatt, mert azert nem akkora deploymentrol beszelunk, ami indokolna a K8s-t vagy hasonlot
  • Storage  az Longhorn, gondolkodtam a shared storage en is, de vegul ennel maradtam

 

Amit managementre hasznalok:

  • Gitlab, integralt Flux-al, ez minden deploy alapja (SSOT ugye)
  • A "gyari" appok Helm el vannak deployolva, amit nem enged a gyari chart, ott Flux kustomization, siman manifest.yaml bol
  • Sajat fejesztesu appok Manifest.yaml bol mennek. itt nem lattam ertelmet Helm chart nak, mert igazabol nem valtoznak annyit, hogy legyen ertelme (az image tag is kb ugyanaz mindig, prod, test, dev...)
  • Helm Dashboard read only modban, mert szepen lehet kovetni a frissiteseket, illetve user def. value-t tesztelni is jo.
  • Altalanos managementre (pl pod konzol, logok etc...) Headlamp. Itt meg gondolkodom a read only-n, de egyelore meg csak en managelem, szoval most meg irni is tud.

 

Kb ennyi az amit en erdekesnek talalok, erdekel a ti management felepitesetek is! (foleg a kisebb clustert managelok, a brutal, tobb clusteres K8s az nem az en user case-em :) )

  • 2613 megtekintés

( asm v | 2026. 02. 20., p – 16:13 )

k9s appot mindenkepp probald ki, erdemes a hotkey-eket betanulni es akkor szazszor gyorsabb mint barmilyen webes tool

( kallaics | 2026. 02. 20., p – 16:39 )

Nem pontosan értem mi itt a kérdés. A K3s eléggé behatárolja a használható Kubernetes komponenseket. 

A hozzáférés vezérlés a Kubernetes role-ok segítségével szokás szabályozni. Kezelni én a K9s-t használom, mert egyszerű. GUI-s programból Dunát lehet rekeszteni, tehát ott ki kell választani kettőt vagy hármat és végig tesztelni, hogy neked mennyire áll kézre.

Hálózat terén a nagyok épp kidobják a Kubenetet, mert nem bírják a NAT eszközeik a terhelést és jelentősen olcsóbb így az üzemeltetés.

Amit még csinálni lehetne a CPU és memória igényeket beállítani a deploymenteknek.

Lehet még játszani azzal, hogy melyik node-ra, hogy ossza el podokat. Affinity, TopogySpreadConstraints. Ez növelheti a rendelkezésre állást, ha egy node kiesik.

A shared storage akkor érdekes, ha rajta tárolt adatok fontosak ha a pod másik node-on indul újra. Ha stateless microservice-ket futtatsz, akkor nem fontos a shared storage.

Ha optimalizálni szeretnéd a clustert, akkor "popeye" nevű tool a barátod. https://popeyecli.io/ 
Másik hasonló tool a Kubent: https://github.com/doitintl/kube-no-trouble

( Sixday v | 2026. 02. 20., p – 17:16 )

Jelenleg az industry standard megoldás kubernetes managementre az ArgoCD, legtobbszor Helm-el.

Full gitops, drift detection es state enforcement (valaki megbuzeral valamit a clusteren kezzel azt azonnal visszaallitja), teljes realtime UI (K8S objektumok, logok, console access, stb.) jogosultságkezeléssel, metrics, events, notifications, stb.
Mivel full gitops igy a git kotelezo meglete mint kozponti adatforras azonnal megold egy csomo jogosultsagkezelesi, auditalasi es uzemeltetesi problemat (pl. codeowners, git history, rollback).
Nagyszeru tool, tenyleg elkepeszto hatekonysagnovekedest es uzemeltetesi minosegjavulast eredmenyez.

A storage es a K8S alapvetoen nem a legjobb baratok mert a full dinamikusan valtozo podok es node-ok sok problemat tudnak szulni a gepteto alatt.
Rengeteg uzemeltetoi mernokorat tud felemeszteni a persistence management nagyobb kornyezetben.

Alapvetoen az a javaslat hogy ha stabil, megbizhato es alacsony mernoki ora koltsegu K8S kornyezetet akar valaki akkor celszeru a stateless alkalmazasok kikenyszeritese a fejlesztokbol, es kulso object storage (S3 es tarsai) es adatbazis megoldasokat kell hasznalni.

Ha muszaj a storage-ot K8S-en belul megoldani akkor pedig nagyon erosen javasolt kulonvalasztani a dinamikus, uzleti alkalmazasokat futtato clustert, es dedikalt, storage-ra fokuszalo clustert adni neki, ahol csak a redisek, kafkak, sql-ek, stb. futnak.
Itt jonnek be a kepbe az ugynevezett operatorok, halistennek mostanra minden komolyabb storage alkalmazasnak (redis, mysql, postgres, kafka, elastic, vault, etc.) van sajat hivatalos operatora.

Ez a cluster gyakorlatilag inkabb egy statikus kornyezet lesz, es igy a megfelelo ovatossaggal lehet eljarni a managelese soran.
Termeszetesen ilyenkor is ki kell "kenyszeriteni" a stateless viselkedest az uzleti appokbol, az uzleti clusteren nem szabad engedni in-cluster storage hasznalatat.
Ha a fejlesztok az alkalmazasukon belul maguknak probaljak meg ilyen-olyan modon megoldani a storage-et abbol egeszen biztosan egy rendszeresen felrobbano bomba lesz.

Jelenleg az industry standard megoldás kubernetes managementre az ArgoCD, legtobbszor Helm-el.

A Flux is ott van a mezőnyben, csak annyiból kevésbé preferálják, hogy annak nincs GUI-ja. Azt inkább olyan helyeken használják, ahol a deploymentnek a háttérben kell megtörténnie.

Ráadásul az ArgoCD nem csak GitOpsot támogat, hanem Helm Repository alapú deploymentet is, ahol a values jöhet ugyan Gitből, de akár fel is lehet tölteni a felületére.

Termeszetesen ilyenkor is ki kell "kenyszeriteni" a stateless viselkedest az uzleti appokbol, az uzleti clusteren nem szabad engedni in-cluster storage hasznalatat.

Ilyen, amikor a Kubernetes üzemeltetők álmodnak. Aztán fejbekólint a valóság a rengeteg legacy vagy legacy gyökerekkel rendelkező appal, amit szintén be "kell" költöztetni Kubernetesbe, részint mert ez a "buzzword" a management részéről, részint mert van előnye azért a kubernetes alapú működésnek még perzisztencia mellett is.

Alapvetően amúgy nem nagy ördöngősség a perzisztencia, ha jól van összerakva az infra. az a fontos, hogy a perzisztencia tényleges tárolója teljesen független legyen a Kubernetestől. Egy Ceph cluster pl vagy egy valamilyen dinamikusabb SAN megoldás. Ha minden node egyformán eléri ezt a storage-t, akkor a Kubernetes megoldja a perzisztencia kezelését.

Ráadásul most már az az "industry standard", hogy minden dobozos alkalmazás alapértelmezetten hozza magával a saját adatbázis szerverét, saját kis PgSQL, MySQL, stb és maximum külön konfigurációra hajlandó azt nem elindítani. Emiatt ezek el se indulnak sehogy sem egy olyan clusteren, ahol nincs értelmes StorageClass erre a célra. És ennek is megvan a maga előnye: az alkalmazás meg tudja várni az indulással, míg az adatbázisa elérhetővé válik, nincs az, hogy a MySQL még bootol miközben az app már lockolná a séma verziókat tartalmazó táblát. Ezt külső SQL szerverrel egyrészt nem nagyon tudja megoldani infra oldalról (a fejlesztőkből pedig rendes adatbázis szerver kezelést "kikényszeríteni" - hát, sok sikert hozzá), másrészt ha találsz valami köztes megoldást (valami monitor service pollozza az SQL szervert hogy futik-e, és akkor vált ready-be, ha futik), az meg egy +1 függőség valamilyen megoldástól.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Akkor én most elmormolok egy imát és hálát adok az égieknek hogy ezt eddig sikerült mindig kitaposnunk az üzletből.

Venném is elő a baltát egyből azokon a meetingeken ahol valami kutyafüle dobozos szoftver megköveteli tőlem K8S-ben a saját mysql-jét és anélkül nem lenne hajlandó elindulni.
Ha nem lehet benne az adatbázist remote-ra konfigurálni az azért valljuk be a nevetségesség felsőkategóriája, olyan szoftvert nem veszünk.

Szerencsére ilyenkor a DBA-k is azonnal erős Devops támogató partnerré válnak, mert rohadtul eszük ágában sincs tartani a hátukat valami random szoftver random dbjének mentéséért, konfigurációjáért, frissítéséért.  :)
Mert mint tudjuk a dobozos szoftverhez van support meg szerződés, de amikor beszarik a cucc mindig a beosztottakat veszi azonnal elő a vezetés hogy rögvest oldják meg, mert a support általában csak alapvető hülyeségeket kérdezget órákon át mire végre valaki elkezd érdemben foglalkozni a problémával a második eszkaláció után, de addigra meg a lead tech Kumar mar hazament, szóval lehet várni még egy fél napot :)))))

Ha meg már megvették az "okosok" akkor deploy és kész, ha meg összeszarja magát akkor megkapja az üzemeltetéstől a plecsnit hogy nem a mi cuccunk, beszéljetek a vendorral.
Általában 2-3 leállás után ahol a support hozza a szokásos formáját (lásd fentebb :)), meg szokott változni a vezetőség hozzáállása és jön a "hmm lehet ez a szoftver mégsem olyan jó nekünk" :)

---

Egyébként alapvetően ugyanazt mondjuk, hogy a perzisztencia ne legyen semmi estere sem az üzleti K8S-ben.

Most hogy éppen arról van szó hogy másik K8S-ben futnak a db-k amit én mondtam, vagy amit te mondasz hogy a K8S szintjén csak a logikai perzisztencia létezik és a cluster worker node-oknak a világon semmi köze hozzá mert Ceph-ben vagy valami SAN-on van, az már végül is mindegy, a lényeg ugyanaz.

Amit nem szabad semmiképpen sem (és úgylátom ebben egyetértünk), az hogy a K8S worker node-ok saját storage-ját nem szabad persistent tárolásra használni.
Az a tökéletes recept arra hogy nagyon nagy baj legyen előbb-utóbb.

Az szokott a gond lenni, amkor elővezeted, hogy oké, hogy itt ez a szoftver, de Postgres 9-cel érkezik, erre van support, tehát akkor szeretnénk kérni egy 9-es clustert a rendszerbe. Na akkor befelhősödik a DBA-k szeme, és elkezdenek csúnyán beszélni. Nem is értem, miért :D

Most nyilván sarkítok, de néhány dobozos (ingyenes és fizetős) cuccnak is olyan elképesztő igényei vannak, hogy csak nézel, hogy ez ugyan miért?! Meg miért nem újabb? És jobb esetben csak így nincs válasz, rosszabb esetben meg kipróbálod újabbal (nyiván playground környezetben) és szétrohad az egész a rákba. Nem tudom melyik a rosszabb valójában.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Amúgy már ott elbuktad hogy a szoftvered single postgresre supportált, clusterre nem.
Ezeket a taknyokat kubernetesre lift and shift módszerrel lehet migrálni, tudomásul kell venni hogy ugyanúgy egy darab adatbázis instance-al fog futni.

Ugye a postgrest nem raktátok be a kubernetes alá?!

Ha GUI-ra vágyik akkor Flux Enterprise verziója talán ad valamit, vagy ArgoCD. Évek óta használok Flux-ot és az első volt, amit körülnézés után ignoráltam az a GUI volt. Igaz közben már a k9s-t használtam párhuzamosan, így a Flux dolgait is ott nézegettem egy idő után. A parancssor meg mindenre is jól ki van találva Flux-ban. 

Aki GUI-ra vágyik annak ott az ArgoCD. Az ArgoCD-t pont a vizualizációja miatt preferálják sokan. Ezzel az ArgoCD rámutatott a Kubernetes egy problémájára, mégpedig a szegmentálódásra. Az egy erőforrás alá tartozó erőforrásokat nehéz lehet átlátni,  együtt kezelni meg még inkább problémás. Gondolok itt akár egy folyamatos LOG-ra, amelyben minden érintett resource látszik egyszerre minden varázslat (külső központi naplózás) nélkül.

A fejlesztőktől (leginkább kóderektől) hallom gyakran, hogy nekik GUI kell mindenhez is. Tapasztalat azt mutatta eddig, hogy egy jó fejlesztő ugyanolyan jól bánik a parancssorral, mint a GUI-val. (Persze a GUI néha kényelmesebb lehet ez nem vitás.)

+1

 

Nalunk is reszben a fejlesztok miatt van csak GUI. Amugy ugye mi Headlamp-ot hasznalunk, ami sztm egy tok jo atmenet a GUI es a CLI kozott. igazabol szinte alig van benne "nyomjmeggomb" az egesz egy strukturalt text editor ra emlekeztet inkabb... (pl nincs drain node gomb mint pl Portainer nel , hanem ugyanugy yaml ba kell beirni mit szeretnel)

 

Headlamp ala van amugy Flux plugin , ha az ember "gui szeru valamit" akar, teljesen hasznalhato.

 

https://fluxcd.io/ecosystem/#flux-plugin-for-headlamp

 

Illetve pl en Flux file Edit-re VSCode ot hasznalok , uh interfesz max akkor kell ha valami nem faxa...  (VScode ala is van Flux Extension azzal is lehet szepen reconcile-ozni, szal a tenyleges gui tenyleg ritkan kell....)

Azert esett a valasztas a Flux-ra mert a gitlab mar adott volt, aztan ugy voltam vele, hogy az ArgoCD tul robosztus nekem.... Amugy ez a resz sztm szepen teszi a dolgat, lenyegeben VScode ban egy push&sync es minden megy a maga utjan :)

 

De koszonom, ha egyszer "szintetlepek" biztos megnezem az ArgoCD-t

( hrgy84 | 2026. 02. 20., p – 18:22 )

Nálunk 2 cluster van, FluxCD, GitLab, főleg kozolos megoldások, most dolgozunk házon belül egy webes felületen, ami passzol az igényeinkhez (minden felületnek amit néztünk, van valami hiányossága, ami nekünk kellene, de nem akarunk 4-5 különböző eszközt használni). A networking Cilium, a storage Ceph RBD.

Ami most még kinéz, hogy be kell vezetnünk ilyeneket, hogy Trivy Operator, illetve az API váltás miatt cserélnünk kell az Ingress Controllereket valami Gateway-es izére.

Otthoni / egy node-os clusterhez szerintem amúgy az ArgoCD bőven jó, meg amiket felsorolátl az mind jó. Amit esetleg javaslok megnézésre, az a Prometheus Operator, és ehhez kapcsolódóan a Grafana. Segít telesítménymetrikákat gyűjteni a clusterről, ha esetleg valamelyik alkalmazással elszaladna a ló (a Kubernetes resource managementje tök fasza, hogy ellövi meg restartolja a pod-ot, csak ez akkor nem sokat segít, amikor valami miatt kétpercenként restartol a pod, vagy historikus infó kellene).

Amit még javaslok, hogy a saját alkalmazásokat is írd át Helm Chartra. Abszolút nem bonyolult, és nem is kell, hogy a Chart túl sűrűn változzon. Viszont egyrészt gyakorlod a dolgot egy low risk feladaton, másrészt sokkal egyszerűbb lesz deployolni, ha valahova máshova is kell esetleg, vagy költöztetni kell, stb.

Én pl azt csinálom, hogy van az alkalmazásomnak egy lokális docker-compose fájla, a gépemen így indul, ebben benne van minden fontosabb konfig, és amikor olyan állapotba kerül, hogy már Kubernetesbe raknám ki, akkor AI segítséggel legeneráltatok egy Helm Chartot a docker-compose -ból, átnézem, átjavítom a sablonokat és mehet is ki. Amennyire én látom, az Argo/FluxCD is kényelmesebben érzi magát Helm Chartokkal. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Szubjektív: én nem szeretem a check-mk-t. Anno világ összes erőforrása oda lett adva alá (16 vCPU, 64GB RAM), be is lett alá tolva 500db host, csoportok, mérések, minden beállítva.
Aztán amikor úgy tűnt, hogy talán használható lesz, megállt mint a szög, és senki nem tudta helyre rakni.
De hogy haszna is legyen a hozzászólásnak: én a Zabbix-ot ajánlom monitorozásra.

az API váltás miatt cserélnünk kell az Ingress Controllereket valami Gateway-es izére.

Az esetek 80%-ban nem nagy varazslat, valojaban az eddigi 2 resource-t (IngressClass + ingress) szetkaptak 3 darabba (gatewayClass + gateway + httproute). 

Itt van az official migration tool: https://github.com/kubernetes-sigs/ingress2gateway

amik ugye trukkosek, azok a controller szintu beallitas modositasok (max packet size, stb.).

( ricpet | 2026. 02. 20., p – 20:15 )

Sajat fejesztesu appok Manifest.yaml bol mennek. itt nem lattam ertelmet Helm chart nak, mert igazabol nem valtoznak annyit, hogy legyen ertelme (az image tag is kb ugyanaz mindig, prod, test, dev...)

Szerintem igenis megéri a saját appot is helm chartból kirakni. Főleg azért, amit említesz, hogy van prod, test stb. környezet, akkor két irányból kell a végső manifest yaml-t kezelni: egyrészt a környezetspecifikus dolgok, pl.: egyrészt prod-on nagyobb replica szám, másrészt meg ha valami új feature jön be az alkalmazásba, mondjuk kell neki egy új volume mount, akkor meg amiatt változik a yaml egy másik része. És akkor egy kicsit ott megállsz, hogy hogyan viszed a változtatást test-ről prod-ra: nem copy paste-elhetsz egyben, mert az egyik jellegű környzetei eltérésed üti a másikat. Helyette kézzel kell mazsolázgatni a különbségeket, és előbb-utóbb elrontod. A kustomization szinte biztos, hogy nem lesz elég.

A verziózott helm chart-okkal, és a nekik átadott környezetspecifikus value-kkal ez a probléma sokkal áttekinthetőbben elkerülhető.

 

Altalanos managementre (pl pod konzol, logok etc...) Headlamp. Itt meg gondolkodom a read only-n, de egyelore meg csak en managelem, szoval most meg irni is tud.

Amit szerintem kubernetesnél mindenképp érdemes megcsinálni, hogy a control plane authentikációja a céges IdP/SSO-hoz legyen federálva. Tehát ha megnyitod a dashboard-ot vagy headlamp-et, akkor az nem a saját belső serviceaccount-jának a jogosultságaival éri el a clustert, sőt nem is igazán kell nekik serviceaccount. Hanem te mint személy, ahogy megnyitod ezeket a dashboard-okat, a te jogosultságaid és céges csoporttagságaid alapján tehetsz vagy nem tehetsz meg valamit a kubernetesben, és ezt a control plane a céges SSO-tól származó identitásod alapján validálja.

És ezzel lehet olyat, hogy te írhatsz, mások csak olvashatnak. Vagy ami egy tipikus developer felállás, hogy mások csak bizonyos namespace-ekben élveznek full controlt, de a többi namespace-t csak olvashatják, kivéve mondjuk a secret-eket.

Koszi a tippeket!

Ahol kell, ott amugy Authentik-et hasznalok, LDAP backendel (ceges AD) a headlamp OIDC-t hasznal, ennek sajat RoleBinding van. magamnak most meg cluster admin, de a jovoben ezt is atgondlom, h szukseges-e ez.

A dev namespace ek el vannak szeparalva (network oldalon is) illetve a devek ezeket a nevtereket csak openziti-n keresztul erik el. (NIS2 eloiras volt nalunk tavaj a dev reszek teljes koru elszeparalasa)

( _Franko_ v | 2026. 02. 22., v – 10:58 )

Mi a célod? Mert az üzemeltethetetlenség határáig el lehet bonyolítani... :)

Van olyan cluster, ahol 4 GB memória nem elég a node alá, mert akkor még csak azok a cuccok futnak rajta, ami kell ahhoz, hogy egyéb pod fusson, mert van wiz, velero, hubble, kyverno, vpa-hpa, konnectivity, cilium, argocd, cert-manager, keda, traefik, opentelemetry, log-collector meg ilyen lófaszok és még semmid nem fut, de már tökig tele van pod-okkal... :)

Vagy onnan indulsz neki, hogy milyen problémát akarsz megoldani és akkor csak olyan csengettyűket meg habot teszel rá, ami kell a feladat megoldásához, mert nem buzzword vagy CV driven az architektúra.

https://iotguru.cloud

Gondolom mert drága, auto módban meg esetleg (attól függően, hogy a nem auto-mode clustered mennyire jól/dinamikusan állítottad be) még drágább. Az, hogy a legújabb fejlesztésekkel (a nyomorék etcd-t gyakorlatilag újraírták egy saját backenddel) jóval tovább skálázható, mint korábban, meg az auto móddal pár sor (IaC) kóddal csinálsz egy olyan clustert, ami a rárakott terhelés függvényében nő, vagy zsugorodik, megkeresve a terheléshez/beállításokhoz illeszkedő legjobb instance típust, integrálva egy csomó más AWS service-t (EBS, ALB stb) más kérdés. :D

Ha magadnak csinálod, olcsóbb, csak az időddel ne kelljen elszámolnod.

De mitol draga? $0.1/h = $72/mth per cluster. Nyilvan olcsobb on-prem kiadni egy kubeadm init-et, de hogy minden osszealljon, kell nehany szerver, storage, network, DB, ilyesmik + jonehany fos IT brigad. Nehany EKS clusterral + szamtalan managed szolgaltatassal egy szal DevOpsos is elboldogul. Ha igy szamolod a TCO-t, akkor igencsak az EKS fele billen a merleg.

Ha igy szamolod a TCO-t, akkor igencsak az EKS fele billen a merleg.

Lehet, hogy Magyarországon még mindig alacsonyak a bérek. :D

Feltételezem a gondolat az, hogy a TCO-ba beleszámolod az egyéb AWS költségeket is (compute, storage, network legalább), ezzel együtt már megállja a helyét, hogy az EKS drága. A control plane-nel önmagában nem sokra mész (ha meg saját (nem AWS) node-okat raksz rá, megint elmondhatod, hogy drága).

Ugy se draga. Ha csak 3 fos IT staff-ot szamolunk bele, fejenkent ~2M beren + sok millios szerver vasarlas (ami eletciklusa nagy reszeben underutilized lesz) + sok millios storage vasarlas (ami eletciklusa nagy reszeben underutilized lesz) + dual fabric network + backup + mindenfele support es licence koltsegek. Mindebbol irtozatosan sok compute+storage+network+db-t tudsz venni public cloudban. Es csak annyit es akkor kell venni, amit tenyleg felhasznalsz. Spot instance es egyeb serverless nyalanksagokrol nem is beszelve.

De ezt mar szazszor kitargyaltuk. Az a $72 kerekitesi hiba szokott lenni a havi cloud szamlaban, ellenben rengeteg mernokorat megsporol (outage-rol nem is beszelve) ...

A nagy cloud szolgáltatók nem olcsók, ha VM-eket használsz, és konstans terhelésed van. Aki így gondolkozik a "cloudba költözésen", az csalódni fog, legalábbis az anyagiakat illetően.

De ha az alkalmazás serverless architektúrában tud menni, esetleg fel-le skálázádó VM-eken tud futni, meg managelt szolgáltatásokat veszel igénybe, amivel mondjuk megspórolod a helyi kubernetes admin meg DBA árát, esetleg nem tudod, hogy egyáltalán a projekt több mint 3 hónapig fog-e élni, akkor vélhetően olcsóbb lesz, mint on-premise.

Meg behozom azt az aspektust is, hogy a DevOps/Cloud-os a munkaja talan nagyobbik reszen olyan dolgokkal foglalkozik, ami a "businesst" elore viszi (uj szolgaltatasokat allit be, deployol vmit vkinek, ilyesmik), mig a tradicionalis adminok (system, storage, network, DBA) tobbnyire azzal sportoltatjak magukat, hogy "ne essen szet" a szipi-szupi on-prem cluster. Nyilvan ez igy tulzas, de ertitek, egy managed cloudban ilyenekkel nem nagyon kell foglalkozni.

Pont ezt fizeti meg az ember az EKS $72/honap araval, hogy par kattintassal (par sor Terraform config) kapsz egy stabil Kubernetes clustert, ami "csak ugy" mukodik.

Nem vitatkozom ezzel. Főleg, hogy mivel API-okat hívogatsz, ezeket rendesen komponensekbe is tudod szervezni, azaz ha kell valakinek egy kubernetes cluster, mögötte egy adatbázissal, EBS-szel, S3-mal, utóbbi felmountolva ide-oda podokba, jogosultságkezeléssel (IAM), integrált load balancinggal, ingresszel, certekkel, DNS-sel, monitoringgal, na ez (ha megírtad a mögötte lévő kódot) egy sor, igények szerint felparaméterezve, és mehet a levesbe akármikor, ha már nincs rá szükség.

Ezeket saját magadnak összerakni major PITA. :D

egy managed cloudban ilyenekkel nem nagyon kell foglalkozni

Jaja, amikor a managed, teljesen elzárt control plane-ben elkezd haldokolni az etcd, akkor kell igazán nem foglalkozni vele, és felülni a repülőre valami távoli sziget felé. :)

elkezd haldokolni az etcd

Errol en is hallottam mar, de kesobb mindig kiderult, hogy nem az EKS onhibajabol tortent, hanem felraktak vmi operatort CRDstul ami (bug vagy felrekonfiguracio miatt) telefloodolta az etcd-t adattal, ami egyreszt jol leterhelte, masreszt a storage is megtelt (amivel az etcd restart se tud mit kezdeni vele). Ez valszeg az on-prem etcd-t is kicsinalta volna. Nyilvan ott tobb eszkozod van kijavitani a problemat.

De ezert tartunk Dev envet, ahol az experimental dolgokat hasznaljuk egy ideig es csak utana megy Prodba. Ezert en nem is vagyok az igazi CI/CD hive, miszerint minden menjen Prodba rogton, mert az ilyen side-effectek es egyeb instabilitas nem szokott felszinre jonni CI alatt.

Nyilvan fugg a workload jellegetol. Ha nem bitcoint banyasz/idojarast szimulal az ember 7/24, hanem barmi, kulso/belso ugyfelek fele torteno service-rol van szo, akkor annak van egy hullamzasa (ejszaka, hetvege, release, stb.), amit cloudban le lehet kovetni (auto-scaling vagy PAYG arazassal), es akkor a utilizationt 50% folott lehet tartani. Ezzel szemben on-prem nagyon hosszadalmas a HW beszerzes (ceges burokracia, kozbeszerzes, ilyesmik), ezert megvasaroljak 3-5 evre a saleses vagyalmokhoz meretezett szervereket+storage-ot. Na annak lesz 10% alatt utilizationje, felteve, ha nem dobjak a projektet egy ev utan.

Mas szemszogbol: brutalisan megnott a RAM ara az utobbi idoben. Ha valaki ezutan vesz szervert, az fizetheti az emelt koltseget. Ellenben az AWS EC2 arak nem valtoztak, ha jol tudom (csak nehany AI specikus instance-nak (trn*)).

Ha vki most bevasarol GPU-bol akarmilyen AI miatt, lehet hogy az a GPU tipus ertektelen lesz 1-2 even belul. Ez is egy riziko, amit figyelembe erdemes venni. Public cloudban meg csak atvaltasz egy ujabb instance-ra.

Nagyon csak a compute-ról beszélsz, de az AWS-ben a nagy biznisz nem azon van, hanem a kiegészítő (néha opcionális, máskor szükséges) szolgáltatásokon, ahol kicsiket/nagyokat fizetsz minden tranzakción, bájton.

Ellenben az AWS EC2 arak nem valtoztak, ha jol tudom

Még. Vannak már, akik elkezdték, és ezalól nyilvánvalóan az AWS sem lesz kivétel, csak mivel vsz. nekik a leghosszabb a futópálya (előre tervezés, beszerzés), lehet, hogy ők csak később ugranak fel a vonatra.

Konkretan mire gondolsz?

Nyilvan nem lattam sok ceg szamlajat, de azert tippre mindenkinel a compute (EC2), storage (EBS, EFS, S3), network (egress, cross-region, cross-AZ, LB, APIGW, CDN), DB (SQL+noSQL+cache) adja a szamla gerincet. Az ilyen Route53, KMS, CM, SQS, SNS filleres tetel szokott lenni. Nyilvan biztos van aki vmit overuse-ol (mondjuk TB-okat mozgat napi szinten regiok es/vagy AZ-k kozott), de akkor annak van celja, nem csak ugy sikeredett.

Talan a CloudWatch az egyetlen, amibe (by default) minden szolgaltatas szorja a logjait es metrikait, ezert "keretlenul" no a koltsege. De ez egy kis utanajarassal kikapcsolhato, nyilvan akkor ha van mas monitoring eszkozunk.

Az ilyen 5k$-os Enterprise support meg az, ami "csak ugy" fizetendo, de ha nem kell, akkor azt le lehet mondani.

Vannak már, akik elkezdték, és ezalól nyilvánvalóan az AWS sem lesz kivétel

En arra szamitok, hogy csak a latest gen. instance-ok (ami mar a draga RAMbol epult) ara fog noni, akinek nincs arra szuksege, hasznalhatja a regebbi [mcr][5-7][ai]. instance-okat valtozatlan aron. 

Konkrétan mindenre, elég érdekes dolgok derülnek ki, amikor megnézel egy ilyen millió dolláros havi számlát, amit a "cloud olcsó, a mérnök drága" szellemben hoz össze egy cég.

Csak hogy három példát mondjak: secrets manager, az általad is említett cloudwatch (elég egy default konfig, ami fossa bele az összes logot, ezzel könnyen összehoz napi 2000 dolláros számlát), vagy pld. az inspector, amit okosan bekapcsoltat a biztonsággal foglalkozó csapat, aztán senki sem nézi, illetve állítja be alaposan, és ez is havi többezer dollár.
És ezek még az egyszerűek.

A cloud addig "nem drága", amíg:

  1. nem használod
  2. beleteszed kb. ugyanazt (vagy több) a munkaórát a menedzselésébe, mint amit egy self-hosted megoldás menedzselésébe beletennél

De az ultimate kedvencem az, amikor beállítasz egy S3 bucketet saját használatra, de rátalál valami bot, és elkezdi kérésekkel szórni (persze mindre 403-at kap), és meglepődve tapasztalod (persze miután nem kevés pénzért beállítottad, hogy legyen logod is az eseményekről, amelyekből ezeket kitúrod), hogy ezek is párezer dollárba fájnak neked(*). Naponta.

*: ezt időközben nagy kegyesen "kijavította" az AWS

Minden relativ. Ahol millio dollaros cloud szamla kepzodik, az a ceg mar feltehetoen 10000+ dolgozoval rendelkezik, ahol a berkoltseg mellett a millio$ kis penz. Ha nem lenne public cloud, akkor ugyanezen embertomeg ugyanugy beleolne ezt (sot lehet hogy meg tobbet) on-prem datacenterbe.

  • secret manager: misuse, nyilvan nem kell masodpercenkent ezerszer lekerdezni a jelszot
  • cloudwatch: igen, ezt emlitettem, de ezert kell alkalmazni harcedzett DevOpsos embereket, akik nem csak babzsakfotelbol kattingatnak fogalmatlanul, hanem figyelnek a reszletekre. Egyebkent meg ott a Cost Managementben az Anomaly Detection feature. Kuld emailt ha vminek kiugroan megno a koltsege egy nap utan. Plusz erdemes Budgetet is beallitani kornyezetekre, hogy az osszkoltseget egybe is lassa az ember. Lehet trendeket nezegetni, hogy no-csokken honapokon keresztul.
  • inspector: az ilyen esetekre kell egy tenyeres-talpas FinOpsos, aki visszacharge-olja a koltsegeket a costcenterekre. Pillanatok alatt kikapcsolodnak az ilyen mas kontojara kert atgondolatlan vagy egyaltalan nem hasznalt szolgaltatasok.
  • inspector: az ilyen esetekre kell egy tenyeres-talpas FinOpsos, aki visszacharge-olja a koltsegeket a costcenterekre. Pillanatok alatt kikapcsolodnak az ilyen mas kontojara kert atgondolatlan vagy egyaltalan nem hasznalt szolgaltatasok.

Bingó.

Valamiért azt gondolja a legtöbb user, hogy a cloud költség az egy ilyen homogén valami, ennyibe kerül, kész. Haha, meg a lófaszt. Amelyik resource-on nincs cost center tag, ott kap mindenki egy értesítést, aki valaha megpiszkálta. Ha utána sincs tag, az automatizmus ledarálja 15 nap múlva. Szevasztok!

szamtalan managed szolgaltatassal egy szal DevOpsos is elboldogul

Na, hát így lesz drága a cloud. :D

az a ceg mar feltehetoen 10000+ dolgozoval rendelkezik

Nem kell annyi a cloudhoz. Vagy mégis? :)

(nem, 1M USD költés lazán van egy startupnál is a nagy víz másik oldalán)

secret manager: misuse, nyilvan nem kell masodpercenkent ezerszer lekerdezni a jelszot

130 forint egyetlen bejegyzés tárolása (nem csináltál még vele semmit). 10k entry 1,3 millió. Még mindig nem csináltál vele semmit. Na ezekből jönnek össze a millió dolláros költések.

"amíg nem használod" olcsó, így nagyon sok helyen egy rendszer tervezésekor (haha) egyáltalán nem számolják ki, hogy mennyi lesz az üzemeltetési költség, utána meg már nagyon nehézkes. Ami azt illeti közben is. Sokszor nehéz egy komplex rendszerben megmondani, hogy miből mennyi művelet/bájt/stb lesz.

A cloud olyan, mint a magyar adórendszer: millió helyre van eldugva mindenféle "adó", amivel sokszor akkor szembesülsz, amikor jönnek a számlák/alertek.

(nem érvelek semmi mellett, vagy ellen, legfeljebb csak azt vitatom, hogy a "cloud -kiváltképp az AWS- nem drága".)

10k entry

Nem kell minden egyes jelszot kulon secretbe menteni, egy appnak eleg egy secret, ami tobb key-value part tartalmaz (up to 64KB). Nem szokott egy cegnek 10k appja lenni. Ha megis, akkor az az 1.3MFt apropenz, valoszinu hogy egy ennyi secrettel elbiro Hashicorp Vault uzemeltetese se lenne sokkal olcsobb...

Ezt nekünk a nagyfőni egyszer elmagyarázta, sajnos nem tudom pontosan visszaadni, de a lényeg az, hogy a sokmilliós szerver + a bérek másfajta költségnek minősülnek, mint a havidíjas cuccok, mint az AWS és más is az elszámolásuk. Ez utóbbinak olyan az elszámolása cég szinten, mint mondjuk egy JetBrains licencnek, míg a szervert le lehet fullosan amortizálni, a munkabéreket is jobban le lehet írni, stb.

Bár volt cégem, sosem ekkora, hogy ezek a dolgok számítsanak, de úgy látszik, itthon valami nagyon ferdén működik a pénzügy a világ többi részéhez képest.

De mindezt félretéve: a $72-ben nincs benne a mérnökóra, márpedig nem mindig spórol az EKS. Az outage valós.

Viszont, a sokmilliós szerver sok $72 -os Kubernetes clustert el tud futtatni, tehát a projektek között eloszlik a költség. Ha neked csak 1 darab Kubernetes clusterra van szükséged, akkor valóban reasonable a $72, de ha folyamatosan növekszik az infrastruktúrád, akkor a privát cluster TCO-ja sok projektre szét tud dobódni, mert nem lesz drágább üzemeltetni azon 1 Kubernetes clustert mint 11-et. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Szerintem: a penzugyesek/reszvenyesek nem szeretik a CAPEX-et, mert az lenyegeben egy lekotott penz, amit a ceg mar nem tud megforgatni. Mivel az ilyen assetek kibogaraszhatoak a reszvenyesi jelentesbol, igy mindenfelet szamolnak belole analystok. A ceg pedig torekszik, hogy minel jobbak legyenek az ilyen meroszamok.

Nem hiszem. Az tuti, hogy volt már, én is biztosan használtam, ezekkel a szavakkal én is rendszeresen 10-15 éve küzdöttem munka közben, mint gelei kolléga. Én most se látom őket sokat szerintem itt, de készségesen elhiszem neked, hogy most gyakoribb a hupon, mint korábban, én messze nem olvasok el mindent.

( goodbyte v | 2026. 02. 23., h – 13:53 )

én k8s-t (managementre nézelődésre k9s ) nyomok otthon, Github Actions + helm + ArgoCD . Authentik nálam is van, illetve szintén tanulás célból prometheus +loki + grafana . még a perzistens storage irányba én is el akarok menni . 

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

( fanta | 2026. 02. 23., h – 14:33 )

Az itthoni kubernetezés a Home Assistant támogatott platformmá válására vár.

$ grep -c egy$ word.list
100

Az akkori temat is olvastam, azt nem tudom hogy full UpToDate vagyok-e abbol a topicbol, de pl amit ott a kerdezo kerdezett (van-e Magyarorszagon letjogosultsaga a kubernetes tanulasanak a gyakorlatban) en annyit tennek hozza, hogy ha uzemeltetsz es kontenerekben gondolkodsz, akkor mindenkepp... A Docker (swarm) uzemeltetesre borzaszto kenyelmetlen. (En swarmoztam, prodban, nem volt jo elmeny...) meg ha nem is a scalability vagy a HA az elsodleges szempontod , hanem csak tenyleg "barmit" kontener alapon uzemeltetsz, akkor is mindnekepp kubernetes. Nekem ez a velemeny ezzel a regi topic-al kapcs-ba.

( strogg v | 2026. 02. 24., k – 12:21 )

"Kubernetes - Ki hogy kezeli?" Paracetamol 3x1, némi alkohol,xanax,válium turmix és kifeküdtem :D :D :D

-42-

( hrgy84 | 2026. 02. 24., k – 18:41 )

Elfelejtettem leírni: a cégnél Kubeadm alapú clustereket használunk, ahol saját üzemeltetésem van, oda K0s-t telepítek. Végtelenszer egyszerűbb. 

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-