3 ms·

You don't run shared/network storage. You run PVCs on local storage and you run an HA setup. You ship log files every 10s/30s/1m to object storage. You test you

You don't run shared/network storage. You run PVCs on local storage and you run an HA setup. You ship log files every 10s/30s/1m to object storage. You test your backups regularly which k8s is great for. All of this means that I don't worry about most things you mention. PG upgrade? Failover and upgrade the pod. Upgrade fails? wal-g clone from object storage and rejoin cluster. Scaling up? Adjust the resource claims. If resource claims necessitate node migration, see failover scenario. It's so resilient. And this is all with raid 10 nvme direct attached storage just as fast as any other setup. You mention etcd but people don't run etcd the way you're describing postgres. You run a redundant cluster that can achieve quorum and tolerate losses. If you follow that paradigm, you end up with postgres on k8s.

dillonmckay 6y ago
How big are your DBs in terms of size?
- qeternity 6y ago
  50gb - multi TB
coding123 6y ago
It sounds pretty simple and enticing. Any problems convincing the team of this route?
- sunshinekitty 6y ago
  Speaking from experience.. This is fine if you have a small single node database that can have some downtime. Once you need replicas, to fit your database in ram for performance, or reliability with a hot standby for failovers it becomes a lot more complicated. You should consider what (if anything) you miss out on by just running in a single vm that you can scale out much easier down the road should you need to. Alternatively pay extra for a hosted solution that simplifies those steps further.
  - qeternity 6y ago
    > single vm that you can scale out much easier I’m not sure how experience could lead you to this conclusion. This wouldn’t work for any of our production needs.
- halbritt 6y ago
  Historically speaking, convincing anyone to run data stores on k8s is a giant pain. This isn't helped by all the mythology around "k8s is great for stateless" further promoted by folks like Kelsey Hightower who firmly believes that one should rely on the cloud provider's data stores. This is great for the cloud provider as those are high margin services, I for one would rather have a single orchestration API that I have to interact with, that being the one offered by k8s. All the benefits of running workloads in k8s apply equally to data stores. Cattle, not pets. If your data store needs coddling then it's a pet and you're doing it wrong.
luttik 6y ago
For dummys like me who are interested but not familiar with infra. PVC = Persistent Volume Claim HA = High avalability PG = Postgres

dillonmckay 6y ago

How big are your DBs in terms of size?

qeternity 6y ago
50gb - multi TB

coding123 6y ago

It sounds pretty simple and enticing. Any problems convincing the team of this route?

sunshinekitty 6y ago
Speaking from experience.. This is fine if you have a small single node database that can have some downtime. Once you need replicas, to fit your database in ram for performance, or reliability with a hot standby for failovers it becomes a lot more complicated. You should consider what (if anything) you miss out on by just running in a single vm that you can scale out much easier down the road should you need to. Alternatively pay extra for a hosted solution that simplifies those steps further.
- qeternity 6y ago
  > single vm that you can scale out much easier I’m not sure how experience could lead you to this conclusion. This wouldn’t work for any of our production needs.
halbritt 6y ago
Historically speaking, convincing anyone to run data stores on k8s is a giant pain. This isn't helped by all the mythology around "k8s is great for stateless" further promoted by folks like Kelsey Hightower who firmly believes that one should rely on the cloud provider's data stores. This is great for the cloud provider as those are high margin services, I for one would rather have a single orchestration API that I have to interact with, that being the one offered by k8s. All the benefits of running workloads in k8s apply equally to data stores. Cattle, not pets. If your data store needs coddling then it's a pet and you're doing it wrong.

luttik 6y ago

For dummys like me who are interested but not familiar with infra. PVC = Persistent Volume Claim HA = High avalability PG = Postgres