Upgrade Kommander

This section describes how to upgrade your Kommander Management cluster and all Platform Applications to their supported versions in air-gapped, non-air-gapped and on-prem environments. To prevent compatibility issues, you must first upgrade Kommander on your Management Cluster before upgrading to DKP.

It is important you upgrade Kommander BEFORE upgrading the Kubernetes version (or Konvoy version for Managed Konvoy clusters) in attached clusters. This ensures that any changes required for new or changed Kubernetes API’s are already present.

Page Contents

Prerequisites

• REQUIRED Before upgrading, create an on-demand backup of your current configuration with Velero.

• Download and install the supported DKP CLI binary of this release on your computer.

• Ensure you are attempting to run a supported DKP upgrade.

• Ensure you are on Kubernetes version 1.24.x.

• If you have attached clusters, ensure they are on Kubernetes versions 1.24 or later.

• Review the DKP 2.5.0 Components and Applications versions that are part of this upgrade.

• For air-gapped environments with DKP Catalog Applications: Load the Kommander and DKP Catalog Applications Docker images into your Docker registry

• For air-gapped environments with DKP Insights: Load the Kommander, DKP Insights Docker images into your Docker registry

• For air-gapped environments without DKP Catalog Applications: Load the Kommander Docker images into your Docker registry

DKP Upgrade with Insights Installed

If your environment has Insights installed, you must uninstall Insights BEFORE upgrading DKP.

Upgrade Kommander

Before running the following command, ensure that your dkp configuration references the Kommander Management cluster, otherwise it attempts to run the upgrade on the bootstrap cluster. You can do this by setting the KUBECONFIG environment variable to the appropriate kubeconfig file’s location.

If you have configured a custom domain, running the upgrade command could result in an inaccessibility of your services via your custom domain for a few minutes.

As stated earlier, an alternative to initializing the KUBECONFIG environment variable is to use the –kubeconfig=cluster_name.conf flag. This ensures that Kommander upgrades on the workload cluster.

1. Use the DKP CLI to upgrade Kommander and all the Platform Applications in the Management Cluster:

   1. For air-gapped environments:

      CODE

      dkp upgrade kommander --charts-bundle ./application-charts/dkp-kommander-charts-bundle-v2.5.2.tar.gz --kommander-applications-repository ./application-repositories/kommander-applications-v2.5.2.tar.gz

   2. For air-gapped with DKP Catalog Applications in a multi-cluster environment:

      CODE

      dkp upgrade kommander --charts-bundle ./application-charts/dkp-kommander-charts-bundle-v2.5.2.tar.gz --charts-bundle ./application-charts/dkp-catalog-applications-charts-bundle-v2.5.2.tar.gz --kommander-applications-repository ./application-repositories/kommander-applications-v2.5.2.tar.gz

      After the upgrade, if you have DKP Catalog Applications deployed, update the GitRepository for dkp-catalog-applications.

      For the following section, ensure you modify the most recent kommander.yaml configuration file. It must be the file that reflects the current state of your environment. Reinstalling Kommander with an outdated kommander.yaml overwrites the list of platform applications that are currently running in your cluster.

      1. In the kommander.yaml you are currently using for your environment, update the DKP Catalog Applications by setting the correct DKP version:

         CODE

         apiVersion: config.kommander.mesosphere.io/v1alpha1
         kind: Installation
         ...
         # The list of enabled/disabled apps here should reflect the current state of the environment, including configuration overrides!
         ...
         catalog:
           repositories:
             - name: dkp-catalog-applications
               labels:
                 kommander.d2iq.io/project-default-catalog-repository: "true"
                 kommander.d2iq.io/workspace-default-catalog-repository: "true"
                 kommander.d2iq.io/gitapps-gitrepository-type: "dkp"
               path: ./dkp-catalog-applications-v2.5.2.tar.gz # modify this version to match the DKP upgrade version

      2. Refresh the kommander.yaml to apply the updated tarball:
         Before running this command, ensure the kommander.yaml is the configuration file you are currently using for your environment. Otherwise, your previous configuration will be lost.

         CODE

         dkp install kommander --installer-config kommander.yaml

   3. For non-air-gapped environments:

      CODE

      dkp upgrade kommander

      After the upgrade, if you have DKP Catalog Applications deployed, update the GitRepository for dkp-catalog-applications.

      1. Update the GitRepository with the tag of your updated DKP version on the kommander workspace:

         CODE

         kubectl patch gitrepository -n kommander dkp-catalog-applications --type merge --patch '{"spec":{"ref":{"tag":"v2.5.2"}}}'

         This command updates the catalog application repositories for all workspaces.

      2. For any additional workspaces created outside the kommander.yaml configuration:
         Set the WORKSPACE_NAMESPACE environment variable to the namespace of the workspace:

         CODE

         export WORKSPACE_NAMESPACE=<workspace namespace>

      3. Update the GitRepository for the additional workspace:

         CODE

         kubectl patch gitrepository -n ${WORKSPACE_NAMESPACE} dkp-catalog-applications --type merge --patch '{"spec":{"ref":{"tag":"v2.5.2"}}}'

      The output looks similar to this:

      CODE

      ✓ Ensuring upgrading conditions are met
      ✓ Ensuring application definitions are updated
      ✓ Ensuring helm-mirror implementation is migrated to chartmuseum
      ...

2. For Enterprise customers (multi-cluster environment): Upgrade your additional Workspaces on a per-Workspace basis to upgrade the Platform Applications on other clusters than the Management Cluster. After upgrading your Workspaces, proceed with the Konvoy Upgrade.
   For Essential customers (single-cluster environment): Proceed with the Konvoy Upgrade.

Troubleshooting

If the upgrade fails, run the following command to get more information on the upgrade process:

dkp upgrade kommander -v 6

If you find any HelmReleases in a “broken” release state such as “exhausted” or “another rollback/release in progress”, you can trigger a reconciliation of the HelmRelease using the following commands:

kubectl -n kommander patch helmrelease <HELMRELEASE_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/suspend", "value": true}]'
kubectl -n kommander patch helmrelease <HELMRELEASE_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/suspend", "value": false}]'

You can always go back to the DKP Upgrade overview, to review the next steps depending on your environment and license type.