The recommendation for previous versions of Eventstore has been not to Dockerize it for production use.
Is v5 considered “safe” for production (or will be safe once it’s out of RC?) when using Kubernetes with attached block storage … ? What would be the pros & cons?
Thanks,
Robert
It comes down to performance, your ability to backup and restore and upgrade.
Just firing it into Kubernetes as a stateful set will not be enough, you will need to manage your disks. If you run across multiple AZs, with multiple nodes in each, you could get away with local disks if you have enough copies of the data and a strong backup plan. Are you using Portworx or something else?
Also just a note here. We are working on offical docs for running Event Store with Kubernetes, right now.
Chris
Not using Portworx, but it does look interesting. Looks like it may simplifiy some of the disk mgmt necessities. I have so far used local disks + backup plan.
Nice!
We’ve been running our staging environment with Azure Kubernetes Service, using managed premium disks and works quite well. We have 3 replicas, obviously it’s only single region, with frequent backups.
Obviously you will want to have multiple nodes on multiple regions if you need HA across regions.
Running multiple nodes in the same cluster in different regions is not recommended. The replication protocol is designed for LAN latencies, not WAN latencies. There are other mechanisms by which you can do georeplication, but this should not be among the considerations!
I agree, you cannot have a node as part of the quorum which is geo-replicated, it will slow everything down.
Non-Promotable clone nodes can be used in this case I imagine as a sort of DR backup or off-site replication, but I believe there is more coming in ES 5 which support geo-replication better.