5 ms·

Definitely a good one: "Experiences with running PostgreSQL on Kubernetes - Gravitational - blog post 2018" For anyone who thinks running a database in a conta

Definitely a good one: "Experiences with running PostgreSQL on Kubernetes - Gravitational - blog post 2018" For anyone who thinks running a database in a container environment is a neat idea, think again. I am guilty of using containers for temporary test databases, but the thought of running production databases in containers sends shivers down my spine.

ivan_ah 6y ago
What about single-host container (i.e. regular docker host, not k8s) with data partition mounted from host?
- squibbles 6y ago
  For me, personally -- I cannot think of a sufficient justification to put a production database in a container. A good database server is designed for performance, reliability, scalability, security, etc., without containers. Putting a production database inside a container introduces a world of unnecessary edge cases and complexity.
  - ivan_ah 6y ago
    Thanks for your feedback. I might run the DB on the host then, and just use containers for the app server. I'm not at the scale to warrant a separate host for the DB.
  - neop1x 6y ago
    Depends on requirements. Someone needs one big, highly-optimized DB instance. Someone else needs high-availability 3+ instance cluster. Having a cluster of containers brings performance penalty but if your app is read-heavy, you can read from all instances and multiply read throughput...
- biglost 6y ago
  And using delegated, for local development, multiple versions with a few commands is really great.
aberoham 6y ago
OG thread https://news.ycombinator.com/item?id=16207430 https://news.ycombinator.com/item?id=16207430
AmericanChopper 6y ago
I don’t know why anybody would presume that a technology focused on ephemeral resource provisioning would be a suitable place to put your persistence layer... That said, I don’t think it’s a sin at all to use it for testing. My default local dev setup is to use a Postgres container. But persistence is very much not required in that situation.
- deathanatos 6y ago
  > I don’t know why anybody would presume that a technology focused on ephemeral resource provisioning would be a suitable place to put your persistence layer... Kubernetes does more than that, and has features like PVCs + Statefulsets are basically intended for, designed for exactly this use case. If you see the HN comments[1], the top comment mentions this, and that the article waves it away for reasons not related to k8s, but to "well, if the underlying storage is slow or not durable, then…" … yeah, then it doesn't matter if you're running k8s in the middle of it or not. [1]: https://news.ycombinator.com/item?id=16207430 https://news.ycombinator.com/item?id=16207430
  - AmericanChopper 6y ago
    You can make it work, but why would you want to? Databases aren’t generally something that benefits from using container orchestration. They’re not usually highly dynamic, horizontally scaling systems. Generally you’d optimize that part of your system to maximize stability and consistency. For most typical use cases I can’t see the intuitive leap required to decide that all that additional complexity is necessary to attempt to replicate what you’d get from a few VPS. Unless you have a specialized use case, to me it just seems like very obviously the wrong tool for the job.
    - FridgeSeal 6y ago
      It that I advocate running your own Postgres setup in your own cluster instead of just renting a managed version, but I’ve run a few databases on K8s and found it pretty fine: useful for when your hosting provider doesn’t support the database you want to run (Clickhouse managed AWS service when?) or for application-specific KV-stores: EBS volumes and PVC’s are great, solid performance, kubernetes takes care of the networking, will resurrect it if the worst happens and it does go down. I probably could have those things on their own instance but then I’d need to have to go through the hassle of networking, failover/recreation, deployments, etc and for the vast majority of cases that’s 100% more effort than deploy a stateful-set.
ec109685 6y ago
This is exactly what AWS does with something like Aurora: https://awsmedia.awsstatic-china.com/blog/2017/aurora-design-considerations-paper.pdf https://awsmedia.awsstatic-china.com/blog/2017/aurora-design... Not sure why you're so fearful. Bare metal machines can crash in weird ways and K8s containers can be just as reliable as the underlying host.
mamon 6y ago
Some companies make a business out of it: https://www.crunchydata.com/products/crunchy-postgresql-operator/ https://www.crunchydata.com/products/crunchy-postgresql-oper...
- neop1x 6y ago
  Percona XtraDB Operator (mysql-like) https://www.percona.com/doc/kubernetes-operator-for-pxc/index.html https://www.percona.com/doc/kubernetes-operator-for-pxc/inde...

ivan_ah 6y ago

What about single-host container (i.e. regular docker host, not k8s) with data partition mounted from host?

squibbles 6y ago
For me, personally -- I cannot think of a sufficient justification to put a production database in a container. A good database server is designed for performance, reliability, scalability, security, etc., without containers. Putting a production database inside a container introduces a world of unnecessary edge cases and complexity.
- ivan_ah 6y ago
  Thanks for your feedback. I might run the DB on the host then, and just use containers for the app server. I'm not at the scale to warrant a separate host for the DB.
- neop1x 6y ago
  Depends on requirements. Someone needs one big, highly-optimized DB instance. Someone else needs high-availability 3+ instance cluster. Having a cluster of containers brings performance penalty but if your app is read-heavy, you can read from all instances and multiply read throughput...
biglost 6y ago
And using delegated, for local development, multiple versions with a few commands is really great.

aberoham 6y ago

OG thread https://news.ycombinator.com/item?id=16207430 https://news.ycombinator.com/item?id=16207430

AmericanChopper 6y ago

I don’t know why anybody would presume that a technology focused on ephemeral resource provisioning would be a suitable place to put your persistence layer... That said, I don’t think it’s a sin at all to use it for testing. My default local dev setup is to use a Postgres container. But persistence is very much not required in that situation.

deathanatos 6y ago
> I don’t know why anybody would presume that a technology focused on ephemeral resource provisioning would be a suitable place to put your persistence layer... Kubernetes does more than that, and has features like PVCs + Statefulsets are basically intended for, designed for exactly this use case. If you see the HN comments[1], the top comment mentions this, and that the article waves it away for reasons not related to k8s, but to "well, if the underlying storage is slow or not durable, then…" … yeah, then it doesn't matter if you're running k8s in the middle of it or not. [1]: https://news.ycombinator.com/item?id=16207430 https://news.ycombinator.com/item?id=16207430
- AmericanChopper 6y ago
  You can make it work, but why would you want to? Databases aren’t generally something that benefits from using container orchestration. They’re not usually highly dynamic, horizontally scaling systems. Generally you’d optimize that part of your system to maximize stability and consistency. For most typical use cases I can’t see the intuitive leap required to decide that all that additional complexity is necessary to attempt to replicate what you’d get from a few VPS. Unless you have a specialized use case, to me it just seems like very obviously the wrong tool for the job.
  - FridgeSeal 6y ago
    It that I advocate running your own Postgres setup in your own cluster instead of just renting a managed version, but I’ve run a few databases on K8s and found it pretty fine: useful for when your hosting provider doesn’t support the database you want to run (Clickhouse managed AWS service when?) or for application-specific KV-stores: EBS volumes and PVC’s are great, solid performance, kubernetes takes care of the networking, will resurrect it if the worst happens and it does go down. I probably could have those things on their own instance but then I’d need to have to go through the hassle of networking, failover/recreation, deployments, etc and for the vast majority of cases that’s 100% more effort than deploy a stateful-set.

ec109685 6y ago

This is exactly what AWS does with something like Aurora: https://awsmedia.awsstatic-china.com/blog/2017/aurora-design-considerations-paper.pdf https://awsmedia.awsstatic-china.com/blog/2017/aurora-design... Not sure why you're so fearful. Bare metal machines can crash in weird ways and K8s containers can be just as reliable as the underlying host.

mamon 6y ago

Some companies make a business out of it: https://www.crunchydata.com/products/crunchy-postgresql-operator/ https://www.crunchydata.com/products/crunchy-postgresql-oper...

neop1x 6y ago
Percona XtraDB Operator (mysql-like) https://www.percona.com/doc/kubernetes-operator-for-pxc/index.html https://www.percona.com/doc/kubernetes-operator-for-pxc/inde...