Introduction

The release notes include important installation changes and known issues. They also highlight ways that you can take advantage of new features or enhancements to improve your product usage.

For more information, see the following related resources:

  • Changelog: A full list of changes, including the ability to compare previous patch and minor versions.
  • Upgrade guide: Steps to upgrade from the previous minor version to the current version.
  • Version reference: Information about Solo’s version support.

🔥 Breaking changes

Review details about the following breaking changes. To review when breaking changes were released, you can use the comparison feature of the changelog. The severity is intended as a guide to help you assess how much attention to pay to this area during the upgrade, but can vary depending on your environment.

  • No breaking changes are currently reported.

🚧 New known issues

Review new known issues and how to mitigate them.

Route name and matcher changes

When performing a bulk update for the name or matchers of a route in a RouteTable resource, the translation of the Istio VirtualService and EnvoyFilter might take some time to complete, which can lead to policies temporarily not being applied to your routes. For more information about this issue and mitigation strategies, see Bulk route name and matcher updates.

🌟 New features

Review the following new features that are introduced in version 2.9 and that you can enable in your environment.

Gloo Operator reference docs

Reference documentation is now published for the Gloo Operator. For more information, check out the following pages:

OPTIONAL_MUTUAL setting on VirtualGateways

In version 2.9.1, you can now configure your ingress gateway with the OPTIONAL_MUTUAL TLS mode by using the VirtualGateway resource. Optional mutual is similar to the MUTUAL TLS mode, except that the client TLS certificate is optional. The client certificate is still requested during the TLS handshake. However, a TLS connection can still be established, even if the client does not present a certificate. If the client presents a certificate, it is validated by the server.

For more information, see the API docs.

GLOO_CORS_TRANSLATION_MODE

Gloo Mesh Gateway translates a RouteTable delegation tree with a root and all its child RouteTables into a single Istio VirtualService. In setups with large delegation trees, the size of the resulting VirtualService can quickly grow and reach the maximum size of 1.4MiB that the etcd data store can process, especially if route policies are also applied to these RouteTables. VirtualServices that exceed the maximum size are rejected by Kubernetes.

To reduce the size of the resulting VirtualService, you can enable the GLOO_CORS_TRANSLATION_MODE environment variable on the Gloo management server in Gloo Mesh Gateway version 2.9.1. This environment variable changes the way CORS policies are translated. By default, CORS policies are added inline on the resulting VirtualService. With the GLOO_CORS_TRANSLATION_MODE setting, you can change this behavior and instead create a separate EnvoyFilter for the CORS policies.

To set the GLOO_CORS_TRANSLATION_MODE environment variable, perform an upgrade of your Gloo management server Helm installation. Add the following values to your Helm values file:

  
glooMgmtServer:
  extraEnvs:
    GLOO_CORS_TRANSLATION_MODE:
      value: "VS_AND_EF"

You can choose between the following values:

  • VS_ONLY: Add CORS policies inline on the VirtualService.
  • EF_ONLY: Add CORS policies as separate EnvoyFilters.
  • VS_AND_EF: Add CORS policies inline on the VirtualService and in separate EnvoyFilters.

🔄 Feature changes

Review the following changes that might impact how you use certain features in your Gloo environment.

Deprecation of the Istio lifecycle manager

The Istio lifecycle manager, provided either by the istioInstallations section of the Helm chart or by the GatewayLifecycleManager and IstioLifecycleManager custom resources, is deprecated in version 2.9. Support for the feature will end in version 2.11.

Instead, you can use the new way of installing Istio with the Gloo Operator. Check out the guides for installing ambient or sidecar meshes, or for migration steps, see Migrate to the Gloo Operator from the Istio lifecycle manager.

Imported VirtualDestination client-side policies

The ImportedVirtualDestinationPolicyLegacyMode feature gate is added to let you temporarily keep client-side policy behavior when importing VirtualDestinations that do not have a backing service in the local cluster.

Previously, client-side policies were not properly applied to VirtualDestinations that were imported from one workspace to another and did not have a backing service in the local cluster.

Legacy mode is enabled by default. However, you can opt in to the fixes by setting the ImportedVirtualDestinationPolicyLegacyMode feature flag to false in your Helm values. Then, the importing behavior matches the expected behavior as described in the policy import docs.

The fix can impact the DestinationRules that are translated from the client-side policies as follows.

  • Many environments get additional DestinationRules to enforce the client-side policies that are now imported to the workspace.
  • Some environments might have modified or fewer translated DestinationRules from the client-side policies, such as if imported client-side policies result in fewer policies being applied from the importing workspace.

🗑️ Removed features

Removed support for Istio 1.21

Istio 1.21 is no longer supported with Gloo Mesh Gateway version 2.9. For more information, see the version support matrix.

🚧 Known issues

The Solo team fixes bugs, delivers new features, and makes changes on a regular basis as described in the changelog. Some issues, however, might impact many users for common use cases. These known issues are as follows:

  • Cluster names: Do not use underscores (_) in the names of your clusters or in the kubeconfig context for your clusters.
  • Istio:
    • Patch versions 1.26.0 and 1.26.1 of the Solo distribution of Istio lack support for FIPS-tagged images and ztunnel outlier detection. When upgrading or installing 1.26, be sure to use patch version 1.26.1-patch0 and later only.
    • Istio patch versions 1.25.1 and 1.24.4 contain an upstream certificate rotation bug in which requests with more than one trusted root certificate cannot be validated. If you use Gloo Mesh (Gloo Platform APIs) to manage root certificate rotation and use Istio 1.25 or 1.24, be sure to use 1.25.2 or 1.24.5 and later only.
    • Istio 1.22 is supported only as patch version 1.22.1-patch0 and later. Do not use patch versions 1.22.0 and 1.22.1, which contain bugs that impact several Gloo Mesh Gateway routing features that rely on virtual destinations. Additionally, in Istio 1.22.0-1.22.3, the ISTIO_DELTA_XDS environment variable must be set to false. For more information, see this upstream Istio issue. Note that this issue is resolved in Istio 1.22.4.
    • If you have multiple external services that use the same host and plan to use Istio 1.22, you must use patch version 1.22.1-patch0 or later to ensure that the Istio service entry that is created for those external services is correct.
    • Due to a lack of support for the Istio CNI and iptables for the Istio proxy, you cannot run Istio (and therefore Gloo Mesh Gateway) on AWS Fargate. For more information, see the Amazon EKS issue.
  • OTel pipeline: FIPS-compliant builds are not currently supported for the OTel collector agent image.
  • Workspaces: If you run Istio version 1.21 or earlier and you reconfigure your Gloo workspaces, such as by moving from one workspace to multiple workspaces, routing to services that are exposed with a virtual destination might fail. You must re-apply the virtual destination to fix routing for these services. Note that this issue is fixed in Istio version 1.22 and later.
  • Route name and matcher changes: When performing a bulk update for the name or matchers of a route in a RouteTable resource, the translation of the Istio VirtualService and EnvoyFilter might take some time to complete leading to policies temporarily not being applied to your routes. For more information about this issue and mitigation strategies, see Bulk route name and matcher updates.