Az nem derult ki az irasodbol milyen kornyezetben probalod.
Amig ilyen keves adatmenyiseggel jatszol meg oke, hogy kubernetesben van utana rohadtul fajdalmas. Ugyan is a podok ki es be menenk ha a rendszer le es fel skalazza a nodok szamat. Erre persze lehet az a megoldas, hogy tartasz kulon "storage" nodeokat a kubernetesbe de ezzel meg mas problemak vannak. Jelenleg a kubernetesben nem lehet normalisan I/O-t limitalni egyes podoknak igy siman lehet, hogy egy alkalmazas megeszi a data node elol az I/O-t ez se egeszesges. Ha az ES-nek egy folyataba relocatelni kell indexeket akkor eleg sokat fogjak ragni a fuledet az emberek.. ,hogy miert nem megy az vagy amaz.
Az autoskalazas otleted meg fura pont a tarhely mennyiseget viszony jol elore ki lehet kalkulalni az alapjan skalazni eleg nagy butasag. Ha mar tarhelynel jarunk akkor erdemes hot/warm architekturat epiteni bar ez nalad ez a veszely nem all fent viszont jobb megoldas mint amit te gondolod. A masik problema ,hogy HPA-val csak ugy tudod megoldani ,hogy teszel moge egy prometeust, datadogot-t vagy barmi hasonlot metric szolgaltatast amibol kepes a kubernetes kiolvasni azt a erteket mikor kell skalaznia.
A harmadik es egyben legnagyobb problema ,hogy cloud kornyezetben a hozzacsatolt kulso diszkek sebessege eleg rossz aws-ben ugy-e gp2 a default ez eleg rossz van az io1 az meg rohadt draga szoval maradt a beepitett instance diszk aminek a prestetenciaja nem megoldhatatlan csak rohadt bonyolult foleg ha meg autoskalazni is szeretned oket.
Szoval nekem az a javaslatom ,hogy ne ragd kubernetesbe nagyon felesleges es nem add elonyt a klasszikus megoldasokhoz kepest. Sok mindenre jo a kubernetes de pont persistanciaba nem annyira jo.
--
"ssh in a for loop is not a solution" – Luke Kanies, Puppet developer