The rise of cloud-native technologies
As the importance of scalability, efficiency and cost savings rises, cloud-native technologies are increasingly in demand by organizations. In addition to traditional infrastructure such as virtual machines and bare metal servers, many companies are seeing more modern solutions such as Kubernetes.
The flexibility and maintainability offered by Kubernetes make it easy to deploy and customize applications, provided you have the right helmet charts and tooling. Especially when it comes to databases such as Postgres, we consider containerized deployments on Kubernetes to be an advanced and efficient approach.
It has a small footprint and can be extended to include PostGIS and TimescaleDB, for example. While some customers are already familiar with this approach, others have yet to be convinced with solid arguments and Proof-of-Concepts.
Kubernetes in production: It can be done!
We get the question whether Postgres in Kubernetes is suitable for use in a production environment. And if! We successfully performed such an implementation for a customer of ours in the maritime sector. The company was already operational with Crunchy Postgres containers, but was looking for extended support for Postgres.
This was prior to the development of the Crunchy operator. The customer asked us to provide support for their Postgres containers and to establish a solid backup and recovery solution. We accomplished this by applying logical replication from the containers in Kubernetes to two Postgres instances on virtual machines.
The Challenges
The number of Postgres containers, or applications using a Postgres pod, grew from just a few to several dozen. Workloads vary widely from application to application, with some focused on analytical tasks and others on online transaction processing (OLTP). In addition, the size of the pods can vary significantly, ranging from a few gigabytes to hundreds of gigabytes. With this logical replication setup, we had to overcome the following challenges:
- The application life cycle, with Postgres containers being restarted regularly.
- The size of particular Postgres containers and the time required for initial synchronization of data via logical replication.
- Specific extensions such as PostGIS and TimescaleDB used by the client’s applications required extra attention during the initial configuration of logical replication.
Postgres Kubernetes Operator
To address these challenges, we recommended that our client implement a Postgres Kubernetes Operator to address those challenges and cumbersome maintenance.
Prior to this choice, we conducted a thorough analysis of the three most relevant options: Zalando’s Postgres Kubernetes operator, Crunchy data operator and EDB’s Cloud Native PostgreSQL operator. In addition to these 3 options, there are other Kubernetes operators emerging (which are also getting better and better) including those from Percona, StackGres and Cybertec but these are not yet relevant in terms of technology compared to the 3 already mentioned and best known. We have considered cost, support, ease of use, flexibility, documentation and – as far as can be determined – market share.
Why choose EDB’s Cloud Native PostgreSQL Operator?
In the end, we chose EDB’s Cloud Native PostgreSQL Operator because of its comprehensive support, ease of use and future-proofing. Let’s take a closer look at that. When choosing an operator, it is very important to look not only at the current situation, but also at the future.
With the most relevant options in mind, we were convinced that in the long run the EDB Cloud Native PostgreSQL (CloudNativePG) would be the most comprehensive and future-proof choice in general and for this project in particular. Important factors that contributed to this decision were:
- Enterprise-grade support from EDB, along with an extensive partner network.
- A well-thought-out operator that meets project requirements.
- Support for bidirectional replication, a unique feature of this operator.
- Vertical scalability capabilities.
- Use of the Enterprise Monitor, providing a unified view of all clusters and nodes, both within Kubernetes (k8s) and on Infrastructure-as-a-Service (IaaS) platforms.
Benefits of EDB’s Cloud Native PostgreSQL Operator.
The main advantages of this operator are the fast deployment of cluster setups, Also, deploying a pgbouncer setup is a wash. The state fullness that provides (almost) true High Availability (the operator ensures that the cluster is always rendered as defined), and the CloudNative Postgres Plugin (CNP) that simplifies the management of Postgres clusters on Kubernetes.
The major challenges in running databases in Kubernetes
Running databases in Kubernetes initially presented significant challenges.
These changes were not easy and required close collaboration with our client. Implementing an explanatory model and moving from traditional scripts to helmet-charts required a significant mindset change.
An additional challenge was the lack of an EDB-supported image with the necessary PostGIS and TimescaleDB extensions at that time. PostGIS is now included by default. Although configuration options such as nodes, node pools, taint and affinity were available, it required experimentation to find the optimal settings.
Setting up effective monitoring and alerting systems and getting the right statistics into the dashboards also proved challenging. Fortunately, the dashboards that came with the operator provided a solid starting point. It was also important to consider resource limits on nodes running resource-intensive pods.
CloudNativePG as open-source-software
CloudNativePG was originally built by EDB and then decided to make it available as open source software, under Apache license 2.0. Opening up the software encourages greater involvement from the community, which will only make the operator stronger. The Cloud Native PostgreSQL operator is a valuable addition to the open source landscape.
Learn more?
Want to know more about how to implement Kubernetes Operators for your databases? With the improvements of ‘persistent storage’ in Kubernetes and the evolution of ‘orchestrators’ for all kinds of databases such as MySQL – with or without Galera – and Postgres, we can advise our customers optimally. Feel free to Contact us.