Choose your workflow
Mission Control provides multiple workflows and access methods to accommodate different use cases, organizational requirements, and deployment practices. This guide helps you understand the available options and choose the best approach for your needs.
Installation versus cluster management
Installing Mission Control and managing database clusters are separate activities. You install Mission Control once on a Kubernetes cluster to establish the control plane and data plane infrastructure. After installation, you use Mission Control to deploy and manage database clusters on an ongoing basis.
Mission Control manages clusters through the Kubernetes API using a declarative model. You declare the desired state of a cluster in a custom resource, and the Mission Control operators reconcile the actual state to match. If you use the Mission Control UI to make changes, Mission Control internally updates the underlying custom resources, so all modifications remain declarative regardless of how you interact with the system. Mission Control does not require agents on managed clusters to perform this reconciliation. Instead, operators running in each data plane cluster watch for custom resource changes and execute operations locally. Mission Control requires no persistent outbound connections, no agent installation on database nodes, and no polling from a central management server. This is a fundamental difference from agent-based tools like DSE OpsCenter and similar infrastructure management platforms.
When the control plane is unavailable, existing clusters continue running unaffected.
The cass-operator in each data plane continues to reconcile datacenter-level resources independently, though multi-datacenter operations and changes to K8ssandraCluster resources are unavailable until the control plane recovers.
Workflow and access method comparison
Mission Control supports both UI-based and programmatic workflows for production environments. Most Mission Control testing occurs with direct Kubernetes API interaction. Both workflows use the same underlying Kubernetes API and custom resources, ensuring consistent behavior and functionality.
The following table compares the available workflows, access methods, and cluster creation modes:
| Workflow | Access method | Cluster creation mode | Advantages | Considerations |
|---|---|---|---|---|
UI workflow |
Web-based interface that generates and submits YAML manifests to the Kubernetes API |
UI Simple Mode: Simplified interface with sensible defaults for development, testing, and quick provisioning |
|
|
UI workflow |
Web-based interface that generates and submits YAML manifests to the Kubernetes API |
UI Expert Mode: Full-featured interface that exposes configuration options |
|
|
Programmatic workflow |
Direct interaction with Kubernetes API using |
No UI (CLI/GitOps/IaC): Fully programmatic workflow that bypasses the UI entirely for automated deployments and version-controlled infrastructure |
|
|
Choose your workflow
Consider the following factors when you choose your workflow:
- Organizational practices
-
Choose the programmatic workflow if your organization uses GitOps, infrastructure-as-code, or has strict change management requirements.
- Deployment environment
-
Choose the programmatic workflow for production deployments to gain better automation, testing, and rollback capabilities. Choose either workflow for development and testing based on team preferences.
- Team expertise
-
Choose the programmatic workflow if your team is familiar with Kubernetes and YAML. Choose the UI workflow if your team is new to Kubernetes or prefers visual tools.
- Automation requirements
-
Choose the programmatic workflow if you need to automate cluster provisioning, scaling, or configuration changes.
- Compliance and audit requirements
-
Choose the programmatic workflow with Git-based version control if your organization requires detailed audit trails and change approval processes.
Workflow flexibility
You can use both workflows for different purposes:
-
Use the UI to explore features and create initial clusters
-
Export cluster configurations as YAML for version control
-
Use the programmatic workflow for production deployments
-
Switch between workflows as your needs evolve
Both workflows interact with the same Kubernetes API, so you can manage clusters created through one method with the other method.
Next steps
-
To install Mission Control, see Choose an installation method.
-
For UI-based cluster creation, see Access Mission Control’s UI and Provision a database cluster
-
For programmatic cluster creation, see Infrastructure as Code (IaC) and GitOps workflows
-
To understand cluster lifecycle operations, see Administer database clusters
-
For custom resource reference documentation, see Mission Control Custom Resource Definition (CRD) reference
