Hey there! I’ve spent a lot of time working with databases on Kubernetes and OpenShift, so let’s tackle your questions head-on:

General Databases (With Native K8s/OpenShift Support or Mature Operators) #

• Relational Databases
  • PostgreSQL: Boasts the richest operator ecosystem for K8s/OpenShift, with tools covering every use case from development to production
  • MySQL/MariaDB: Multiple official and community operators available, including Red Hat’s supported version optimized for OpenShift
  • Oracle Database: Oracle provides an official Operator for Kubernetes that integrates seamlessly with their enterprise database features
  • SQL Server: Microsoft’s SQL Server Operator lets you deploy and manage SQL Server instances natively on K8s/OpenShift
• NoSQL Databases
  • MongoDB: Official MongoDB Operator (and community variants) handle replica sets, sharding, and full lifecycle management
  • Cassandra: K8ssandra (a popular open-source distribution) or DataStax’s Cassandra Operator simplify deploying and scaling Cassandra clusters
  • Redis: Operators from Redis Labs or the community manage Redis standalone, sentinel, or cluster deployments
  • Elasticsearch: Elastic’s Elastic Cloud on Kubernetes (ECK) operator manages Elasticsearch, Kibana, and other stack components seamlessly

PostgreSQL Operators (Tailored for K8s/OpenShift) #

• Crunchy Data PostgreSQL Operator: One of the most widely adopted community options. It supports high availability, automated backups/restores, monitoring, and integrates smoothly with OpenShift’s security policies.
• Zalando Postgres Operator: Built by Zalando for their own production use, this operator automates cluster scaling, failover, and maintenance tasks with minimal manual intervention.
• EDB PostgreSQL Operator: Enterprise-grade solution with commercial support, ideal for teams needing SLA-backed deployments on OpenShift.
• Red Hat OpenShift PostgreSQL Operator: Available directly in the OpenShift OperatorHub, it’s a fully supported, out-of-the-box option that integrates deeply with OpenShift’s ecosystem.
• StackGres: Open-source operator focused on performance and simplified operations, with built-in features like connection pooling, automated backups, and observability tools.

Here are proven HA solutions you can dive into, categorized by approach:

• Operator-Native HA Solutions
  • Leverage built-in HA capabilities from mature operators: For example, Crunchy Data’s operator uses Patroni to manage PostgreSQL clusters, handling failover, leader election, and node healing automatically. Zalando’s Spilo-based operator does the same with a focus on hands-off automation.
  • MongoDB Operator Replica Sets: Automatically maintains replica set health, elects new primary nodes on failure, and ensures data consistency across replicas.
  • K8ssandra: Manages Cassandra’s multi-node clusters, handling data replication, node replacement, and failure recovery out of the box.
• StatefulSet + External Coordination Tools
  • StatefulSet + Patroni: If you prefer more control, deploy Patroni alongside a PostgreSQL StatefulSet. Patroni uses etcd for coordination to manage leader election and failover.
  • StatefulSet + Keepalived + VIP: A traditional HA approach for databases without native cluster support—Keepalived maintains a virtual IP that switches to the healthy primary pod on failure.
  • StatefulSet + etcd + Custom Controllers: For teams with development resources, build a custom controller that uses etcd to track cluster state and handle failover logic.
• Cloud-Native Storage-Driven HA
  • CSI Storage Plugins (Portworx, Rook Ceph): Use distributed block storage to replicate database volumes across nodes. Combined with StatefulSets, this ensures data survives node failures, while database-level replication handles service availability.
  • OpenShift Data Foundation (ODF): Red Hat’s integrated storage solution provides distributed, highly available storage that pairs seamlessly with OpenShift’s database operators for end-to-end HA.
• Cross-Availability Zone/Region HA
  • Multi-AZ Cluster Deployments: Spread database nodes across multiple AZs in your cloud provider (or on-prem zones), using database replication (like PostgreSQL streaming replication) to sync data across zones. Operators can automatically failover to a healthy node in another AZ if one zone goes down.
  • Disaster Recovery with Object Storage: Schedule regular backups to object storage (e.g., OpenShift Object Storage, S3-compatible storage) and automate recovery in a secondary cluster. This is a cost-effective way to handle regional outages.

内容的提问来源于stack exchange，提问作者Kipje