This article covers various topics of uninstallation, cleanup, and upgrade of Airlock Microgateway. Note that some instructions in this article are release-dependent because upgrading from Microgateway versions 4.0 and 4.1 to helm-install-based Microgateway 4.2 (and newer) is not possible.
Upgrade from Microgateway 4.1 to 4.2
When changing from any older Airlock Microgateway 4 version to Microgateway 4.2 and newer, you must uninstall the old version first. Except the CRDs and the CNI plugin have been installed via Helm. The following brief sequence describes the upgrade from a Microgatway 4.x release to 4.2 and newer.
Note that the instructions must be performed in the correct order.
- Label all the applications that should be protected with Airlock Microgateway with the new label
sidecar.microgateway.airlock.com/inject=true
. This is necessary because we switched from annotation to label. - Uninstall the Microgateway CNI plugin if it was installed with
kustomize
. - Upgrade the Microgateway CNI plugin. If the CNI plugin was installed with
kustomize
the command ishelm install
instead ofhelm upgrade
. - Uninstall Microgateway deployments. Note that you must not uninstall the CRDs.
- Apply the new license. This is important because the license format changed in Microgateway 4.2.
- Update the CRDs. This will not break your current installation if not noted otherwise in the release notes of the new Microgateway version.
- Install the new Microgateway Operator.
- You can verify the current Pod status by checking the
version
label. To finalize the upgrade process, manually restart all application Pods containing Microgateway Engine sidecars. See Uninstallation and upgrade section in this article.
Adapt the <environment>
part before running the following command:
Uninstalling Microgateway versions 4.0 and 4.1
- Remove the label
sidecar.microgateway.airlock.com/inject
from your applications and make sure they are restarted. - Uninstall Microgateway deployments and the CRDs.
- Uninstall the Microgateway CNI plugin.
If the CNI plugin has been manually installed using kustomize
adapt the <environment>
part before running the following command:
If the CNI plugin has been installed using helm
, run:
Uninstalling Microgateway version 4.2 and newer
Airlock Microgateway 4.2 and newer releases are helm-based and can be uninstalled using helm
commands. However, helm
does not support removing installed CRDs, which requires using kubectl delete
commands to complete the uninstallation process.
- Remove the label
sidecar.microgateway.airlock.com/inject
from your applications and make sure they are restarted. - Uninstall the Microgateway Operator.
- Uninstall the CRDs.
- Uninstall the Microgateway CNI plugin.
Cleanup after installation tests for Microgateway version 4.2 and newer
CNI and operator test pods are not automatically uninstalled after test completion. We recommend uninstalling them after testing, even if they are inactive and do not require any resources.
- Delete the CNI test Pods.
- Delete the Operator test Pods.
- To remove remaining test resources, run:
Upgrading Microgateway 4.2 and newer
The following upgrade instructions aim to upgrade running deployments to a newer version of Airlock Microgateway without interruption of service.
This instruction may not apply to breaking release upgrades of Airlock Microgateway. Refer to the release notes of the Microgatway version you want to upgrade to before following the below instructions.
- Update the CRDs. This will not break your current installation if not noted otherwise in the release notes of the new Microgateway version.
- Upgrade the Microgateway CNI plugin.
- Upgrade the Microgateway Operator.
- You can verify the current Pod status by checking the
version
label. To finalize the upgrade process, manually restart all application Pods containing Microgateway Engine sidecars.
Script-supported upgrading of deployments with outdated application Pods:
We have created a useful script to accelerate the deployment update process with multiple application Pods. The script can fetch Deployments, DaemonSets, and StatefulSets managing outdated application Pods.
- Save the script fetch-outdated-resources, rename it to
fetch-outdated-resources.sh
, and make it executable. - Variant 1
- Variant 2
- Set the
microgateway.airlock.com/restartRequired=true
label. - Perform a rollout restart of the labeled resources.
- Remove the
microgateway.airlock.com/restartRequired=true
label after rollout.
Automatic rollout restart of outdated resources with the following command:
Further information and links
- Internal links:
- See chapter Installation for available installation options and instructions.