CNPG - Cloud Native Postgresql - Pilot

Moving from Traditional Postgres to CNPG (Cloud Native Postgres)

Rising hosting costs and the desire to stay current with modern technologies prompted a significant shift in my lab cloud setup. The main goal was to reduce expenses while exploring newer tools. A key part of this plan involved moving as much workload as possible from traditional virtual machines to my existing, well-running Kubernetes cluster, which already hosts around 18 applications with plenty of capacity to spare.

Immediate Priorities

Two quick wins stood out:

Retire the dedicated database server
Move the Puppet-managed Nagios server onto an existing web server

Looking further ahead, I plan to migrate web services to Kubernetes, replace Nagios with Zabbix (which also runs nicely in Kubernetes), switch from Jenkins to GitLab CI, and give Prometheus another try in the cluster.

Thanks to the growing ecosystem of Kubernetes operators, managing complex services has become much smoother. The end result should be roughly half the number of servers—and significantly lower costs.

First Step: Moving to CNPG

Last year, I experimented with a standard Postgres container, but the results were disappointing. Performance lagged behind my VM-based setup, and I was limited to a single instance. In contrast, the VM environment delivered solid performance and allowed near-complete management through Puppet.

The new objectives for the CNPG migration were clear:

Run Postgres natively in Kubernetes
Manage everything through CI/CD and GitOps
Deploy a 3-node cluster
Enable straightforward database migrations
Implement reliable backups
Improve internal transport security via the Kubernetes network (even though everything was already TLS-secured in a private network)
Optionally expose database services to external applications

This migration took several days and required careful attention to several key areas: