Skip to main content

How It Works

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:

ResourceDescriptionOutput
ScrapeConfig
Configures scrapers to run periodicallyConfig items, analysis, change, cost
Canary
Runs health checks using HTTP, SQL, S3, kubectl, etc.1 or more checks (Health)
Notification
Sends notifications based on eventsEmail, Slack, etc
Playbook
Defines playbooks that can be run on config items, health checks and componentsPull Request, CLI, Webhook
Connection
Re-usable connections with secure external lookup to Kubernetes secrets, configmaps, service accounts and Helm valuesURL, username, password, etc
Topology
Combines configs, health checks and lookups to form cardsComponent

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