EDB Postgres for Kubernetes is a Kubernetes Operator for Postgres written by EDB entirely from scratch in the Go language and relying exclusively on the Kubernetes API.
The reason behind this choice stands on an important 3-word concept: Immutable Application Containers.
Declarative configuration
EDB Postgres for Kubernetes consists of a Kubernetes manifest that can be downloaded from the documentation for the operator. The manifest is just a YAML file.
Our Kubernetes offering uses a declarative configuration approach to deploying software rather than an imperative one. By focusing on a DevOps mindset, we were challenged to define the desired state of the PostgreSQL cluster; not a list of steps or changes to be executed in sequence.
Application vs System containers
Another important aspect of our offering is that it builds immutable application containers with a minimal operating system to produce the smallest and lightest images possible. Container image builds are directly integrated into our Continuous Delivery pipeline from the commit phase to publishing on Quay.io.
You might be asking: “You mentioned immutable application containers. What are they?”
An application container is designed to run a single main entry point process such as PostgreSQL. This is in contrast to a system container, in which multiple services are running at the same time (such as PostgreSQL, SSH, Syslog, and so on). System containers are similar to traditional virtual machines or physical servers, but they tend not to fit well in Kubernetes (or at least, this is what we believe).
As a result, our application containers do not require the root user to run or access the storage, reducing the risk of exploits and privilege escalation incidents. This allows us to implement important Pod Security Policies (PSP) in our systems such as non-privileged mode for containers and volume access via security contexts.
Immutability
Another important property of our application containers is that they are also immutable, meaning that they are shipped with a given version of the stack and they cannot be updated using “yum update” or “apt upgrade”, for example. An update means a new container image. In Kubernetes terms, PostgreSQL is an application, and every PostgreSQL minor release has its own immutable container image.
Kubernetes has been designed to work with immutable application containers and to perform deployments and/or updates of such applications in a rolling fashion without downtime. Persistent volumes allow us to reuse the same PGDATA files.
Designed for Kubernetes
Choosing a declarative approach and immutable application containers means that our EDB Postgres for Kubernetes product can only work with Kubernetes and, most importantly, in Kubernetes.
This is an important difference in views between our operators and the existing ones currently available as open source. Consider for example that, in order to manage high availability and automated failover, we do not use tools that have been designed for virtual machine or bare metal deployments like Patroni, Stolon, or repmgr.
We’ve decided to rely on Kubernetes only. We have made the Cloud Native choice.
About our operator
EDB Postgres for Kubernetes works with PostgreSQL and EDB Postgres Advanced, and is available under the EnterpriseDB Limited Use License.
Our PostgreSQL container image is freely available on GitHub and downloadable from Quay.io. This containerized version of PostgreSQL can be used with an implicit license key for up to 30 days with our Kubernetes Operator.
EDB also publishes container images for EDB Postgres Advanced Server on Quay.io, which can also be managed by the EDB Postgres for Kubernetes Operator. You can request a 60 day trial license from EDB’s website.
EDB Postgres for Kubernetes is also available on Red Hat OpenShift.
More Blogs
Release Radar: EDB Postgres® AI Q3 Release Highlights
This blog was co-authored by Tim Boutin, Dave Stone, Lizzy Nguyen, and Simon Notley. There’s a lot of energy at EDB following the Q2 announcement of EDB Postgres AI, an...