Upgrade Kommander

This section describes how to upgrade your Kommander Management cluster and all Platform Applications to their supported versions in networked, 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, due to the previous versions’ incompatibility with 1.22.

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 on DKP version 2.2 or higher and Kubernetes version 1.22 or higher.

If you are on DKP 2.1 or older, you must upgrade to DKP 2.2 before upgrading to 2.3.

• If you have attached clusters, ensure they are on Kubernetes versions 1.22 or higher.

• Review the Platform Application version updates that are part of this upgrade.

• For air-gapped environments with DKP Catalog Applications in a multi-cluster environment: Load the Docker images into your Docker registry

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

• For air-gapped environments only:

Download the Kommander application definitions:

wget "https://downloads.d2iq.com/dkp/v2.3.1/kommander-applications-v2.3.1.tar.gz"

Download the Kommander charts bundle:

wget "https://downloads.d2iq.com/dkp/v2.3.1/dkp-kommander-charts-bundle-v2.3.1.tar.gz"

If you have any DKP Catalog Applications, download the DKP Catalog Application charts bundle:

wget "https://downloads.d2iq.com/dkp/v2.3.1/dkp-catalog-applications-charts-bundle-v2.3.1.tar.gz"

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.

The Fluentbit application, which is responsible for collecting admin level logs, is automatically disabled on upgrade to v2.3.1. To keep Fluentbit enabled on your clusters, you will need to pass in the new --disable-appdeployment flag set to "". You must ensure there is sufficient storage for these logs if you keep it enabled. See Fluent Bit for more information.

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:

      dkp upgrade kommander --charts-bundle dkp-kommander-charts-bundle-v2.3.1.tar.gz --kommander-applications-repository kommander-applications-v2.3.1.tar.gz

      CODE

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

      dkp upgrade kommander --charts-bundle dkp-kommander-charts-bundle-v2.3.1.tar.gz --charts-bundle dkp-catalog-applications-charts-bundle-v2.3.1.tar.gz --kommander-applications-repository kommander-applications-v2.3.1.tar.gz

      CODE

      After the upgrade, follow the DKP Catalog Applications configuration page to update the Git repository.

   3. For networked:

      dkp upgrade kommander

      CODE

      If you have DKP Catalog Applications deployed, follow the DKP Catalog Applications configuration page to update the Git repository after the upgrade.
      
      The output looks similar to this:

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

      CODE

2. For air-gapped deployments, an additional step is required to upgrade the Grafana Loki MinIO Tenant:

   kubectl patch statefulset grafana-loki-minio-ss-0 -n kommander --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"quay.io/minio/minio:RELEASE.2022-01-08T03-11-54Z"}]'

   CODE

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

   dkp upgrade kommander -v 6

   CODE

   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}]'

   CODE

4. 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.
   For Essential customers (single-cluster environment): Proceed with the Konvoy Upgrade.

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