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.

🚨 High

Review severe changes that can impact production and require manual intervention.

Extauth denied auth response merging

The Gloo Mesh Enterprise external auth server now merges denied authentication responses when a || boolean expression is used. This change allows you more control over returned responses. Previously, a 403 HTTP response code was returned in all cases. Use the following examples to learn more about the new behavior:

  • 401 || 401 results in a 401 HTTP response code. Previously, this case returned a 403 HTTP response code.
  • 401 || 403 results in a 403 response code.

You can disable the new behavior by enabling the following feature flag in your Helm values file:

  
extAuthService: 
  extraEnvs: 
    DONT_MERGE_DENIED_AUTH_RESPONSES: true

Retries in Istio 1.24

Starting in Istio 1.24, Istio does not automatically retry failed 503 HTTP response codes anymore. To learn more about this change, see the Istio documentation.

You can temporarily disable this new behavior by adding the following values to your Helm values file:

  
featureGates: 
  EXCLUDE_UNSAFE_503_FROM_DEFAULT_RETRY: true

🔔 Medium

Review changes that might have impact to production and require manual intervention, but possibly not until the next version is released.

  • No medium-severity changes are currently reported.

ℹī¸ Low

Review informational updates that you might want to implement but that are unlikely to materially impact production.

Dashboard upgrades

The gloo-mesh-ui deployment no longer watches secrets and config maps that are used to secure access to the dashboard. If you update these resources, such as to rotate a secret, you must now restart the gloo-mesh-ui deployment after the Helm upgrade. Note that this change does not apply in scenarios where you customize the secret or config map names during the initial Helm installation.

OTel image change

The name of the OpenTelemetry image that is used in Gloo Mesh Enterprise is changed as follows:

  • Old name: gloo-otel-collector
  • New name: otel-collector

Make sure to update any CI/CD pipelines to pull the new image (gcr.io/gloo-mesh/otel-collector:0.2.0), such as in an airgapped environment.

⚒ī¸ Installation changes

In addition to comparing differences across versions in the changelog, review the following installation changes from the previous minor version to version 2.7.

🌟 New features

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

Managed Istio installations with the Gloo Operator (alpha)

By using the Gloo Operator to manage your service meshes, you no longer need to manually install and manage the istiod control plane. Instead, you provide minimal Istio configuration to the operator in a ServiceMeshController custom resource, and the operator translates this configuration into a managed istiod control plane in your cluster for you. The operator reduces both the amount of configuration required to deploy Istio, and the overhead required to manage the lifecycle of Istio resources in your cluster.

To get started, see

Install Gloo-managed sidecar meshes.

Note that the Gloo operator is an alpha feature in version 2.7.

Virtual destinations for multicluster rate limiter

Now, you can configure the rate limiter to use virtual destinations. Then, you can set up the rate limiter in each cluster to share the same external Redis database. This way, you can enforce the same rate limit, such as 3 requests per day, across clusters. For more information, see the Multicluster rate limit guide.

Deployment overrides and other options for external auth service and rate limiter

Now, you can set deployment overrides for the external auth service and rate limiter in the Helm values file for your Gloo Mesh Enterprise installation. This way, you can customize the default deployment settings, such as the metadata or resource limits for CPU and memory. Or, you might want to provide your own resource such as a config map, service account, or volume that you mount to the deployment. For more information, see Overrides for default components.

You also now can set the number of replicas for the rate limiter with the new rateLimiter.rateLimiter.replicas setting. For more information, see the Helm reference docs.

Delimiters in JWT token claims

Now, you can configure custom delimiters when you extract claims from JWT tokens. This way, you can append the claim information in a header in a different format than the default comma-delimited format. For example steps, see Extract claims to headers.

Keepalive settings for virtual destinations

Now, Gloo Mesh Enterprise can set the TCP keepalive settings for all your virtual destinations by default. To enable this behavior, upgrade your installation with the EnableDefaultTcpKeepalive feature gate. You can refine the keepalive settings per virtual destination by using the TCP ConnectionPolicy. For more information, see the TCP ConnectionPolicy guide.

Istio 1.24 and 1.23 support

You can now run Gloo Mesh Enterprise with Istio 1.24 and 1.23. Istio 1.18 and 1.19 are no longer supported. For more information, see the version support matrix.

Kubernetes 1.31

You can now run Gloo Mesh Enterprise with Kubernetes 1.31. Kubernetes version 1.24 and 1.25 are no longer supported. For more information, see the version support matrix.

Gloo Gateway support

You can now use Gloo Gateway as the ingress gateway to a sidecar mesh. You can also configure Gloo Gateway to route traffic to a VirtualDestination directly. For more information, check out the following guides in the Gloo Gateway documentation:

🔄 Feature changes

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

New Gloo UI design

The Gloo UI has a new look and feel. In addition, the following features were introduced:

  • New Dashboard design that allows you to quickly see the status of your insights, metrics, such as requests per second and request latency, and the health of your Gloo and Istio components. To view the new dashboard, you must have insights enabled.
  • New design of the Traffic section that gives you an overview of traffic-related resources, such as Gateways, Routes, Destinations, and Policies.
  • New Clusters page that quickly gives you an overview of the cluster’s insights and the health of the Gloo Mesh Enterprise, Istio, Kubernetes Gateway API resources and components that are deployed in your cluster.

To learn more about the new Gloo UI design, see Explore the UI.

Logs for Gloo and Istio components

In previous releases, logs for Gloo and Istio components were enabled by default in the Gloo UI. Starting with version 2.7, the logs are no longer automatically enabled. Instead, you must enable logs for the Gloo UI during your installation. For more information, see Enable logs.

Telemetry pipeline architecture changes

In 2.7, the following components in the Gloo Mesh Enterprise telemetry pipeline were changed:

  • The Gloo analyzer is now deployed as a sidecar to the Gloo agent in multicluster setups. The analyzer scans your workload cluster setups and sends back analyzer results as logs via the Gloo telemetry pipeline. Previously, the Gloo analyzer was deployed as a separate component in the gloo-mesh namespace. You can still run the Gloo analyzer as a separate deployment on clusters where no Gloo UI is deployed by setting glooAnalyzer.runAsSidecar=false in your Helm installation. Note that in single cluster setups, you do not need to install the Gloo agent and Gloo analyzer as the insights engine in the Gloo UI is sufficient to scan your environment and generate the insights.
  • The insights engine is now deployed as a sidecar to the Gloo UI. Previously, the insights engine was part of the Gloo management server. In multicluster setups in 2.7, the insights engine in the Gloo UI now reads the logs from Redis streams that the Gloo analyzer sends via the Gloo telemetry pipeline. The insights engine then runs queries by using the metrics that are stored in Prometheus to generate insights. In single cluster setups, the insights engine scans your environment to generate the insights. No Gloo analyzer is required. Insights are stored in memory in the Gloo UI pod. Note that you cannot run the insights engine as a separate deployment anymore.

For more information about the telemetry pipeline architecture, see About the telemetry pipeline.

🗑ī¸ Removed features

Gloo UI redesign

As part of redesigning the UI, the following changes were introduced:

  • Fields removed from Graph: The following fields are removed from the workload node view in the Graph UI. These fields showed boundaries of the underlying network infrastructure provider when you onboarded VMs to the mesh.

    • instance
    • platform
    • subnet
    • vpc

  • Removed views: The following views were removed:

    • Traffic > Ingress, related gateways and routes can be found under Traffic > Gateways and Traffic > Routes
    • Inventory > Services, services can now be found under Traffic > Destinations

  • GraphQL and Cilium: All GraphQL and Cilium information was removed.

  • Removed session support: Due to lack of use and the extra dependency on Redis that can introduce risk, the ability to store Gloo UI sessions in Redis was removed. This removes the following settings:

    • In the Dashboard resource, the authn.oidc.session.redis settings.
    • In the Helm chart, the glooUi.auth.oidc.session.redis settings.

Removed support for Istio 1.18 and 1.19

Istio 1.18 and Istio 1.19 are no longer supported with Gloo Mesh Enterprise version 2.7. For more information, see the version support matrix.

Removed support for Kubernetes 1.24 and 1.25

Kubernetes 1.24 and 1.25 are no longer supported with Gloo Mesh Enterprise version 2.7. 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:
    • Due to a lack of support for the Istio CNI and iptables for the Istio proxy, you cannot run Istio (and therefore Gloo Mesh Enterprise) on AWS Fargate. For more information, see the Amazon EKS issue.
    • 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 Enterprise 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.
    • Istio 1.20 is supported only as patch version 1.20.1-patch1 and later. Do not use patch versions 1.20.0 and 1.20.1, which contain bugs that impact several Gloo Mesh Enterprise features that rely on Istio ServiceEntries.
      • If you have multiple external services that use the same host and plan to use Istio 1.20, 1.21, or 1.22, you must use patch versions 1.20.7, 1.21.3, or 1.22.1-patch0 or later to ensure that the Istio service entry that is created for those external services is correct.
      • The WasmDeploymentPolicy Gloo CR is currently unsupported in Istio versions 1.18 and later.
    • 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.