Skip to main content
This section assumes you’re already familiar with the RegattaDB software modules (SM, SNA, GDD, DCM, Sequencer, RDB) and how they work together in a RegattaDB deployment.
The Regatta operator is a Kubernetes controller that automates deploying and operating RegattaDB on Kubernetes. Instead of manually creating the Kubernetes resources RegattaDB needs, provisioning its storage, and issuing System Manager (SM) commands yourself, you describe the RegattaDB deployment you want in a single RegattaCluster resource and let the operator drive Kubernetes and RegattaDB into that state.

​
Kubernetes Concepts You Will Use

​
What the operator does for you

  • Describes your deployment as a single Kubernetes resource: the RegattaCluster resource captures the RegattaDB version, image, module settings, storage, and resource sizing you want.
  • Creates and maintains the Kubernetes resources RegattaDB needs: StatefulSets, Services, ConfigMaps, and storage claims, generated and kept in sync automatically.
  • Configures and starts RegattaDB for you: once Kubernetes resources are ready, the operator configures RegattaDB modules and starts or stops RegattaDB through the System Manager (SM).
  • Reports readiness continuously: Kubernetes and RegattaDB health are reflected in the RegattaCluster status, so you always know the current state.

​
Deployment Architecture

In a manual or RDT-driven RegattaDB deployment, you decide which node runs which modules: one SM, one SNA on every node that hosts an operational module, one GDD, one DCM, one Sequencer, and one or more RDB modules. On Kubernetes, a Pod is the unit that runs one or more RegattaDB modules together, the same role a node plays in a manual deployment. The operator places modules for you, using the following default layout:
RegattaDB Kubernetes Pod layoutRegattaDB Kubernetes Pod layout
Unlike a manual deployment, you do not choose per-Pod module placement here. The operator uses this default layout; the only placement decision you make today is how many RDB replicas to configure. Each Pod also gets one or more stable Kubernetes Services, giving it a fixed network address, similar to assigning a fixed internal IP address to each node in a manual deployment. The SM Pod has one Service, and every RDB Pod has its own dedicated Service, so its address does not change even if Kubernetes moves the Pod to a different Kubernetes node. A Kubernetes node is a physical or virtual machine in your Kubernetes cluster. It is a different concept from the node used in manual RegattaDB deployment guides: a single Kubernetes node can run many Pods at once, including Pods belonging to other applications, and Kubernetes decides which node each Pod runs on and can move a Pod to a different node later. You do not assign RegattaDB modules to specific Kubernetes nodes yourself, though you can influence which Kubernetes nodes the operator’s Pods are eligible to run on using standard scheduling controls; see Schedule Pods.

​
How this section is organized

  • Prerequisites and Installation: what your cluster needs, and how to install the operator.
  • Configuration: the RegattaCluster spec reference, covering the object header, version and image, module settings, storage, networking, security and lifecycle, and resources and scheduling.
  • Examples: end-to-end walkthroughs, from a single-node quickstart to static RDB storage.
  • Operations: how the operator keeps Kubernetes and RegattaDB in sync, reading status, and making supported changes.
  • Troubleshooting and Release Notes.

​
Next steps

New to the Regatta operator? Start with Prerequisites and Installation, then follow the Quickstart: Single-Node RegattaCluster to deploy RegattaDB end to end.