De la stateless la stateful
De unde pornim
În Laboratorul 2, Ticketing API rula cu:
USE_POSTGRES=false
Fiecare Pod păstra tichetele în memoria procesului. Această variantă a fost utilă pentru a studia reconcilierea, scalarea și rolling update-ul, dar are două limitări importante:
- datele dispar la recrearea Pod-ului
- replicile nu partajează aceeași stare.
În Laboratorul 3 folosim:
USE_POSTGRES=true
Toate replicile API accesează aceeași bază de date PostgreSQL.
Arhitectura laboratorului
Fluxul principal este client → Service ticketing-api → Pod Ticketing API → Service postgres → Pod postgres-0. Pod-ul PostgreSQL montează un
PersistentVolumeClaim separat de ciclul său de viață.
Componentele au responsabilități diferite:
| Componentă | Tip | Motivație |
|---|---|---|
| Ticketing API | Deployment | replicile sunt interschimbabile și nu păstrează date local |
| PostgreSQL | StatefulSet | are identitate stabilă și folosește stocare persistentă |
| API Service | ClusterIP | oferă un endpoint stabil către replicile Ready |
| PostgreSQL Service | headless | oferă identitate de rețea stabilă pentru StatefulSet |
| PVC | stocare | păstrează datele independent de ciclul de viață al Pod-ului |
Deployment sau StatefulSet?
Un Deployment este potrivit atunci când Pod-urile sunt interschimbabile. Dacă un Pod API dispare, Kubernetes poate crea altul fără să păstreze identitatea celui vechi.
Un StatefulSet este potrivit atunci când instanța are nevoie de una sau mai multe proprietăți stabile:
- nume predictibil, în cazul nostru
postgres-0 - identitate de rețea stabilă
- asociere stabilă cu propriul PersistentVolumeClaim.
Folosirea unui StatefulSet nu transformă automat PostgreSQL într-un sistem replicat sau high-availability. În laborator rulăm o singură instanță pentru a studia identitatea și persistența.