Upgrade Mission Control using the embedded runtime

You can upgrade Mission Control to the latest version using the embedded runtime to take advantage of new features and improvements.

Upgrading Mission Control is an incremental process designed to minimize downtime of components. DataStax recommends that you schedule upgrades during low-activity periods, avoid scheduling new backup jobs during the upgrade window, and pause long-running repair operations before you start the upgrade.

Run an upgrade only on a single control plane or a data plane at any given time. You must upgrade all data plane clusters first, and then proceed to upgrade the control plane.

In-service upgrade considerations

Different deployment architectures might exhibit different behaviors during upgrades. In-service upgrades of Mission Control affect the following components and features.

System availability

The Mission Control UI remains accessible throughout the upgrade process with no downtime. The upgrade process ensures service continuity during component updates. If enabled, Grafana dashboards remain accessible during the upgrade.

Vector continues collecting logs during the upgrade, with log collection resuming immediately after component restart. If enabled, Loki remains available for log queries during the upgrade, with the gateway service remaining accessible even if individual Loki components restart. If enabled, Mimir continues storing metrics during the upgrade with individual components restarting independently while maintaining metrics collection through component transitions. The system does not lose data during the upgrade process.

Background operations

If enabled, backup and repair operations can be temporarily affected during the upgrade. The system tracks progress and automatically retries operations when possible. Existing backups remain intact and accessible throughout the upgrade process.

Cluster operations

You must upgrade all data plane clusters first, and then proceed to upgrade the control plane. Upgrading one datacenter doesn’t affect other datacenters, and data replication continues normally between datacenters during upgrades. Inter-datacenter communication remains functional.

Database clusters continue running normally during the Mission Control upgrade. The system might temporarily make cluster management operations unavailable during the upgrade, while monitoring and health checks continue throughout the process.

Performance considerations

The upgrade process might temporarily increase resource usage on management nodes, including CPU and memory consumption, additional network traffic during component updates, and temporary increases in disk I/O during component restarts and updates.

Known issues and limitations

Based on testing and customer feedback, the following known issues apply to embedded runtime upgrades.

Container registry limitations

Container registries in embedded runtime installations impose specific limitations that affect upgrade operations. You must ensure that Medusa, Reaper, and the cqlsh container repositories all reside within the same registry server. You cannot override the registry for each container individually.

This limitation is resolved in versions 1.15.0 and later.

Resource limitations

Several resource limitations affect embedded runtime upgrades. CRD upgrade and patch jobs do not support setting resource limits, which might affect performance in resource-constrained environments. Security context defaults do not specify SecCompProfile, which might require you to configure this manually for enhanced security requirements.

Use the embedded runtime to upgrade Mission Control

After you select your environment to upgrade, select a Management node for the coordination of upgrade tasks.

Choose one of the following two modes to upgrade the core runtime for Mission Control:

Online upgrade: You perform upgrades with internet access available to the hosts.
Offline upgrade: You perform upgrades without internet access. This is also known as an airgap upgrade.

Online upgrade
Offline (airgap) upgrade

Prerequisites

An existing embedded cluster installation
A valid Mission Control license file and license ID
Internet access on the nodes

Upgrade runtime

Download assets and run the upgrade script on the upgrade coordinator.

Choose one of the Management nodes in your Mission Control installation to be the upgrade coordinator. Initiate and run the upgrade process on this host.

Download the installation assets to all the nodes in your cluster:
```
curl -f https://replicated.app/embedded/mission-control/stable/VERSION_NUMBER -H "Authorization: LICENSE_ID" -o mission-control-stable.tgz
```
Replace the following:
- VERSION_NUMBER: Mission Control version number, for example v1.14.0. By default, use latest, or specify a version number, such as v1.14.0, if you need to install a specific version.
- LICENSE_ID: License ID to authenticate the download. The ID is available in your Mission Control license file.
Extract the installation assets:
```
tar xvzf mission-control-stable.tgz
```
Run the following upgrade script on the Management node:
```
sudo ./mission-control update
```
This script pushes images to the registry and creates a new version for deployment.
Result
✔ Application images are ready! ✔ Finished!

Upgrade Mission Control

After you upgrade the core runtime, you can update the Mission Control application.

In the KOTS Admin Console, click Cluster Management. On the Dashboard tab under Version, the system displays the new update version as available.
Click Version history to view the available versions, and then click Deploy.
Complete the options in the Config step, and then click Next.
Complete the options in the Preflight checks step, and then click Next: Confirm and deploy.
Review the changes in the Review and Deploy step, and then click Deploy.

What’s next

With all nodes and the core runtime upgraded, you can continue with accessing Mission Control.