This guide is intended for DKP Enterprise Edition, but the mechanism is the same for other editions.
This guide was tested on d8 v0.17.1.
The guide uses the third-party utility crane to analyze the container registry. Install it first following the official instructions.
Platform update mechanism using release channels
Deckhouse Kubernetes Platform (DKP) updates are based on release channels.
You can check which release channel is configured for your DKP installation
in the deckhouse
ModuleConfig by running the following command:
d8 k get mc deckhouse -o jsonpath='{.spec.settings.releaseChannel}'
Example output:
Stable
Technically, a DKP update works as follows: the registry contains an image with a fixed name release-channel
and a tag corresponding to the release channel.
This tag points to an image of a specific DKP version (when a new version is released,
the tag is updated to point to the new image).
Let’s examine the contents of a DKP Enterprise Edition image with the alpha
release channel.
To do that, run the following command:
crane export registry.deckhouse.io/deckhouse/ee/release-channel:alpha | tar -tf -
The output contains a list of files and directories in the image:
changelog.yaml
version.json
.werf
.werf/stapel
.werf/tmp
.werf/tmp/ssh-auth-sock
The image contains two key files:
changelog.yaml
: Describes changes.-
version.json
: Contains data about the release canary deployment (canary
), requirements (requirements
), disruptions (disruptions
) (deprecated field), and the release version itself in theversion
field.To view the contents of
version.json
, run the following command:crane export registry.deckhouse.io/deckhouse/ee/release-channel:alpha | tar -xOf - version.json | jq
Example contents of
version.json
:{ "canary": { "alpha": { "enabled": true, "waves": 2, "interval": "5m" }, "beta": { "enabled": false, "waves": 1, "interval": "1m" }, "early-access": { "enabled": true, "waves": 6, "interval": "30m" }, "stable": { "enabled": true, "waves": 6, "interval": "30m" }, "rock-solid": { "enabled": false, "waves": 5, "interval": "5m" } }, "requirements": { "k8s": "1.29", "disabledModules": "delivery,l2-load-balancer,ceph-csi", "migratedModules": "", "autoK8sVersion": "1.31", "ingressNginx": "1.9", "nodesMinimalOSVersionUbuntu": "18.04", "nodesMinimalOSVersionDebian": "10", "istioMinimalVersion": "1.19", "metallbHasStandardConfiguration": "true", "unmetCloudConditions": "true", "nodesMinimalLinuxKernelVersion": "5.8.0" }, "disruptions": { "1.36": [ "ingressNginx" ] }, "version": "v1.71.5" }
When the version
field changes in version.json
in the registry, DKP applies a new release in the cluster:
a deckhouserelease
object is created and the update process begins.
If the deckhouse
module is set to manual update mode (via the settings.update.mode
field),
you need to manually approve the new version before it is applied.
If there is a gap between the minor version running in the cluster and the one in the release-channel
image,
DKP will automatically attempt to reconstruct intermediate deckhouserelease
objects to perform a sequential update.
Note that DKP can’t be updated non-sequentially by skipping minor releases (patch releases are not affected). Minor releases often include migrations that must be applied in order. These migrations may be removed over time. Skipping minor releases may result in:
- Leftover “garbage”
- Cluster malfunction due to missed migrations
Module update mechanism
Modules have a similar update mechanism, but their release cycle is decoupled from the platform and fully independent.
The cluster contains ModuleSource resources tracked by DKP, which determine the list of available modules.
To see from which repository modules will be installed, run the following command:
d8 k get ms deckhouse -o jsonpath='{.spec.registry.repo}'
Example output:
registry.deckhouse.io/deckhouse/ee/modules
You can view repository contents with the following command:
crane ls registry.deckhouse.io/deckhouse/ee/modules
Example output:
commander-agent
console
csi-ceph
csi-nfs
observability
operator-postgres
pod-reloader
prompp
sds-local-volume
sds-node-configurator
sds-replicated-volume
secrets-store-integration
snapshot-controller
stronghold
virtualization
As an example, let’s look at the contents of the console
module image.
The registry contains an image with the fixed name release
and a tag for the channel,
pointing to a specific version of the console
module (when a new module version is released, this tag is updated).
To view the contents of this image, use the following command:
crane export registry.deckhouse.io/deckhouse/ee/modules/console/release:alpha | tar -tf -
Example output:
changelog.yaml
version.json
Similarly to the DKP image, the module image contains the changelog.yaml
and version.json
files.
To view the contents of version.json
, run the following command:
crane export registry.deckhouse.io/deckhouse/ee/modules/console/release:alpha | tar -xOf - version.json | jq
Example contents of version.json
:
{
"version": "v1.39.4"
}
The version
field contains the module version.
When it changes, DKP applies a new release (a modulerelease
object is created and the update process begins).
Note that modules can’t be updated non-sequentially by skipping minor releases (patch releases are not affected). Minor releases often include migrations that must be applied in order. These migrations may be removed over time. Skipping minor releases may result in:
- Leftover “garbage”
- Cluster malfunction due to missed migrations
If required minor versions are missing,
DKP will report an error that may look as follows: minor version is greater than deployed $version by one
.
If there is a gap between the minor version running in the cluster and the one in the release
image,
DKP will automatically attempt to reconstruct intermediate modulerelease
objects to perform a sequential update.
Vulnerability scanner database update mechanism
Available in DKP Enterprise Edition.
Vulnerability databases are updated every 6 hours.
The operator-trivy
module in the cluster downloads them from the registry once during this period.
Vulnerability database images in DKP EE have fixed names and tags and are available at:
registry.deckhouse.io/deckhouse/ee/security/trivy-db:2
registry.deckhouse.io/deckhouse/ee/security/trivy-java-db:1
registry.deckhouse.io/deckhouse/ee/security/trivy-checks:0
To configure periodic updates of vulnerability database images, run the command in the following format:
d8 mirror pull --source='registry.deckhouse.io/deckhouse/ee' --license='YOUR_LICENSE_TOKEN' --no-platform --no-modules $(pwd)/d8-bundle-security-db && d8 mirror push $(pwd)/d8-bundle-security-db YOUR_PRIVATE_REGISTRY_HOSTNAME:5050/dkp/ee --registry-login='YOUR_REGISTRY_LOGIN' --registry-password='YOUR_REGISTRY_PASSWORD' --tls-skip-verify
Example workflow for updating the platform, modules, and vulnerability databases
To update DKP, its modules, and vulnerability databases to the latest versions in an air-gapped environment, download the latest patch releases of all required platform minor versions and modules, then upload them to your registry.
Running d8 mirror pull --source='registry.deckhouse.io/deckhouse/ee' --license='YOUR_LICENSE_TOKEN' $(pwd)/d8-bundle
downloads all release channel images and all modules (over 30 in DKP EE).
This results in a very large d8-bundle
(at the time of writing, the volume of the d8-bundle
directory is more than 50 GB).
To avoid this, download only the images relevant to your version following these guidelines:
-
Get the DKP version in your cluster using the following command:
d8 k -n d8-system get deployment deckhouse -o json | jq -r '.metadata.annotations | {"core.deckhouse.io/edition","core.deckhouse.io/version"}'
Example output:
{ "core.deckhouse.io/edition": "EE", "core.deckhouse.io/version": "v1.68.13" }
-
Get the list of modules deployed in the cluster:
d8 k get mr | grep Deployed
Example output:
commander-agent-v1.2.4 Deployed 13d console-v1.35.1 Deployed 7d4h
Add this list to the
d8 mirror pull
command as flags:--include-module='commander-agent@v1.2.4' --include-module='console@v1.35.1'
Alternatively, use a one-liner:
d8 k get mr -o json | jq -r '.items[] | select(.status.phase == "Deployed") | "--include-module='\''\(.spec.moduleName)@\(.spec.version)'\''"' | paste -sd " " -
-
Create the final command for pulling images with the obtained parameters:
d8 mirror pull --source='registry.deckhouse.io/deckhouse/ee' --license='YOUR_LICENSE_TOKEN' --since-version='v1.68.13' --include-module='commander-agent@1.2.4' --include-module='console@1.35.1' $(pwd)/d8-bundle
If you have already set up periodic downloading and pushing of vulnerability databases to your registry, you can add the flag
--no-security-db
to skip them during this process.This will download the latest patch releases of all required platform minor versions and modules, starting from the latest patch versions up to the current ones on release channels.
-
Push the artifacts to your registry using the following command:
d8 mirror push $(pwd)/d8-bundle YOUR_PRIVATE_REGISTRY_HOSTNAME:5050/dkp/ee --registry-login='YOUR_REGISTRY_LOGIN' --registry-password='YOUR_REGISTRY_PASSWORD' --tls-skip-verify
-
Check the update status in the cluster by running the following commands:
d8 k get deckhousereleases.deckhouse.io d8 k get modulereleases.deckhouse.io d8 system queue list
Possible issues
Release is suspended
When trying to download platform images with d8 mirror pull d8-bundle/ --license='YOUR_LICENSE_KEY'
,
you may encounter the following error:
Sep 9 00:10:57.145 INFO ╔ Pull Deckhouse Kubernetes Platform
Sep 9 00:11:01.532 ERROR Pull Deckhouse Kubernetes Platform failed error="Find tags to mirror: Find versions to mirror: get stable release version from registry: Cannot mirror Deckhouse: source registry contains suspended release channel \"stable\", try again later"
Error: pull failed, see the log for details
This means that release deployment on a channel has been suspended.
This happens when a new version is pushed to the release channel but then something happened that paused its rollout.
The channel image is patched with a suspend
flag.
Nevertheless, you can still download the platform version by specifying the --deckhouse-tag
flag in d8 mirror pull
.
For example:
d8 mirror pull d8-bundle/ --license='YOUR_LICENSE_KEY' --deckhouse-tag='v1.71.3'
Example output:
Sep 16 12:56:25.074 INFO ╔ Pull Deckhouse Kubernetes Platform
Sep 16 12:56:25.713 INFO ║ Skipped releases lookup as tag "v1.71.3" is specifically requested with --deckhouse-tag
Sep 16 12:56:25.714 INFO ║ Creating OCI Image Layouts
Sep 16 12:56:25.720 INFO ║ Resolving tags
Sep 16 12:56:26.715 INFO ║╔ Pull release channels and installers
Sep 16 12:56:26.716 INFO ║║ Beginning to pull Deckhouse release channels information
Sep 16 12:56:26.717 INFO ║║ [1 / 1] Pulling registry.deckhouse.io/deckhouse/ee/release-channel:v1.71.3
Sep 16 12:56:27.087 INFO ║║ Deckhouse release channels are pulled!
Sep 16 12:56:27.087 INFO ║║ Beginning to pull installers
Sep 16 12:56:27.087 INFO ║║ [1 / 1] Pulling registry.deckhouse.io/deckhouse/ee/install:v1.71.3
...