Percona Operator for PostgreSQL 2.0.0 (Tech preview)¶
-
Date
December 30, 2022
-
Installation
The Percona Operator is based on best practices for configuration and setup of a Percona Distribution for PostgreSQL on Kubernetes. The benefits of the Operator are many, but saving time and delivering a consistent and vetted environment is key.
Note
Version 2.0.0 of the Percona Operator for PostgreSQL is a tech preview release and it is not recommended for production environments. As of today, we recommend using Percona Operator for PostgreSQL 1.x, which is production-ready and contains everything you need to quickly and consistently deploy and scale PostgreSQL clusters in a Kubernetes-based environment, on-premises or in the cloud.
The Percona Operator for PostgreSQL 2.x is based on the 5.x branch of the Postgres Operator developed by Crunchy Data. Please see the main changes in this version below.
Architecture¶
Operator SDK is now used to build and package the Operator. It simplifies the development and brings more contribution friendliness to the code, resulting in better potential for growing the community. Users now have full control over Custom Resource Definitions that Operator relies on, which simplifies the deployment and management of the operator.
In version 1.x we relied on Deployment resources to run PostgreSQL clusters, whereas in 2.0 Statefulsets are used, which are the de-facto standard for running stateful workloads in Kubernetes. This change improves stability of the clusters and removes a lot of complexity from the Operator.
Backups¶
One of the biggest challenges in version 1.x is backups and restores. There are two main problems that our user faced:
- Not possible to change backup configuration for the existing cluster
- Restoration from backup to the newly deployed cluster required workarounds
In this version both these issues are fixed. In addition to that:
- Run up to 4 pgBackrest repositories
- Bootstrap the cluster from the existing backup through Custom Resource
- Azure Blob Storage support
Operations¶
Deploying complex topologies in Kubernetes is not possible without affinity and anti-affinity rules. In version 1.x there were various limitations and issues, whereas this version comes with substantial improvements that enables users to craft the topology of their choice.
Within the same cluster users can deploy multiple instances. These instances are going to have the same data, but can have different configuration and resources. This can be useful if you plan to migrate to new hardware or need to test the new topology.
Each postgreSQL node can have sidecar containers now to provide integration with your existing tools or expand the capabilities of the cluster.
Try it out now¶
Excited with what you read above?
- We encourage you to install the Operator following our documentation.
- Feel free to share feedback with us on the forum or raise a bug or feature request in JIRA.
- See the source code in our Github repository.
