Navigation :

Supported versions

Review the following information about supported release versions for Gloo Platform, including dependencies on open source projects like Istio.

Supported versions

Solo supports n-3 versions for Gloo Platform. Within each Gloo Platform version, different open source project versions are supported, including Gloo Cilium n-4 version support.

Gloo Platform

The following versions of Gloo Platform are supported with the compatible open source project versions of Cilium and Kubernetes. Later versions of the open source projects that are released after Gloo Platform might also work, but are not tested as part of the Gloo Platform release.

Gloo Platform	Release date	Gloo Cilium`*`	Kubernetes`†`
2.4	28 Aug 2023	1.12 - 1.13	1.21 - 1.26
2.3	17 Apr 2023	1.12	1.20 - 1.25
2.2	20 Jan 2023	1.12	1.19 - 1.24
2.1	21 Oct 2022	1.12	1.18 - 1.23

Gloo Cilium

Gloo Platform n-4 Cilium support starts with the first release of Gloo Network. As new Cilium versions are released, support for these versions is added to Gloo Network. Keep in mind that Gloo Platform offers n-4 security patching support only with Gloo Cilium versions, not community Cilium versions. Gloo Cilium versions support the same patch versions as community Cilium. You can review community Cilium patch versions in the Cilium release documentation. You must run the latest Gloo Platform patch version to get the backported Istio support.

Upgrading versions

The upgrade process depends on which software you need to upgrade and your infrastructure provider.

Gloo Network

Consider the following rules before you plan your Gloo Network upgrade. For steps on how to perform the upgrade, see the Upgrading guide in Gloo Mesh.

General:
Always upgrade the Gloo management server first. Then, roll out the upgrade to the Gloo agents in your workload clusters. For more information, see the version skew policy for management and remote clusters.

Patch version upgrades:
You can skip patch versions within the same minor release. For example, you can upgrade from version 2.2.0 to 2.2.5 directly, and skip the patch versions in between.

Minor version upgrades:

Always upgrade to the latest patch version of the target minor release. For example, if you want to upgrade from version 2.1.x to 2.2.x, and 2.2.5 is the latest patch version, upgrade to that version and skip any previous patch versions for that minor release. Do not upgrade to a lower patch version, such as 2.2.0 or 2.2.1.
Do not skip minor versions during your upgrade. Upgrade minor release versions one at a time. For example, if you currently run version 2.0.x and want to upgrade to version 2.2.x, you must first upgrade to the latest patch version of the 2.1.x minor release. After you upgraded to 2.1.x, you can then plan your upgrade to the latest patch version of the 2.2.x release.

Version skew policy for management and remote clusters

Plan to always upgrade your Gloo management server and agents to the same target version. During the upgrade process, your management server and agents can be one minor version apart. For example, let's say you currently run version 2.3.x and want to upgrade to version 2.4.x. Start by upgrading your management server to the latest patch version of the 2.4 minor release. Your management server and agent are still compliant as they are one minor version apart. Then, roll out the 2.4 minor release upgrade to the agents in your workload clusters.

If you plan to upgrade more than one minor releases, you must perform one minor release upgrade at a time. For example, to upgrade your management server and agent from 2.2.x to 2.4.x, you upgrade your management server to the latest patch version of the 2.3 minor release first. Your management server and agent are compliant because they are one minor version apart. Then, you upgrade your agents to the 2.3 minor release. After you verify the 2.3 upgrade, use the same approach to upgrade the management server and agents from 2.3 to the target 2.4 minor release.

If both your management server and agent run the same minor version, the agent can run any patch version that is equal or lower than the management server's patch version.

Consider the following example version skew scenarios:

Supported?	Server version	Agent version	Requirement
✅	2.3.4	2.3.2	The management server and agents run the same minor version. The agent patch version is equal to or lower than the management server.
❌	2.3.4	2.3.5	The agent runs the same minor version as the server, but has a patch version greater than the server.
✅	2.3.4	2.2.4	The agent runs a minor version no greater than n-1 behind the server.
❌	2.3.4	2.1.9	The agent runs a minor version that is greater than n-1 behind the server.

Kubernetes or OpenShift

Consult your infrastructure provider's upgrade process. For example, you might use Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), or Microsoft Azure Kubernetes Service (AKS).

Download a specific image

You can download a particular image for Gloo Platform, such as for the following use cases.

To download and transfer these images if your environment does not have public network access or cannot pull public images, for an air-gapped installation.
To run an older Istio version that the community no longer supports while still receiving security patches.
To use a custom build that aligns with compliance standards such as Federal Information Processing Standards (FIPS).

Get the Gloo Platform version that you want to use

Find the version tag in the changelog, such as 2.4.1.
To download the package for the gloo-mesh-mgmt-server component that you deploy in your management clusters, append the <version_tag> to the following URL.
```
https://storage.googleapis.com/gloo-mesh-enterprise/gloo-mesh-enterprise/gloo-mesh-enterprise-<version_tag>.tgz
```
To download the package for the gloo-mesh-agent component that you deploy in your remote data plane clusters, append the <version_tag> to the following URL.
```
https://storage.googleapis.com/gloo-mesh-enterprise/gloo-mesh-agent/gloo-mesh-agent-<version_tag>.tgz
```

Optional: For FIPS-compliant images, open the values.yaml file in the downloaded package, search for the image section, and append -fips to the tag, such as in the following example.

...
enterpriseNetworking:
  image:
    pullPolicy: IfNotPresent
    registry: gcr.io/gloo-mesh
    repository: gloo-mesh-mgmt-server
    tag: 2.4.1-fips

Optional: If you need to pull the images locally, such as for an air-gapped installation, you can use the information you retrieved from the images section in the values.yaml file to pull the image. For example, you might use the following docker pull command for a FIPS image. Repeat this step for each image that you want to build locally and push to a private repository.
```
docker pull gcr.io/gloo-mesh/gloo-mesh-mgmt-server:2.4.1-fips
```
Use these packages when you install Gloo Platform.

Release lifecycle

Typically, Gloo Platform releases a new minor version, n, each quarter. Make sure that you run a supported version for production environments, and keep that version upgraded to the latest patch version so that you have the latest security fixes. For more information, see Upgrading Gloo Platform.

Version	Supported?	Type	Description
`n`	Yes	Latest	The latest stable version is the default version when you view the documentation. New features are typically not developed for the latest version, but the version is actively maintained for security patches, bugs, and documentation.
`n-2`	Yes	Stable	Supported versions up to `n-2` continue to receive support for security patches, bugs, and documentation. You can review the documentation for these versions by switching the documentation to the `main` branch from the dropdown in the menu bar.
`n+1`	No	Beta	Active feature development happens on the `main` branch as part of the development of a beta version. When the `n+1` beta version is prepared as a release candidate, new feature development is suspended until this version becomes the new `n`. You can preview the documentation for some of these features by switching the documentation to the `main` branch from the dropdown in the menu bar. New features and development work on `main` is subject to change, not necessarily fully tested, and not supported.
`n-3`	No	Unsupported	Versions that are `n-3` or older are no longer supported or maintained. Upgrade your release to a stable version to continue to receive support.

Open source packages in Gloo Platform

For specific versions of open sources packages that are bundled with Gloo Platform, see the entries in the Open Source Attribution topic. For more information on where these open source packages are retrieved from, see the go.mod documentation.

Help me choose which version to run

Consider your container platform environment, particularly which cloud provider and version of Kubernetes that you want to run. Compare the version against the table of supported versions for Gloo Platform.
Review the features that are available in a particular version of the software.
- Istio features
- Kubernetes release notes
Decide if you need to run a specific image, such as the FIPS version of Solo Istio for FedRAMP compliance.
Follow the Setup guides, modifying the steps to install the particular versions that you want to use.