New in Radar: Complete CloudNativePG Operations

If you run PostgreSQL on Kubernetes with CloudNativePG, answering "which database needs attention, why, and what do I do about it" usually means stitching together a dozen CRD lists, kubectl cnpg status for each cluster, the operator's logs and a Grafana dashboard.

Radar now does that stitching. Since v1.16 it has a CloudNativePG workspace: the fleet, backups, declared databases and roles, poolers and the operator, read straight from the cluster. v1.17 adds the operations: create, restore, back up, switch over, fence, hibernate and more. You review each one before it runs, and Radar follows it until the cluster shows the outcome.

All of it is in Radar OSS, the free Apache-2.0 binary that runs on your laptop and installs nothing in the cluster.

Here's a one-minute tour on a test cluster:

The fleet: which Postgres cluster needs attention

The Clusters view lists every CloudNativePG cluster you can see, worst first. Each row shows readiness, replication, storage and backups, and names its top problem in words. You can tell an instance that can't be scheduled from a backup schedule that has nowhere to write without opening anything. Needs attention narrows the list to clusters with a real problem on the Cluster, its instance Pods, its Jobs, or an object that points at it.

Opening the Cluster kind from anywhere in Radar (search, a favorite, a link from Issues) lands on this view. Next to it: Backups across all clusters, Declarations (Databases, roles, publications and subscriptions, declared versus actually applied), Pooling for PgBouncer Poolers, and Operator, which shows whether CloudNativePG itself is healthy. If the operator isn't reconciling, every cluster page says so before showing any status, because that status may be stale.

One page per cluster, organized by task

Each cluster's page has a tab per job: Overview, Replication, Storage, Performance, Backups, Activity, Logs and Configuration. Four health marks follow you across tabs: Serving next to the name, and a dot on Replication, Storage or Backups when something there needs a look.

• Replication has a card per instance: role, timeline, streaming state, and how far each standby is behind, in bytes. We don't use PostgreSQL's replay_lag for that. It reads zero for a standby that's receiving nothing, so it can't tell you a standby is caught up.
• Storage shows volumes and usage, what is holding WAL on disk, and resize.
• Performance shows sessions and connection headroom, the tree of which backend is blocking which (with cancel and terminate), per-database health, and history charts. The charts come from Prometheus when it scrapes the CNPG exporter. Without Prometheus, Radar samples while the page is open.
• Logs merges all instances into one stream, with role labels and CNPG's JSON log levels parsed.
• Configuration has PostgreSQL parameters as declared and as each instance reports them, certificates and their expiry, and Connect: every address with copy-ready psql and port-forward commands. The password stays a placeholder, because Radar never reads the Secret.

Backups: could you actually restore, and to when?

This is the part we spent the most time on, because CloudNativePG's own status is easy to misread here.

kubectl get clusters.postgresql.cnpg.io shows the phase, and "Cluster in healthy state" says nothing about backups. A cluster can have failed every WAL archive attempt for weeks and still list as healthy. Worse, a cluster with no backup destination at all reports ContinuousArchiving=True with "Continuous archiving is working". CloudNativePG's archive command succeeds when there's nowhere to send the WAL, so the condition can't fail.

So the Backups view keeps each fact separate, each with where it came from:

• the schedule, and whether it can actually run
• the destination
• the last successful backup, from whichever source has the newest one
• WAL archiving, judged from the spec as well as the condition
• the recovery window
• restore validation

Restore validation never shows green. Kubernetes keeps no record of restore tests, so the most Radar can show is a note someone recorded after checking a restored cluster: who, when, and what they checked.

From the same tab, Set up backups walks through attaching an existing Barman Cloud ObjectStore, creating or fixing a matching schedule, then checking that WAL uploads resumed and a new base backup completed. Saving the configuration alone never counts as protected. Restore to a new cluster starts from a cluster, a Backup or an ObjectStore. You pick the latest point, a point in time, or the end of a backup, and Radar shows what that source actually holds. A target outside that evidence gets a warning, not a block. Every create and restore runs a server dry-run before anything is written.

Operations you review before they run

The operations: back up now, switchover, rolling or single-instance restart, reload, fence and lift fence, hibernate and rehydrate, node maintenance, ScheduledBackup suspend, resume and run now, Pooler pause and resume, cancelling or terminating a blocking backend, and replacing a fenced standby.

Each one opens a review first. It leads with the effect in plain words and keeps the exact API write one click away. For disruptive actions, like a switchover, fencing the primary or hibernating a cluster, you type the cluster's name to confirm.

A few things happen behind that dialog:

• The request carries what you reviewed: the kube context, the cluster's UID, the current and target primary, the fence state. The server reads them again and refuses if anything changed in between. Nothing is retried automatically.
• Unsafe targets are refused. Radar won't fence or restart the instance an in-flight switchover is promoting, or an instance whose Pod says primary while the cluster status names another.
• Writes use your identity, not Radar's. Radar impersonates the caller, so Kubernetes RBAC decides what you can do.
• GitOps is checked first. If Argo CD, Flux or Helm manages the field being written, the review says whether the next sync is likely to revert it.

An accepted request isn't a finished operation. The cluster header follows each one until the cluster reports the outcome: requested, progressing, then completed, failed, stalled or unobservable. For a switchover, completed means the target is primary, the old primary is streaming again and the read-write Service points at the new one. If Radar can't see a step, the operation stays unobservable. It's never marked completed on faith.

For the rest of an incident there's a report bundle, shaped like kubectl cnpg report cluster, with Secret values never read and credentials redacted from everything else.

Unknown is never shown as healthy

We hold every screen to one rule: show what the cluster reports, labelled with its source, and when something can't be read, say so. Never show zero, "none" or green in its place.

• A standby whose lag can't be read is "lag unknown", not caught up.
• If some namespaces can't be read, counts show as a lower bound (≥3), not a total.
• A section you don't have access to names the permission it needs instead of looking empty.

Radar uses your own Kubernetes permissions throughout. Live instance data (replication, slots, WAL, sessions) comes through pods/proxy from each instance manager and the PostgreSQL exporter. psql and the blocking view need pods/exec. Without those permissions, those parts say what's missing and the rest of the page still works.

What it doesn't do

• Destinations other than Barman Cloud. Barman Cloud (the plugin and the in-tree version) and volume snapshots are covered. Other backup plugins aren't modelled.
• Provisioning. Radar doesn't create object storage or credentials, or install the Barman Cloud plugin.
• Shared operation history. The operation tracker lives in your browser tab. It isn't a team-wide record.
• More than one cluster at a time. Like the rest of Radar OSS, these views show the Kubernetes cluster you're connected to.

Try it

brew install skyhook-io/tap/radar
radar

You need Radar v1.17.0 or newer. The CloudNativePG views appear in the Resources sidebar when the postgresql.cnpg.io CRDs are installed. The CloudNativePG docs go through each view and the permissions behind it.

If Radar shows a cluster as healthy or protected when you can prove it isn't, please open an issue on GitHub.