Flux GitOps es az image rollout

A Nortinia minden Kubernetes klasztere Flux GitOps-szal mukodik. Ez nem trendkovetes — egy konkret felelosseg-szegmentaciot kapunk vele: a Git a forrasa az igazsagnak, a Flux a recociler, a NIP pedig a kontroll-sik, ami az image taggjeit es a deploy auditot kezeli. Itt a felepites es az egy igazi race condition tortenete.

Egy repo per klaszter

Negy klaszter, negy repo:

• nip-cluster-prod — production workloads
• nip-cluster-staging — staging
• nip-cluster-data — adatszolgaltatasok (Postgres, Redis, MinIO)
• nip-cluster-observability — Grafana, Prometheus, Loki

Mindegyik egy Flux Kustomization gyokerrel, alatta namespace-enkenti alappapir + per-app overlay-ek. A separacio okai: (1) RBAC tisztabb, (2) reconcile failure scope-ja egy klaszterra korlatozott, (3) klaszter ujraepitese egyszerubb.

A reconcile ciklus: 60 masodperc

Flux a Kustomization-okat 60 masodpercenkent reconcile-li alapertelmezetten. Mi nem allitottuk lentebb — kiserleteztunk a 30 masodperccel, de a Git LFS quota (esetenkenti git pull-ok az image cache-elesnel) feleslegesen ugrott. 60 masodperc megfelel a 9 perces end-to-end deploy SLA-nak.

A ImageUpdateAutomation (Flux image automation controller) kulon polloz a GHCR-en, 1 percenkent. Latja az uj tag-eket, es a Git-be commit-ol egy bump-ot, amit a Kustomization egy ciklus mulva bevisz.

PR-vezerelt prod, push-to-main staging

• staging — push-to-main szabaly. A main branchet azonnal deploy-oljuk. Cel: gyorsan beriasztja a nyilvanvalo hibakat.
• prod — PR-vezerelt. Egy mernok PR-t nyit, legalabb egy review kell, CI gates-ek atmennek, csak akkor mergel. A merge utan a Flux reconcile-li.

A PR template-en megjelennek a kovetkezo info-k: melyik image tag, melyik commit, milyen change log, milyen rollback path. Ez az audit trail.

Az image promocios letra

Egy uj image elete:

1. dev-<sha> — fejlesztoi machine build, csak helyileg.
2. staging-<sha> — CI build a staging branchrol, automatic deploy a staging klaszterbe.
3. prod-<sha> — CI build a main branchrol, manualis promociot var (PR a prod GitOps repoba).

A promocio NEM duplazza a Docker layer-eket — ugyanaz a SHA, ugyanaz az image. A tag csak retag (docker buildx imagetools create). Olcso es gyors.

A 2026 marciusi race condition

2026. marcius elejen volt egy ket napos peri-od, amikor a deploy idook megnyultak ~9 percrol ~25 percre. A tunet: a Flux Kustomization status Reconciling-ban ragadt, majd Suspended lett. Vizsgalat.

A gyoker-ok: a ImageUpdateAutomation controller commit-olt egy uj image tag-et UGYANABBA a kustomization.yaml-ba, amit a Kustomization reconciler eppen olvasott. A Flux nem ad lockoldast a ket controller kozott, igy a reconciler vegtelen ciklusba kerult, mert a fajl a reconcile alatt valtozott.

A javitas: szetszedtuk a fajlokat. A ImageUpdateAutomation mar egy kulon image-tags.yaml-be ir, amit a kustomization.yaml patchesStrategicMerge-vel betolt. Igy a ket controller kulon fajlokon dolgozik. A reconcile ido visszament 60-90 masodpercre.

A tanulsag: a Flux controller-ek logikailag elvalnak, de fizikailag (fajl szinten) nem. A patchesStrategicMerge segit ezt megoldani.

Mit nem epitettunk meg

• Multi-cluster GitOps (egy repo, sok klaszter) — kornyezetenkenti repo egyszerubb, kevesebb folder-hierarchia, jobb RBAC.
• Sajat reconciler — a Flux jol mukodik, nincs miert helyettesiteni.
• Automatic prod promotion — szandekosan manualis. Egy mernok PR-ja a vegso gate.

Szamok

• 4 klaszter / 4 repo
• 60 masodperces reconcile (default)
• 1 perces image polloz GHCR-en
• 1 247 deploy az utolso negyedevben, ebbol 0 elveszett (PR audit trail)