How It Works
Configuration Approach
Mission Control manages configuration primarily through Custom Resource Definitions (CRDs). While a postgres database serves as the ultimate source of truth, Kubernetes operators ensure continuous synchronization between the CRDs and the database. By using the database as the source of truth Mission Control provides the best of both worlds.
CRD's are great for:
- GitOps
- Decentralizing configuration, reducing the need for teams to coordinate
- Bundling health checks, topologies into application Helm charts
- Secure lookup of secret values
Layering the database on top enables:
- High performance - ETCD is optimized for consistency over performance, while mission control works well with eventually consistent configuration
- Escape hatches to create configuration via a UI/API
Mixing CRDs and UI Editing
Configuration created by CRD's is readonly from the UI/API. You can mix and match at the configuration item level, but cannot change the mode once created.
Mission Control uses Kubernetes Custom Resources Definitions as the underlying configuration method. The CRD's include:
| Resource | Description | Output |
|---|---|---|
ScrapeConfig | Configures scrapers to run periodically | Config items, analysis, change, cost |
| Canary | Runs health checks using HTTP, SQL, S3, kubectl, etc. | 1 or more checks (Health) |
| Notification | Sends notifications based on events | Email, Slack, etc |
| Playbook | Defines playbooks that can be run on config items, health checks and components | Pull Request, CLI, Webhook |
| Connection | Re-usable connections with secure external lookup to Kubernetes secrets, configmaps, service accounts and Helm values | URL, username, password, etc |
| Topology | Combines configs, health checks and lookups to form cards | Component |
Glossary
- Config Item
- A physical item with some underlying configuration e.g.
Pod,VM,File,Database - Changes
- Changes in the underlying configuration of a config item, or external events that occur on them
- Insights
- Recommendations and analysis provided by third parties through scanning and AI
- Relationships
- Links between config items based upon how they are logically related and categorized
- Component
- A logical entity that often corresponds 1-1 with a config item, but not always e.g.
Pod,Finance Application - Health
- The RAG (Red, Amber, Green) status of a component or config item e.g. Healthy, Unhealthy, Warning
- Scrape
- Connecting to an external API and ingesting data from it
- Playbook
- A sequence of automated steps performed on a config item or component
- Canary
- A definition for how to perform a health check, Canaries produce one or more checks
- Check
- The output of a Canary (Health Check) that includes Health, Latency, and other runtime details
- Topology
- The arrangement and interconnection of various components and config items within the system
- Webhook
- An HTTP-based callback that allows real-time updates
- Custom Resource Definition (CRD)
- An extension mechanism in Kubernetes that enables users to define their own object types
- GitOps
- Method for operating software declaratively using Git with automatic pulling and continuous reconciliation