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.

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 and access method comparison
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

  • Eliminates the need to learn YAML syntax or Kubernetes concepts

  • Quick provisioning with sensible defaults

  • Streamlined interface reduces complexity

  • Catches configuration errors with built-in validation

  • Provides real-time feedback on cluster status

  • Ideal for straightforward cluster deployments

  • Does not support automation

  • Does not automatically version control changes

  • Requires UI access and authentication

  • Does not expose all advanced configuration options

  • Limited to basic cluster configurations

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

  • Exposes configuration options for advanced use cases

  • Provides visual interface for complex configurations

  • Catches configuration errors with built-in validation

  • Provides real-time feedback on cluster status

  • Allows fine-grained control over cluster settings

  • Supports advanced production requirements

  • Does not support automation

  • Does not automatically version control changes

  • Requires UI access and authentication

  • Requires understanding of YAML and Kubernetes concepts for advanced configurations

Programmatic workflow

Direct interaction with Kubernetes API using kubectl, GitOps tools (Argo CD, Flux), or API clients

No UI (CLI/GitOps/IaC): Fully programmatic workflow that bypasses the UI entirely for automated deployments and version-controlled infrastructure

  • Enables full automation capabilities

  • Maintains version control for all infrastructure changes

  • Defines configuration as code

  • Integrates with CI/CD pipelines

  • Ensures consistent, repeatable deployments

  • Creates audit trail through Git history

  • Supports GitOps practices

  • Removes UI dependency

  • Provides complete control over all configuration options

  • Requires knowledge of Kubernetes and YAML

  • Needs manual validation of manifest syntax

  • Requires setup of GitOps tooling (optional)

  • Requires appropriate RBAC permissions

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

Was this helpful?

Give Feedback

How can we improve the documentation?

© Copyright IBM Corporation 2026 | Privacy policy | Terms of use |  Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: Contact IBM