Skip to content
Homelab

Longhorn and CloudNativePG

Phase 6. Risk: medium, storage disruption is possible. Stateful workloads depend on both.

Longhorn

Section titled “Longhorn”

Pin: helm:https://charts.longhorn.io/longhorn@X.Y.Z in workloads/cdk8s.yaml, then regenerate imports.

Before syncing: every volume healthy, none degraded or faulted. No V2 data-engine volumes in use.

Terminal window
just synth && git push
kubectl get nodes.longhorn.io -n longhorn-system
kubectl get volumes.longhorn.io -n longhorn-system \
  -o custom-columns=NAME:.metadata.name,STATE:.status.state,ROBUST:.status.robustness
kubectl get engineimages -n longhorn-system   # new image deployed on every node

Volume engines upgrade live, one per node at a time (concurrentAutomaticEngineUpgradePerNodeLimit: 1 in longhorn.go). A strict-local volume such as ollama needs a detach before its engine moves.

CloudNativePG

Section titled “CloudNativePG”

Pins in config/versions.yaml: charts.cloudnative-pg (operator) and images.n8n-postgres (the n8n-pg operand). Operator upgrades are backwards-compatible with existing Cluster CRs. An operand bump within one PostgreSQL major is a rolling restart; a major bump is not.

Terminal window
kubectl get cluster -A   # every cluster healthy

n8n-pg is a single instance with no scheduled backup. Take a pg_dump first — see n8n.