CloudNativePG Deployment Guide

Overview

Crater uses PostgreSQL as its backend database to manage user sessions, job metadata, scheduling state, and platform configurations.

To achieve production-grade, Kubernetes-native PostgreSQL management, we adopt the CloudNativePG Operator, which provides:

• Declarative management of PostgreSQL clusters via CRDs
• Automated high-availability, backups, and failover
• Tight integration with Kubernetes RBAC, storage, and scheduling

Our deployment integrates CloudNativePG with OpenEBS Local PV for storage, enabling fast local-disk performance and complete data lifecycle management.

Why CloudNativePG?

We chose CloudNativePG because:

• It is a CNCF incubating project with strong community support.
• It provides a clean separation between PostgreSQL configuration and Kubernetes-native orchestration.
• It simplifies PostgreSQL deployment while remaining flexible for advanced tuning.

In the Crater stack, each PostgreSQL cluster is defined as a custom Cluster resource and controlled by the operator.

Storage Configuration

The database uses local persistent storage backed by OpenEBS Local PV (as described in openebs.md).

This setup provides:

• High IOPS and low latency for single-node workloads
• Predictable node-local scheduling
• Clean and declarative volume lifecycle management

Make sure OpenEBS Local PV is installed and functioning correctly before installing CloudNativePG.

Prerequisites

• kubectl and helm installed
• OpenEBS Local PV installed

Installation

We provide a tailored Helm configuration for the operator installation.

📦 Helm values: deployments/cloudnative-pg/values.yaml
📖 Detailed guide: deployments/cloudnative-pg/README.md

Edit on GitHub