GitHub
07/01/2026, 1:44 PMgpinitsystem — coordinator, standby, segments, and mirrors, all provisioned declaratively from a single YAML
• Horizontal scale-up: patch spec.segments.count, the operator provisions new pods and redistributes data automatically
• Two SSH trust models: static keypair for dev/CI, certificate mode for production (per-cluster CA, short-lived certs, annotation-driven rotation without pod restarts)
• Declarative postgresql.conf and pg_hba.conf management via DatabaseConfig
• High availability out of the box: standby coordinator (WAL streaming, auto-promoted on failure) and mirror segments (one mirror per primary, auto-recovered via gprecoverseg)
• On-demand backups to S3-compatible storage via gpbackup, with cross-cluster restore support
• Phase-driven lifecycle: PodsStarting → SSHReady → Initializing → Running, with the operator reconciling continuously from there
• Admission webhook that catches errors at the API boundary — cluster name length, HA node availability, invalid CRD references — before anything reaches a pod
• Helm install, cert-manager for webhook TLS, Kubernetes 1.29+
Why I built it: Standing up a Cloudberry cluster is operationally heavy — SSH trust, gpinitsystem, segment registration, mirror setup, replication wiring. Keldon automates all of it so you can go from zero to a running MPP cluster without touching any of it manually.
What I'm looking for:
1. Are there use cases or deployment patterns in the community I haven't accounted for?
2. Anything in the way Keldon models clusters that conflicts with how you think about Cloudberry architecture?
3. If you get a chance to try it, I'd love to hear what breaks — missing features / bug to fix
Repo: github.com/keldonio/keldon-operator
Docs: keldon.io/docs
Happy to answer questions or take direction on anything missing.
— Imad
apache/cloudberry