5 ms·

So do people containerize databases in production these days? I thought a couple of years ago DBs were the classic example of applications that don't belong in

by curt15 1y ago

So do people containerize databases in production these days? I thought a couple of years ago DBs were the classic example of applications that don't belong in containers.

fillest 1y ago
Services should be decoupled from OS distro dependencies as much as possible, otherwise you will be bitten at an unexpected moment (e.g. upgrading your distro packages) by some problem like this https://wiki.postgresql.org/wiki/Locale_data_changes https://wiki.postgresql.org/wiki/Locale_data_changes This can be solved by building statically (or using something like Nix) or by at least using containers.
lukaslalinsky 1y ago
I do, but I take a very cautious approach. I run a custom image with PostgreSQL and Patroni on Kubernetes, no operator, each replica has it's own StatefulSet tied to a specific node. There is very little automation, but it still better than running PostgreSQL outside of Kubernetes. I get the benefit of simplified monitoring, log handling, request routing, while still having very static resource assignments.
qskousen 1y ago
I also would like to know this, I was just told that databases should be outside the cluster a couple days ago by someone with a decade of K8s experience.
- 5Qn8mNbc2FNCiVV 1y ago
  Well, CloudnativePG exists and it works really really well. At some point if you can afford to have someone manage your databases separately from your applications, you can think about putting it outside the cluster but I'd wager at some point you've got enough experience with running your DB with an operator that you can keep running it in the cluster.
- Atotalnoob 1y ago
  Generall, yes. Unless you have a dedicated team to do the stuff for you. Crunchydata is a good starting point
imcritic 1y ago
Depends on the scale. Something small is okay to keep in containers. If you want to push performance to the limits - you definitely will run your DBMS outside a container.
tekno45 1y ago
To host it in an orchestrator your cluster has to be more available than your DB. you want 3 9s of availability for your DBs maybe more. Then you need 4 9s for your cluster/orchestrator. If your team can make that cluster, then it makes more sense to put all under one roof then develop a whole new infrastructure with the same level of reliability or more.
- GauntletWizard 1y ago
  This is a persistent myth that is just flat out wrong. Your k8s cluster orchestrator does not need to be online very often at all. The kube proxies will gladly continue proxying traffic as last they best know. Your containers will still continue to run. Hiccups, or outright outages, in the kubi API server do not cause downtime, unless you are using certain terrible, awful, no good, very bad proxies within the cluster (istio, linkerd).
  - tekno45 1y ago
    Your CONTROL PLANE doesn't immediately cause outages if it goes down. But if your workloads stop and can't be started on the same node you've got a degradation if not an outage.
    - GauntletWizard 1y ago
      Yes, but that's workloads || operator, not workloads && operator - you don't need four nines for your control plane just to keep your workloads alive. Your control plane can be significantly less reliable than your workloads, and the workloads will keep serving fine. In real practice, it's so cheap to keep your operator running redundantly, that it's probably going to have more nines than your workloads, but it doesn't need to be
      - tekno45 1y ago
        You're assuming a static cluster. In my world scaling is required. Meaning new nodes and new pods. Meaning you need a control plane. Even in development, no control plane means no updates. In production, no scaling means im going to have a user facing issue at the next traffic spike

by curt15 1y ago

So do people containerize databases in production these days? I thought a couple of years ago DBs were the classic example of applications that don't belong in containers.

fillest 1y ago

Services should be decoupled from OS distro dependencies as much as possible, otherwise you will be bitten at an unexpected moment (e.g. upgrading your distro packages) by some problem like this https://wiki.postgresql.org/wiki/Locale_data_changes https://wiki.postgresql.org/wiki/Locale_data_changes This can be solved by building statically (or using something like Nix) or by at least using containers.

lukaslalinsky 1y ago

I do, but I take a very cautious approach. I run a custom image with PostgreSQL and Patroni on Kubernetes, no operator, each replica has it's own StatefulSet tied to a specific node. There is very little automation, but it still better than running PostgreSQL outside of Kubernetes. I get the benefit of simplified monitoring, log handling, request routing, while still having very static resource assignments.

qskousen 1y ago

I also would like to know this, I was just told that databases should be outside the cluster a couple days ago by someone with a decade of K8s experience.

5Qn8mNbc2FNCiVV 1y ago
Well, CloudnativePG exists and it works really really well. At some point if you can afford to have someone manage your databases separately from your applications, you can think about putting it outside the cluster but I'd wager at some point you've got enough experience with running your DB with an operator that you can keep running it in the cluster.
Atotalnoob 1y ago
Generall, yes. Unless you have a dedicated team to do the stuff for you. Crunchydata is a good starting point

imcritic 1y ago

Depends on the scale. Something small is okay to keep in containers. If you want to push performance to the limits - you definitely will run your DBMS outside a container.

tekno45 1y ago

To host it in an orchestrator your cluster has to be more available than your DB. you want 3 9s of availability for your DBs maybe more. Then you need 4 9s for your cluster/orchestrator. If your team can make that cluster, then it makes more sense to put all under one roof then develop a whole new infrastructure with the same level of reliability or more.

GauntletWizard 1y ago
This is a persistent myth that is just flat out wrong. Your k8s cluster orchestrator does not need to be online very often at all. The kube proxies will gladly continue proxying traffic as last they best know. Your containers will still continue to run. Hiccups, or outright outages, in the kubi API server do not cause downtime, unless you are using certain terrible, awful, no good, very bad proxies within the cluster (istio, linkerd).
- tekno45 1y ago
  Your CONTROL PLANE doesn't immediately cause outages if it goes down. But if your workloads stop and can't be started on the same node you've got a degradation if not an outage.
  - GauntletWizard 1y ago
    Yes, but that's workloads || operator, not workloads && operator - you don't need four nines for your control plane just to keep your workloads alive. Your control plane can be significantly less reliable than your workloads, and the workloads will keep serving fine. In real practice, it's so cheap to keep your operator running redundantly, that it's probably going to have more nines than your workloads, but it doesn't need to be
    - tekno45 1y ago
      You're assuming a static cluster. In my world scaling is required. Meaning new nodes and new pods. Meaning you need a control plane. Even in development, no control plane means no updates. In production, no scaling means im going to have a user facing issue at the next traffic spike