Skip to main content

​
How the operator keeps things in sync

After you apply a RegattaCluster resource, the operator continuously works to bring Kubernetes and RegattaDB into the state you described:
  1. It creates or updates the StatefulSets, Services, ConfigMaps, and Secret your RegattaCluster resource requires.
  2. It waits until the storage your Pods requested is bound, and every Pod is running and ready.
  3. Once Kubernetes is ready, it configures and starts, or stops, RegattaDB through the System Manager (SM), using the Service addresses Kubernetes created.
  4. It writes what it observed, including readiness, endpoints, and RegattaDB health, back into your RegattaCluster resource’s status, and repeats this cycle so any drift is corrected automatically, at least every five minutes even without any change.
Kubernetes objects being healthy is necessary but not sufficient: your RegattaCluster resource only reports readiness once RegattaDB itself confirms, through the System Manager, that it is active and healthy.

​
Reading RegattaCluster status

status is owned by the operator; never edit it yourself. Useful fields:
  • status.observedGeneration: the most recent spec generation the operator has reconciled. If this lags behind metadata.generation, the operator has not caught up yet.
  • status.endpoints.sm and status.endpoints.rdbs[]: the Service names, DNS names, ClusterIPs, and ports the operator advertised to RegattaDB. RegattaDB clients and management tools should use these addresses from status; spec never contains live connection addresses, only your desired configuration.
  • status.rdb: desiredReplicas, readyPods, configuredReplicas, and activeReplicas - how many RDB Pods exist, are ready, are configured in RegattaDB, and are active.
  • status.modules: per-module role summaries (total/active/down), as RegattaDB itself reports them.
  • status.devices: raw block device health, with a status, a healthy flag, a failed list of device names that are not healthy, and an items[] list. Each item includes the device’s name, path, node, and module.
  • status.regatta: the raw System Manager observation, including systemState, healthy, desiredState, and recent actions.

​
Conditions

status.conditions follows the standard Kubernetes condition shape (type, status, reason, message):
Ready=True always requires both Kubernetes readiness and SM-confirmed RegattaDB health together; Kubernetes readiness alone is never enough.

​
Making supported changes

Once your RegattaCluster resource exists, a small set of fields remain mutable, though some have side effects worth planning for:
  • spec.image (tag, digest, pullPolicy, pullSecrets), as long as spec.version stays the same. The operator applies this as a same-version rolling update - see Configure Version And Image for what that means and what you can/cannot control.
  • config on any module. Note that changing it restarts the Pod or Pods that host the affected module.
  • spec.rdb.service.type and spec.rdb.service.port (the aggregate RDB Service’s own type and exposed port) only affect that Service object. RDB’s actual container port stays fixed, and Kubernetes forwards the externally exposed port to it correctly, so both are always safe to change.
  • spec.lifecycle.start: set to false to stop RegattaDB while keeping Kubernetes Pods running, and back to true to start it again.
Every other field covered in Configuration, including spec.version, spec.rdb.replicas, spec.rdb.devices, module port/service_port/num_threads/ram_MB, and every storage setting, is immutable once your RegattaCluster resource is created.

​
Deleting a RegattaCluster

Delete the resource like any other Kubernetes object:
Deletion:
  1. Makes a bounded attempt, up to 30 seconds, to stop RegattaDB through the System Manager if it is running.
  2. Continues even if that stop attempt fails, recording a warning Event instead of blocking.
  3. Deletes the generated StatefulSets, Services, ConfigMaps, and the credentials Secret.
  4. Leaves every PersistentVolumeClaim in place, so your data is not deleted along with the RegattaCluster resource.
If you are certain the data is no longer needed, delete the retained PVCs explicitly: