Crunchy Data PostgreSQL Operator
Run your own production-grade PostgreSQL-as-a-Service on Kubernetes!
The Crunchy PostgreSQL Operator automates and simplifies deploying and managing open source PostgreSQL clusters on Kubernetes and other Kubernetes-enabled Platforms by providing the essential features you need to keep your PostgreSQL clusters up and running, including:
PostgreSQL Cluster Provisioning
Create, Scale, & Delete PostgreSQL clusters with ease, while fully customizing your Pods and PostgreSQL configuration!
High-Availability
Safe, automated failover backed by a distributed consensus based HA solution. Uses Pod Anti-Affinity to help resiliency; you can configure how aggressive this can be! Failed primaries automatically heal, allowing for faster recovery time.
Disaster Recovery
Backups and restores leverage the open source pgBackRest utility and includes support for full, incremental, and differential backups as well as efficient delta restores. Set how long you want your backups retained for. Works great with very large databases!
Monitoring
Track the health of your PostgreSQL clusters using the open source pgMonitor library.
PostgreSQL User Management
Quickly add and remove users from your PostgreSQL clusters with powerful commands. Manage password expiration policies or use your preferred PostgreSQL authentication scheme.
Upgrade Management
Safely apply PostgreSQL updates with minimal availability impact to your PostgreSQL clusters.
Advanced Replication Support
Choose between asynchronous replication and, for workloads that are sensitive to losing transactions, synchronous replication
Clone
Create new clusters from your existing clusters with a simple pgo clone
command.
Connection Pooling
Use pgBouncer for connection pooling
Node Affinity
Have your PostgreSQL clusters deployed to Kubernetes Nodes of your preference
Scheduled Backups
Choose the type of backup (full, incremental, differential) and how frequently you want it to occur on each PostgreSQL cluster.
Backup to S3
Store your backups in Amazon S3 or any object storage system that supports the S3 protocol. The PostgreSQL Operator can backup, restore, and create new clusters from these backups.
Multi-Namespace Support
You can control how the PostgreSQL Operator leverages Kubernetes Namespaces with several different deployment models:
- Deploy the PostgreSQL Operator and all PostgreSQL clusters to the same namespace
- Deploy the PostgreSQL Operator to one namespaces, and all PostgreSQL clusters to a different namespace
- Deploy the PostgreSQL Operator to one namespace, and have your PostgreSQL clusters managed acrossed multiple namespaces
- Dynamically add and remove namespaces managed by the PostgreSQL Operator using the
pgo create namespace
and pgo delete namespace
commands
Full Customizability
The Crunchy PostgreSQL Operator makes it easy to get your own PostgreSQL-as-a-Service up and running on Kubernetes-enabled platforms, but we know that there are further customizations that you can make. As such, the Crunchy PostgreSQL Operator allows you to further customize your deployments, including:
- Selecting different storage classes for your primary, replica, and backup storage
- Select your own container resources class for each PostgreSQL cluster deployment; differentiate between resources applied for primary and replica clusters!
- Use your own container image repository, including support
imagePullSecrets
and private repositories
- Bring your own trusted certificate authority (CA) for use with the Operator API server
- Override your PostgreSQL configuration for each cluster
Deployment Requirements
The PostgreSQL Operator is validated for deployment on Kubernetes, OpenShift, and VMware Enterprise PKS clusters. Some form of storage is required, NFS, hostPath, and Storage Classes are currently supported.
The PostgreSQL Operator includes various components that get deployed to your
Kubernetes cluster as shown in the following diagram and detailed
in the Design section of the documentation for the version you are running.
The PostgreSQL Operator is developed and tested on CentOS and RHEL linux platforms but is known to run on other Linux variants.
The Crunchy PostgreSQL Operator is tested on the following Platforms:
- Kubernetes 1.13 - 1.15 (See note about 1.16 and beyond)
- OpenShift 3.11+
- Google Kubernetes Engine (GKE), including Anthos
- VMware Enterprise PKS 1.3+
NOTE: At present, while the Crunchy PostgreSQL Operator has compatibility for Kubernetes 1.16 and beyond, it has not been verified for the v4.2.0 release.
Storage
The Crunchy PostgreSQL Operator is tested with a variety of different types of Kuberentes storage and Storage Classes, including:
- Google Compute Engine persistent volumes
- HostPath
- NFS
- Rook
- StorageOS
and more.
We know there are a variety of different types of Storage Classes available for Kubernetes and we do our best to test each one, but due to the breadth of this area we are unable to verify PostgreSQL Operator functionality in each one. With that said, the PostgreSQL Operator is designed to be storage class agnostic and has been demonstrated to work with additional Storage Classes.
Installation
PostgreSQL Operator Installation
The PostgreSQL Operator provides a few different methods for installation.
For an automated deployment using Ansible playbooks, please start here:
For a step by step customer installation using Bash, please start here:
For a quick start deployment using OperatorHub.io, please see instructions here:
For a quick start deployment to Google Kubernetes Engine (GKE), please see instructions here:
pgo
Client Installation
If you have the PostgreSQL Operator installed in your environment, and are interested in installation of the client interface, please start here:
There is also a pgo-client
container if you wish to deploy the client directly to your Kubernetes environment.
Using the PostgreSQL Operator
If you have the PostgreSQL and Client Interface installed in your environment and are interested in guidance on the use of the Crunchy PostgreSQL Operator, please start here:
Contributing to the Project
Want to contribute to the PostgreSQL Operator project? Great! We've put together
as set of contributing guidelines that you can review here:
If you want to learn how to get up your development environment, please read our
documentation here:
Once you are ready to submit a Pull Request, please ensure you do the following:
- Reviewing the contributing guidelines and ensure your
that you have followed the commit message format, added testing where
appropriate, documented your changes, etc.
- Open up a pull request based upon the guidelines. If you are adding a new
feature, please open up the pull request on the
master
branch. If you have
a bug fix for a supported version, open up a pull request against the supported
version branch (e.g. REL_4_1
for 4.1)
- Please be as descriptive in your pull request as possible. If you are
referencing an issue, please be sure to include the issue in your pull request
Submitting an Issue
Please use GitHub to submit an issue for the PostgreSQL Operator project.
If you would like to work the issue, please add that information in the issue so that we can confirm we are not already working no need to duplicate efforts.
If you have any question you can submit a Support - Question and Answer issue and we will work with you on how you can get more involved.
Complete Documentation
For additional information regarding design, configuration and operation of the
PostgreSQL Operator, pleases see the
Official Project Documentation
If you are looking for the nightly builds of the documentation, you can view it at:
https://crunchydata.github.io/postgres-operator/latest
Past Versions
Documentation for previous releases can be found at the Crunchy Data Access Portal