Platform components and operations
This reference guide provides detailed information about the various components and operations that make up Mission Control. Use this guide to understand the purpose of each component and to troubleshoot issues when they arise.
Platform architecture
Mission Control consists of several key components that deploy as Kubernetes pods, organized into deployments and stateful sets. Each component pod has a specific role in the platform’s operation, and this guide covers:
The platform components work together to provide a complete database management solution:
-
The
mission-control-operator,cass-operator, andk8ssandra-operatorpods form the control plane, managing the lifecycle of database clusters and their components. For detailed information about how these operators interact with the control plane and data plane, see Control plane and data plane operators. For information about required service account permissions, see Service account permissions. -
The
uianddexpods provide the user interface and authentication services, allowing users to interact with the platform. -
The observability stack includes
loki,mimir, andaggregatorpods for collecting and storing metrics and logs from all platform components and database nodes. For information about configuring and sizing the observability components, see Observability metrics. -
The database management components include
medusaandreaperfor providing backup, restore, and repair capabilities for database clusters.
Mission Control deploys these components in its namespace, while it deploys database clusters in separate namespaces. The platform components communicate with each other and with database clusters through the Kubernetes API.
Platform components
The platform components form the foundation of the Mission Control platform, with each component running as one or more Kubernetes pods. You must understand their roles and requirements for effective platform management and troubleshooting.
Quick reference
The following table provides a quick reference for each platform component, including their purpose, common issues, and documentation. For detailed information about operator architecture and troubleshooting, see Control plane and data plane operators.
| Component | Purpose | Common issues | Documentation |
|---|---|---|---|
|
Custom resource (CR) management |
|
|
|
Apache Cassandra® operations |
|
|
|
K8ssandra operations |
|
|
|
Metrics collection |
|
|
|
Web interface and REST API |
|
|
|
Authentication service |
|
|
|
Log aggregation |
|
|
|
Metrics storage |
|
|
|
Metrics aggregation and forwarding with Vector |
|
|
|
Backup and restore |
|
|
|
Repair management |
|
Detailed component information
The following sections provide detailed information about each platform component, including their roles, configuration options, and common issues.
Control plane components
The control plane components manage the lifecycle of database clusters and their resources. These operators work together to handle cluster creation, configuration changes, and ongoing operations.
For detailed information about operator architecture, responsibilities, and interactions between the control plane and data plane, see Control plane and data plane operators.
mission-control-operator
The Mission Control operator manages custom resources and orchestrates cluster operations across multiple Kubernetes clusters. It runs in the control plane namespace and coordinates multi-datacenter operations.
Common issues include reconciliation failures and resource quota problems.
Review the operator logs in the mission-control-operator pod for specific errors and verify that the service account has the necessary permissions as described in the Service account permissions documentation.
cass-operator
The cass-operator manages the lifecycle of Apache Cassandra®, DataStax Enterprise (DSE), and Hyper-Converged Database (HCD) datacenters.
It runs in each data plane cluster and directly manages database pods and resources.
Common issues include pod reconciliation failures and resource quota problems.
Review the operator logs in the cass-operator pod for specific errors and check resource quotas.
Verify that the service account has the necessary permissions as described in the Service account permissions documentation.
k8ssandra-operator
The k8ssandra-operator manages K8ssandra cluster resources and coordinates multi-datacenter configurations.
It runs in each data plane cluster and manages auxiliary services like Medusa, Reaper, and Stargate.
Common issues include reconciliation failures and resource creation problems.
Review the operator logs in the k8ssandra-operator pod for specific errors and verify that the service account has the necessary permissions as described in the Service account permissions documentation.
User interface components
The ui component provides the web interface and REST API for Mission Control.
The UI service handles user authentication, cluster management, and monitoring through a web-based interface. It also exposes a REST API for programmatic access to Mission Control functionality.
Common issues include service availability problems and resource quota issues. Review the UI service logs for specific errors and check resource quotas. Verify that the service account has the necessary permissions as described in the Service account permissions documentation.
If you cannot access the UI service, check the pod status and logs for errors. Ensure that you properly configured the service and that all dependencies are available. Monitor the service through the Mission Control dashboards to identify any issues early. If issues persist, contact IBM Support for assistance.
Authentication components
The dex component provides authentication services for Mission Control.
Dex handles user authentication and authorization, supporting various authentication methods including:
-
Static credentials
-
LDAP
-
OAuth2
-
OpenID Connect
Common issues include authentication failures and resource quota problems. Review the Dex service logs for specific errors and check resource quotas. Verify that the service account has the necessary permissions as described in the Service account permissions documentation.
If you encounter authentication issues, check the Dex configuration and ensure that you properly configured all authentication providers. Monitor the service through the Mission Control dashboards to identify any issues early. If issues persist, contact IBM Support for assistance.
|
The KOTS Admin Console and Mission Control UI use separate authentication systems. The KOTS Admin Console (accessed through local proxy on port 8800 or through Ingress) manages the Mission Control installation, configuration, licensing, and upgrades, while the Mission Control UI (accessed through Ingress) provides the database management interface for cluster operations. You can change Mission Control UI passwords through KOTS. After you make changes, restart the Dex pod to apply them. |
Observability components
The observability components collect, store, and query metrics and logs from all platform components and database nodes.
kube-state-metrics
The kube-state-metrics component monitors the state of various Kubernetes resources and makes them available for monitoring and alerting.
Review the metrics logs in the kube-state-metrics pod for specific errors and check resource quotas.
Verify that the service account has the necessary permissions as described in the Service account permissions documentation.
Common issues include collection failures and resource quota problems during high-volume operations.
Resource quota issues can prevent the component from functioning properly, especially when collecting metrics from large clusters. Review the resource quotas in the target namespace and adjust them if necessary. Monitor the metrics collection process through the Mission Control dashboards to identify any issues early. If issues persist, contact IBM Support for assistance.
loki
Loki is the log aggregation system for Mission Control. It collects and stores logs from all platform components and database nodes.
mimir
Mimir is the metrics storage and query system for Mission Control. It provides long-term storage and efficient querying of metrics collected from all platform components and database nodes.
aggregator
The aggregator component controls Vector for metrics aggregation in Mission Control.
It collects metrics from all platform components and database nodes and forwards them to Prometheus.
Database management components
The database management components provide backup, restore, and repair capabilities for database clusters.
Medusa
Medusa is the backup and restore system for Mission Control. It provides point-in-time backup and restore capabilities for database clusters.
For detailed information about Medusa configuration and usage, see Backup and restore.
Reaper
Reaper is the repair management system for Mission Control. It provides automated repair scheduling and execution for database clusters.
For detailed information about Reaper configuration and usage, see Repair management.
Deployment considerations
This section covers important considerations for deploying and managing Mission Control in various environments.
Security context
Configure workloads to comply with security measures:
-
Use non-root user settings
-
Implement read-only file systems where appropriate
-
Manage capabilities according to security requirements
-
Follow the principle of least privilege for service accounts
Performance best practices
Follow these recommendations for optimal performance:
-
Utilize external object storage solutions for long-term data retention
-
Deploy a minimum of two nodes for platform workloads
-
Monitor and adjust resource allocations based on workload
-
Implement proper resource limits and requests
Kubernetes compatibility
Mission Control supports various deployment environments:
-
Bare-metal Kubernetes clusters
-
Cloud-managed Kubernetes services:
-
Amazon EKS
-
Google GKE
-
Azure AKS
-
-
On-premises infrastructure
-
Cloud-based infrastructure
The system is packaged as a Helm chart, allowing for customizable deployments through:
-
KOTS admin console
-
Helm-based tooling
Configuration management
Manage Mission Control configuration through:
-
values.yamlfile for chart and sub-chart settings -
Version-controlled configuration changes
-
Iterative updates and modifications
-
Environment-specific customizations
Component instances and deployment types
The following table lists all component instances and their deployment types.
Components with a -n suffix where n is a number are deployed as multiple instances for high availability and scalability.
For example, loki-backend-0, loki-backend-1, and loki-backend-2 represent three instances of the Loki backend component.
| Component instance | Purpose | Deployment type |
|---|---|---|
|
Platform operator |
Deployment |
|
Apache Cassandra® operator |
Deployment |
|
K8ssandra operator |
Deployment |
|
Log storage backend |
StatefulSet |
|
Log query gateway |
Deployment |
|
Log read operations |
Deployment |
|
Log write operations |
Deployment |
|
Metrics ingestion |
StatefulSet |
|
Metrics compaction |
StatefulSet |
|
Metrics distribution |
Deployment |
|
Alert management |
StatefulSet |
|
Metrics storage gateway |
StatefulSet |
|
Backup cleanup |
Job |
The number of instances for StatefulSet components is determined by the configuration in the Helm values. For more information about configuring these components, see Observability metrics.
