Enterprise: Upgrade the Management Cluster and Platform Applications

These pages refer to DKP Enterprise and DKP Gov Advanced products.

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.

Upgrade Kommander

Prerequisites

Use the --kubeconfig=${CLUSTER_NAME}.conf flag or set the KUBECONFIG environment variable to ensure that you upgrade Kommander on the right cluster. For alternatives and recommendations around setting your context, refer to Provide Context for Commands with a kubeconfig File.
If you have DKP Insights installed, ensure you uninstall it before upgrading DKP. See DKP Insights Upgrade from DKP 2.5.x to 2.6.0 for more information.

Limited availability of DKP resources

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 DKP UI and other APIs may be inconsistent or unavailable until the upgrade is complete.

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

For non-air-gapped environments

CODE

dkp upgrade kommander

If you want to disable the AI Navigator, add the flag --disable-appdeployments ai-navigator-app to this command.

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
...

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

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.6.2"}}}'

This command updates the catalog application repositories for all workspaces.

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>

Update the GitRepository for the additional workspace:

CODE

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

For air-gapped environments

CODE

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

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
...

For air-gapped environments with DKP Catalog Applications

CODE

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

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
...

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.

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

CODE

...
# 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.6.2.tar.gz # modify this version to match the DKP upgrade version
...

Refresh the kommander.yaml to apply the updated tarball:

Ensure the kommander.yaml is the Kommander Installer Configuration file you are currently using for your environment. Otherwise, your configuration will be overwritten and previous configuration lost.

CODE

dkp install kommander --installer-config kommander.yaml

Troubleshooting

If the upgrade fails, run the following command to get more information on the upgrade process:
CODE
```
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:

CODE

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

Next Step:

Enterprise: Upgrade Platform Applications on Managed and Attached Clusters