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. This ensures that any changes required for new or changed Kubernetes API’s are already present.

Page Contents

Prerequisites

DKP Upgrade with Insights Installed

If your environment has Insights installed, you must uninstall Insights BEFORE upgrading DKP. For an overview of the upgrade workflow, see Upgrade Insights.

Prerequisites for Configurations with NVIDIA GPU Nodes

If your cluster is running GPU nodes and has deployed the nvidia Platform Application, you must run additional steps prior to upgrading Kommander. In DKP 2.4, the nvidia application is replaced by nvidia-gpu-operator during upgrade, and the configuration for the new application must be created prior to the upgrade to ensure that the new application is deployed with the proper configuration, or it may not deploy successfully. If your cluster is not running GPU nodes, then skip these steps and proceed directly to the Upgrade Kommander section.

  1. Create the ConfigMap with the necessary configuration overrides to set the correct Toolkit version. For example, if you’re using Centos 7.9 or RHEL 7.9 as the base operating system for your GPU enabled nodes, set the toolkit.version parameter:

    cat <<EOF | kubectl apply -f -
    apiVersion: v1
    kind: ConfigMap
    metadata:
      namespace: kommander
      name: nvidia-gpu-operator-overrides
    data:
      values.yaml: |
        toolkit:
          version: v1.10.0-centos7
    EOF
    CODE
  2. Create an AppDeployment named nvidia-gpu-operator in the kommander namespace:

    cat <<EOF | kubectl apply -f -
    apiVersion: apps.kommander.d2iq.io/v1alpha3
    kind: AppDeployment
    metadata:
      name: nvidia-gpu-operator
      namespace: kommander
    spec:
      appRef:
        name: nvidia-gpu-operator
        kind: ClusterApp
      configOverrides:
        name: nvidia-gpu-operator-overrides
    EOF
    CODE
  3. You may now proceed to the Kommander upgrade steps.

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:

      dkp upgrade kommander --charts-bundle ./application-charts/dkp-kommander-charts-bundle-v2.4.0.tar.gz --kommander-applications-repository ./application-repositories/kommander-applications-v2.4.0.tar.gz
      CODE
    2. For air-gapped with DKP Catalog Applications in a multi-cluster environment:

      dkp upgrade kommander --charts-bundle ./application-charts/dkp-kommander-charts-bundle-v2.4.0.tar.gz --charts-bundle ./application-charts/dkp-catalog-applications-charts-bundle-v2.4.0.tar.gz --kommander-applications-repository ./application-repositories/kommander-applications-v2.4.0.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. 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
  3. 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.