How platform applications work

When attaching a cluster, DKP deploys certain platform applications on the newly attached cluster. Operators can use the DKP UI to customize which platform applications to deploy to the attached clusters in a given workspace.

Currently, the monitoring stack is deployed by default. The logging stack is not.

Review the workspace platform application resource requirements to ensure that the attached clusters have sufficient resources.

When deploying and upgrading applications, platform applications come as a bundle; they are tested as a single unit and you must deploy or upgrade them in a single process, for each workspace. This means all clusters in a workspace have the same set and versions of platform applications deployed.

Customize a workspace’s applications

You can customize the applications that are deployed to a workspace’s clusters using the DKP UI:

  1. From the top menu bar, select your target workspace.

  2. Select Applications from the sidebar menu to browse all applications that can be deployed or uninstalled.

To use the CLI to deploy or uninstall applications, see Application Deployment

There may be dependencies between the applications, which are listed in the Workspace Platform Application Dependencies documentation. Review them carefully prior to customizing to ensure that the applications are deployed successfully.

Upgrade Platform applications from the CLI

The DKP upgrade process deploys and upgrades Platform applications as a bundle for each cluster or workspace. For the Management Cluster or workspace, DKP upgrade handles all Platform applications; no other steps are necessary to upgrade the Platform application bundle. However, for managed or attached clusters or workspaces, you MUST manually upgrade the Platform applications bundle with the following command.

If you are upgrading your Platform applications as part of the DKP upgrade, upgrade your Platform applications on any additional Workspaces before proceeding with the Konvoy upgrade. Some applications in the previous release are not compatible with the Kubernetes version of this release, and upgrading Kubernetes is part of the DKP Konvoy upgrade process.

Use this command to upgrade all platform applications in the given workspace and its projects to the same version as the platform applications running on the management cluster:

dkp upgrade workspace WORKSPACE_NAME
CODE

An output similar to this appears:

✓ Ensuring HelmReleases are upgraded on clusters in namespace "WORKSPACE_NAME"
...
CODE

If the upgrade fails or times out, retry the command with higher verbosity to get more information on the upgrade process:

dkp upgrade workspace WORKSPACE_NAME -v 4
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 <WORKSPACE_NAMESPACE> patch helmrelease <HELMRELEASE_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/suspend", "value": true}]'
kubectl -n <WORKSPACE_NAMESPACE> patch helmrelease <HELMRELEASE_NAME> --type='json' -p='[{"op": "replace", "path": "/spec/suspend", "value": false}]'
CODE