Do you run databases in Kubernetes or keep them outside the cluster?

Managed services are worth considering if you don't want to own every part of database operations. Depending on the service and configuration, the provider can handle much of the backup, failover, and upgrade work. Check what is actually included, especially for disaster recovery.

The bill may be higher than running the software yourself, but compare that with the time and expertise needed to maintain it. That tradeoff gets more noticeable when there are lots of services to support.

Running stateful workloads in Kubernetes is a valid option. A StatefulSet gives pods stable identities and can work with persistent volumes, but it doesn't by itself make a database highly available or take care of backups.

Look at application-specific operators such as CloudNativePG for PostgreSQL or Strimzi for Kafka. They can automate parts of deployment and maintenance, but you still need to understand storage, recovery, upgrades, and the operator's failover behavior before trusting the setup in production.

There's a middle option: run the database on dedicated VMs and manage the configuration with infrastructure as code and a tool like Ansible. You still own maintenance and recovery, but the database doesn't have to share the Kubernetes lifecycle.

For a bare metal cluster, storage design can drive the whole decision. One possible setup uses Ceph for primary storage and dedicated nodes with local disks for replicas. Replicas can provide another copy of the data, but they don't replace backups and log shipping.

Automatic failover isn't mandatory either. You can choose a manual process, though that means accepting the operational work and recovery time that come with it.