CloudNativePG: A New Open-Source Kubernetes Operator for Postgres | Hacker News Reader

CloudNativePG: A New Open-Source Kubernetes Operator for Postgres

enterprisedb.com

Disclaimer - I'm one of the maintainers of the project

Thanks for sharing the news!

The project is hosted on github.com/cloudnative-pg/cloudnative-pg and it is distributed under Apache License 2.0.

It manages PostgreSQL primary/standby architecture clusters, providing self-healing, high availability through automated failover, continuous backup, point-in-time recovery, native Prometheus exporter, JSON standard output logging, rolling updates, and so on.

It relies on the Kubernetes API server to keep the status of the cluster, detect issues/changes, and react.

It is production ready, originally created by EDB, which is one of the major contributors to the open source PostgreSQL project.

There are a lot of Postgres operators. Wondering if a CNCF endorsement would place it as the “by default” operator to use. Could this reasoning be extended to other databases and stateful applications?

The sandbox submission is not an endorsement from CNCF. It only demonstrates the willingness of the maintainer to create a community-driven, vendor-neutral software following the guidelines defined by CNCF.

Disclaimer: I'm one of the maintainers.

The project has just been submitted to the CNCF Sandbox, it hasn't yet been accepted. There's a lot of road to be done. If we get accepted, we'll be honoured to adapt and contribute to the project until incubation.

However, what is important here though is that this is the first operator for Postgres whose IP is now owned by a vendor neutral and openly governed community - or at least aims to be based on the public GOVERNANCE policies. We look upon the CNCF for principles and values.

This is our commitment.

There is a need to standardize operators. Not only to streamline their usage, but also to ensure quality or at least give the community guidelines on what are the best practices to follow when building or using an operator.

That’s probably something the CNCF community should define.

There's definitely commonalities between operators for databases, not only with the same engine, but also different ones and similar primary/standby architecture.

I agree this is something we could somehow work together as a standard kind of spec, but probably we are still at an early stage of the process. My 2 cents.

Agree. Monitoring is a great example. Every DBMS server needs monitoring and it should be exportable to Prometheus. But the commonality ends pretty much ends there, at least in my experience. That's just single instances, too, not complex clusters.

That's another good example of why CNCF is important, as in that ecosystem live technologies that are becoming standard for everything related to infrastructure, including monitoring and alerting. Prometheus is an example, Open Telemetry is another one. When you are able to "interface" with one of these components, you've done your integration job.

From a Postgres standpoint, IMO, it is also important the concept of cluster - as that's what applications connect too - the operator hides the underlying complexity of managing the single instances. And .. also important monitoring sets of clusters from an infrastructure management PoV.

Can you please elaborate on this: "Could this reasoning be extended to other databases and stateful applications?"?

Operators seem like a mandatory element for a lot of stateful applications to be working. MySQL, Kafka, OpenEBS, Cassandra… all need an operator to ensure day-2 operations.

I am just wondering if CNCF could provide signals that could help end users pick the right operator among the many out there. They could start with the projects they have in their landscape…

Got it. That's an interesting point of view. I think it makes sense in the data workloads, especially in the database one. Consider for example how database workloads are still lagging behind in Kubernetes, and - most importantly - viceversa (Kubernetes is a hard topic IMO for traditional DBAs).

Operators are there to help in both cases, and this is the goal of our CloudNativePG operator.

IMO CNCF represents an opportunity for vendors of the same database engine to converge in a healthy community and provide the best operator for their platform. This is probably the first stage.

The second stage could be to study those operators (of different engines, like Postgres, MySQL, ...) and generalize commonalities in a sort of standard spec. Just an idea. Is this in line with what you are thinking?

Thanks!

Reply on news.ycombinator.com