Legacy infrastruktúra migrálása Kubernetesre

A kihívás

Egy nagyvállalati ügyfélnél a teljes platform manuálisan felhúzott EC2 példányokon futott. Ami pár éve még „gyors és egyszerű” megoldásnak tűnt, idővel nehezen kezelhető rendszerré vált: egyedi szerverek, kézzel módosított konfigurációk, és rengeteg kimondatlan tudás, ami két senior mérnök fejében élt. Ismerős helyzet.

A fájdalompontok:

• A skálázás teljesen manuális volt. Új példányindítás, függőségek telepítése, load balancer beállítás, DNS frissítés. Csúcsidőben ez simán elvitt több órát.
• Nem létezett két egyforma szerver. Az évek alatt mindenhol más apró módosítás maradt, így a hibakeresés kiszámíthatatlan lett.
• A költségek folyamatosan nőttek. Sok túlméretezett példány futott éjjel-nappal, mert senki nem mert hozzányúlni.
• Az onboarding lassú volt. Új mérnököt betanítani hetekbe telt, mert dokumentáció helyett a „kérdezd meg Dávidot” folyamat működött.
• A kulcstudás két embernél volt. Ez lett a legnagyobb működési kockázat, és ezzel mindenki tisztában volt.

Úgy kellett modernizálni, hogy közben a fizető ügyfelek semmit ne érezzenek az átállásból.

A megközelítés

A migrációt három fázisra bontottam, és 10 hét alatt vittük végig. Egyetlen fix feltétel volt: ügyféloldalon nem fér bele leállás.

1. fázis: Infrastructure as Code (1-3. hét)

Mielőtt a Kuberneteshez nyúltam volna, kódba kellett önteni a meglévő állapotot. Amit nem értesz pontosan, azt nem érdemes migrálni.

• A futó szolgáltatások teljes auditja. Függőségek, portok, környezeti változók, volume mountok, cron jobok. Találtam 7 olyan szolgáltatást, amiről senki nem tudta, hogy még él. Igen, mind fontosnak bizonyult.
• Terraform a meglévő infrastruktúrára, első körben. VPC-k, security groupok, IAM role-ok, RDS példányok. Ez adott egy biztonsági hálót és egy olvasható dokumentációt is.
• Terragrunt bevezetése a környezetek közti ismétlődés csökkentésére.

2. fázis: EKS klaszter és konténerizálás (3-7. hét)

Miután a meglévő rendszer már IaC alapon állt, felépítettem a célarchitektúrát:

• EKS klaszter Terraformmal. Managed node groupokkal, on-demand kapacitással a stateful workloadokhoz és spot példányokkal a stateless szolgáltatásokhoz.
• Helm chart minden szolgáltatáshoz. Sablonozva, verziózva, átgondolt alapértékekkel.
• Konténerimage-ek multi-stage Dockerfile-okkal, méretre és biztonságra optimalizálva.
• Titokkezelés a .env fájlokból AWS Secrets Managerbe költöztetve, External Secrets Operatorral injektálva.
• Perzisztens tárolás EBS CSI driverrel és EFS-sel.

Két héten át párhuzamosan futtattam az új környezetet szintetikus forgalommal, mielőtt valódi terhelést engedtünk rá. Migrációnál a türelem általában a legolcsóbb biztosítás.

3. fázis: Zéró leállás melletti migráció (7-10. hét)

A tényleges átállás volt a legprecízebben megtervezett szakasz:

• Szolgáltatásonként haladtunk, nem egyszerre. A kevésbé kritikus komponensekkel kezdtünk, majd lépésről lépésre mentünk tovább.
• Súlyozott DNS routing. 5%-os indulás a Kubernetes irányába, egy hét megfigyelés, utána 25%, 50%, végül 100%.
• Az adatbázis-kapcsolatok adták a legtöbb finomhangolást, itt PgBouncer connection poolingot használtam.
• Rollback terv minden szolgáltatásra készült. A régi infrastruktúra 30 napig meleg tartalékban maradt.

Az eredmények

A számok csak a történet egyik fele. A csapat működése is érezhetően megváltozott: új mérnökök 10 perc alatt indítottak teljes fejlesztői környezetet, a telepítések pedig stresszes eseményből rutinfeladattá váltak. A két senior mérnök, akikre minden rá volt kötve, végre a termékre tudtak fókuszálni a szerverőrség helyett. Dávid különösen értékelte ezt.

A Terraform kódbázis lett az egyetlen megbízható forrás az infrastruktúrához. Kevesebb rögtönzés, kevesebb egyedi szerver, és jóval kevesebb „ezt még Dávid állította be” pillanat.