Latest posts from Jonathan S. Katz

We're excited to announce the release of PGO 5.0, the open source Postgres Operator from Crunchy Data. While I'm very excited for you to try out PGO 5.0

I can talk about the benefits of PostgreSQL for application development and operations all day. But there two enduring topics that are close to my heart: SCRAM

We're excited to announce the new version of PGO, the open source Postgres Operator from Crunchy Data version 4.7! There's a lot of really cool features that make it easy to deploy production Postgres clusters on Kubernetes. In this release, we focused on adding enhancements around "Day 2" operations (e.g. PVC resizing), allowing for backups to be stored in Google Cloud Storage

Not too long ago I wrote a blog post about how to deploy TLS for Postgres on Kubernetes in attempt to provide a helpful guide from bringing your own TLS/PKI setup to Postgres clusters on Kubernetes. In part, I also wanted a personal reference for how to do it!

However, some things have changed since I first wrote that post. OpenSSL released a fix for CVE-2021-3450

A recent (well depending on when you read this) Twitter discussion mentioned the topic of creating the quintessential "read-only Postgres user" that can, well, only read info from a database, not write to it. A simple way to handle this case is to create a read-only Postgres replica, but that may not make sense based on your application.

So, how can you simply create a read-only Postgres user (and note that I will use "user" and "role" interchangeably)? Let's explore!

Background: GRANT, REVOKE, ALTER DEFAULT PRIVILEGES

Please Note: This post references an older version of the Crunchy Postgres for Kubernetes. See PGO Documentation for the latest version.

The Crunchy Data team announced the latest release of our open source PostgreSQL Operator for Kubernetes 4.6 a few weeks back. So let's take a whirlwind tour of how we make it easy to run production-quality Postgres on Kubernetes. With this release, we included features to streamline management of the Operator, added security features, and extra system metrics to enhance your high availability Kubernetes Postgres cluster.

Let's take a look at what's new in the Postgres Operator 4.6!

What’s New in Operator 4.6 At a Glance

This post provides guidance for v4x. For the latest on PGO, GitOps and Helm installer, please see: https://github.com/CrunchyData/postgres-operator-examples/tree/main/helm

In the previous article

The desire to use Pod tolerations to schedule Postgres instances sometimes comes up around complex Kubernetes deployments. To address this feedback, we added support for tolerations to the 4.6 release of the Postgres Operator

"GitOps" is a term that I've been seeing come up more and more. The concept was first put forward by the team at Weaveworks as a way to consolidate thought around deploying applications. In essence: your deployment topology lives in your git repository. You can update your deployment information by adding a new commit. Likewise, if you need to revert your system's state, you can rollback to the commit that you want to represent your production environment. Any changes to your deployment topology should be reconciled in your production environment.

A lot of the conversations around GitOps came around the Postgres Operator

TLS allows for the secure transmission of data between systems and is also a requirement of many production environments. Part of setting up TLS is ensuring anything communicating over a network within your system also has TLS. If you are not encrypting traffic between all your endpoints, you open yourself up to snooping.

An earlier post describes how to set up PostgreSQL clusters with TLS on Kubernetes