Uninstallation and upgrade instructions

This article covers various topics of uninstallation, cleanup, and upgrade of Airlock Microgateway in sidecarless (K8s Gateway API) data plane mode.

Do not add the --reuse-values flag during the helm upgrade operations when upgrading to a different version of Airlock Microgateway/Helm charts. This flag would prevent updating some required settings and changes, such as new chart default values and container image digests.

If the helm upgrade command does not change the Airlock Microgateway version, the flag is safe to use in the commands below, e.g., to clean up test resources.

Upgrade to Microgateway 4.4 from sidecar-based to sidecarless data plane mode

This instruction is applicable when changing from a previous Airlock Microgateway 4.2 or later sidecar-based data plane mode installation to a Microgateway 4.4 sidecarless K8s Gateway API-based data plane mode installation. In this case, you must uninstall the old version and the CNI plugin, except the CRDs. The following brief sequence describes the upgrade and data plane mode switch procedure.
Note that the instructions must be performed in the correct order.

  1. Uninstall the Microgateway CNI plugin if it was installed with kustomize.

    2. Adapt the <environment> part before running the following command:

    copy
    kubectl kustomize --enable-helm https://github.com/airlock/microgateway/deploy/cni/<environment> | kubectl delete -f -
  2. Uninstall Microgateway deployments. Retain previous Microgateway CRDs if you want to retain your custom settings, e.g., custom deny rules in the DenyRules CR.
    3. copy
    kubectl delete -k https://github.com/airlock/microgateway/deploy/deployment/
kubectl delete -k https://github.com/airlock/microgateway/deploy/crd-rbac/
  3. Optional: When upgrading from Microgateway 4.2 and earlier, apply a new license. This is important because the license format changed in Microgateway 4.2.
    4. copy
    kubectl create namespace airlock-microgateway-system
kubectl -n airlock-microgateway-system create secret generic airlock-microgateway-license --from-file=microgateway-license.txt
  4. Update the CRDs. This will not break your current installation if not noted otherwise in the release notes of the new Microgateway version.
    5. copy
    kubectl apply -k https://github.com/airlock/microgateway/deploy/charts/airlock-microgateway/crds/?ref=4.4.0
  5. Install the K8s Gateway API resources. Note that the sidecarless data plane mode installation of Airlock Microgateway requires installing the K8s Gateway API standard channel v1.1.0.
    6. copy
    kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/standard-install.yaml
  6. Wait until the required CRDs for K8s Gateway API usage have been installed.
    Example:
    7. copy
    customresourcedefinition.apiextensions.k8s.io/gatewayclasses.gateway.networking.k8s.io created 
customresourcedefinition.apiextensions.k8s.io/gateways.gateway.networking.k8s.io created 
customresourcedefinition.apiextensions.k8s.io/grpcroutes.gateway.networking.k8s.io created 
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io created 
customresourcedefinition.apiextensions.k8s.io/referencegrants.gateway.networking.k8s.io created
  7. Adapt and run the following command with the current Airlock Microgateway Operator Helm chart version. This will upgrade the Operator in the airlock-microgateway-system namespace and activate the K8s Gateway API support.
    8. copy
    helm upgrade -n airlock-microgateway-system airlock-microgateway oci://quay.io/airlockcharts/microgateway --wait --version 4.4.0 --set=operator.gatewayAPI.enabled=true
  8. Verify that the Airlock Microgateway Operator started successfully:
    9. copy
    kubectl -n airlock-microgateway-system wait --for=condition=Available deployments --all --timeout=3m
  9. The logs should show the message Thank you for installing Airlock Microgateway​. ... including further information on successful installation.
  10. Deploy Microgateway Engine Pods via the Gateway CR and configure the routing through the Microgateway Engine Pod in the HTTPRoute CR.
  11. At this point you may want to check whether the built-in security settings of the Airlock Microgateway are active and securing your application according to your HTTPRoute configuration.
  12. Optional: If additional Microgateway CRs (such as Limits, DenyRules etc.) have already been configured for the previous sidecar-based installation and should be preserved, you must replace the old ContentSecurity with a new ContentSecurityPolicy CR. See also the API reference documentation of the CR ContentSecurityPolicy for an example configuration.

The ContentSecurityPolicy CR is a Direct Policy Attachment for the K8s Gateway API. Microgateway CRs covering custom security aspects, such as the Limits and DenyRules CRs, can be referenced in the ContentSecurityPolicy CR.

If additional Microgateway CRs are not explicitly configured and referenced in the ContentSecurityPolicy, default security settings will be applied. Our default security settings are designed to work well with most upstream services and provide a solid level of security.