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:

JWT support for VirtualDestination selectors

Now, you can use the applyToDestinations selector in a JWT policy to select a VirtualDestination. Previously, the selector only supported Kubernetes services or ExternalServices. For more information, see JWT concept docs.

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 (Gloo Platform APIs) 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 (Gloo Platform APIs) 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.

Route to external TCP services

In version 2.9.2, you can now route traffic to an external TCP service by using an Istio egress gateway. The mTLS connection from the pod is terminated at the egress gateway, and you can decide whether to forward TCP traffic or originate a new TLS connection to your external service.

For more information, see Route to external TCP services.

🔄 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 (Gloo Platform APIs) 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.
    • In the Solo distribution of Istio 1.25 and later, you can access enterprise-level features by passing your Solo license in the license.value or license.secretRef field of the Solo distribution of the istiod Helm chart. The Solo istiod Helm chart is strongly recommended due to the included safeguards, default settings, and upgrade handling to ensure a reliable and secure Istio deployment. Though it is not recommended, you can pass your license key in the open source istiod Helm chart by using the --set pilot.env.SOLO_LICENSE_KEY field.
    • 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 (Gloo Platform APIs) 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 (Gloo Platform APIs)) 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.