Em qui, 13 de set de 2018 às 10:06, Alfredo De Luca <
alfredo.deluca@gmail.com> escreveu:
thanks heaps.
The idea is actually to use K8s so install postgres with glusterfs as storage manager so in case a POD crashes can start again on another node with the same file systems
So it was a case of problem A question B.
If you're really looking that way I would never consider a networked filesystem.
k8s has mechanisms to restart a pod on the same node if you configure your pod correctly. Also, you should declare a data container with a well defined hardware dedicated volume and use a known stable filesystem like xfs or ext4 on it.
You should think of using PostgreSQL native replication to a standby pod on another kubernetes node.
If you really think you don't want to replicate your data (not recommended anyway) you can use a hardware storage system connected to two (or more) servers and use CLVM to switch a volume between servers in a controlled way. I don't know how to automate that with kubernetes maybe someone has more answers to you.
I don't see the point of using kubernetes for such a statefull beast like a database, kubernetes basics assume that a pod may fail at any time and you can have other instances running in parallel without worrying about their current state, which is *not* what a database system can do transparently.
You may consider using that for development or testing purposes but I don't see it in production by current technology. Some people run production databases on containers (replicating things as I said), I don't know about k8s.
Flavio Gurgel