Skip to content

Upgrading components

Compatibility

Kubernetes Server-Side Apply (SSA) Requirement

There is an important compatibility requirement that must be considered when installing the Palo Alto Networks enterprise Kubernetes components: Kubernetes Server-Side Apply (SSA) support. For most components, SSA support is a hard requirement. This feature was promoted to GA in Kubernetes version 1.22. For more information, see the Kubernetes documentation.

For this reason, Palo Alto Networks requires all enterprise components to be installed on Kubernetes version 1.22 or later

How to upgrade components

Upgrade increments

Upgrade one minor release at a time, for example, from 1.11.0 to 1.12.0, then to 1.13.0. Similarly, upgrade one LTS release at a time, for instance, from 1.12.0 to 1.17.0.

Always upgrade to the latest patch version of each release directly.

We do not support skipping upgrades since intermediate versions might contain migration logic that is removed in later versions.

Upgrade strategy

Make sure you have a fast-paced process to upgrade to the latest patch version of the release that you are using as soon as possible.

It's important to stay up to date with patches, otherwise you might be susceptible to outages owing to vulnerabilities, or bugs.

Handling CRDs

DO NOT remove CRDs before upgrading. Removing CRDs will result in CRs being garbage collected. Instead patch or replace the CRD resources.

For example, if you remove the certificates.cert-manager.io CRD, all certificate resources will be irreversibly removed by the Kubernetes garbage collector.

  1. Before you upgrade, make sure you have a way to restore the cluster to its state before the upgrade (see Component backups. It's not strictly necessary to do this for patch upgrades (but it's recommended if you want to be extra careful).

  2. Before upgrading to the next release, read the release notes/ upgrade notes. These notes will list breaking changes or extra actions that must be taken before upgrading.

  3. Use Kubernetes manifests, Helm, or GitOps tools to upgrade to the latest version.

  4. Make sure that the CRDs are also upgraded. If you installed the CRDs separately, you must upgrade them separately.

  5. To test your upgraded installation, you can re-issue a certificate. Without causing downtime, the cmctl renew -n namespace certificate-name must be used. For more information on this, see the cert-manager documentation.

    DO NOT remove the TLS secret resource, as this can cause downtime.

  6. If you experience any issues with the newly upgraded version, you can easily revert to the previous version of your installation using helm rollback. For more information, see the Helm documentation.

    If the rollback also fails, you can recover from the backup created in step 1.