Szerintem ez több szívással jár (ebben a felállásban ahogy tervezed) mint amennyi hasznot hoz. Olvasva a fenti hozzászólásokat, kérdéseket, business kritikus az alkalmazás, ami nem biztos, hogy fel van készítve a konténerizációra. A kubernetes nem azt garantálja, hogy egy pod mindig futni fog, hanem azt, hogy az adott deploymenthez tartozó podból mindig fog futni valamennyi (annyi, amennyit meghatároztál). EKS-nél jártunk úgy, hogy scheduled retirement matt cserélődtek a hostok, és a podok új node-okon jöttek létre. Ennek időpontját meghatározni te nem nagyon tudod, ami máris kockázattal jár. HA nélkül mysql-t/mariadb-t kubernetesen kezelni felér egy oroszrulettel.
A skálázódás jelen esetben db oldalról nem releváns neked, max a siteok oldaláról. Egy kicsit úgy érzem - javíts ki ha tévedek -, hogy azért akartok K8S irányba menni, mert ez most a trendi. Pedig nem mindenre jó a K8S.
Aztán ha jól értem, akkor az ec2-k esetében sincs redundancia, vagy backup. Mi történik, hogy ha megáll az egyik db ec2? Tolerálható a probléma? Ha igen, akkor mehet kubernetesbe is, mert ott sem lesz kisebb a leállás kockázata.
Amit szintén el kell dönteni, hogy egy alkalmazást üzemeltettek a sok usernek, vagy sok alkalmazást a sok usernek, ahogy ezt fentebb már kérdezték is.
Szóval, ha kritikus az alkalmazás, akkor én a következő irányba mennék el:
Kubernetes Namespacek (RBAC-ot jól kell konfigurálni):
- minden user külön namespacebe
- HA megoldás a db-nek