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

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

Múlt hónapban végre belehúztam. Hónapokig figyeltem, ahogy az OpenTofu projekt érik, és a HashiCorp licenszelési helyzete egyre kényelmetlenebbé válik az ügyfélmunkákhoz. Végül 47 Terraform modult migráltam három éles környezetben OpenTofu-ra. Nagyjából két hét tényleges munka volt, egy hónapra széthúzva, és a legtöbb simán ment. A legtöbb. Miért váltottam A BSL licencváltás volt a kiváltó ok, de nem az egyetlen. Pár ügyfelem kényes kérdéseket kezdett feltenni a Terraform Enterprise szerződésükről. Egyikük kapott egy levelet a HashiCorp sales csapattól, amiből elég egyértelművé vált a költségek iránya. Az OpenTofu eljutott arra a pontra, ahol a maradás kockázata nagyobbnak tűnt, mint a váltásé. ...

Egyszer töröltem S3 bucketet, és azóta is bánom. 2022-ben szedtem szét egy staging környezetet, és pár órán belül valaki más már be is húzta ugyanazt a bucket nevet. Egy másik accountban futó CloudFormation stack pedig teljes nyugalommal kezdett logokat írni egy bucketbe, ami már nem az enyém volt. Nem az a péntek volt, amire szívesen emlékszem vissza. Az AWS most végre kiadta a rendes megoldást: account regional namespace az S3 general purpose bucketekhez. Kb. hét év kellett hozzá, ami egyszerre vicces és kicsit fárasztó. ...

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