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.

  • No high-severity changes are currently reported.

🔔 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.

  • No low-severity changes are currently reported.

🌟 New features

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

Istio 1.28 support

You can now run Gloo Mesh (Gloo Platform APIs) with Istio 1.28. Istio 1.23 is no longer supported. For more information, see the version support matrix, and the Solo distribution of Istio changelog for 1.28.

Additional Helm settings for scrape overrides

New Helm settings are added for scrape intervals and timeouts in the OpenTelemetry (OTel) gateway and collector. These settings can be useful for tuning your telemetry pipeline large environments.

For example, you might want to override the following Prometheus values.

  prometheus:
  server:
    global:
      scrape_interval: 60s
      scrape_timeout: 50s

To easily override these values, you can use the following new Helm settings in your Gloo Mesh installation.

  • Telemetry gateway:
      telemetryGatewayCustomization.otlp.max_recv_msg_size_mib
telemetryGatewayCustomization.prometheusScrapeInterval
telemetryGatewayCustomization.prometheusScrapeTimeout
  • Telemetry collector:
      telemetryCollectorCustomization.prometheusScrapeInterval
telemetryCollectorCustomization.prometheusSrapeTimeout
telemetryCollectorCustomization.otlp.max_recv_msg_size_mib
telemetryCollectorCustomization.otlpExporterTimeout
telemetryCollectorCustomization.otlpExporterRetry.enabled
telemetryCollectorCustomization.otlpExporterRetry.initial_interval
telemetryCollectorCustomization.otlpExporterRetry.max_interval
telemetryCollectorCustomization.otlpExporterRetry.max_elapsed_time

OTel collector sharding

By default, the telemetry collector runs as a daemon set in your Gloo Mesh environment. In some organizations, security or architecture restrictions might prevent you from running the collector pod on every node in the cluster. In this case, you might want to shard the tellemetry collector as a stateful set instead. This method allows the collector to be able to continually process a high level of metrics, without requiring the collector pod to deploy as a daemon set.

To shard the telemetry collector, follow the Upgrade guide and add the following configuration to your Helm values file:

  telemetryCollector:
  enabled: true
  mode: statefulset
  replicaCount: 2
telemetryCollectorCustomization:
  sharding:
    enabled: true

🔄 Feature changes

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

Deprecation of the built-in Jaeger instance

The built-in Jaeger instance, which was previously provided in the Gloo UI for testing or demo purposes, is deprecated in Gloo Mesh version 2.11 and later, and will be removed in future versions. Instead, you can create your own custom tracing pipeline in the Gloo telemetry pipeline to forward traces to a tracing platform that is managed by your organization and hardened for production. Alternatively, you can send production traces to a SaaS backend. Use the steps in Bring your own Jaeger instance as a guide to integrate your own tracing platform.

No Istio 1.28 support in Istio lifecycle manager

The Istio lifecycle manager (ILM) is deprecated and is planned to be removed in Gloo Mesh (Gloo Platform APIs) 2.12. You cannot use ILM to install Istio 1.28. However, you can continue to use the ILM to install the latest patch updates for Istio 1.27 or earlier. Note that during the installation or upgrade with the ILM, a deprecated note is shown.

If you have not done so yet, change the way that you manage Istio by using either Helm or the new 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.

Deprecation of solo.io/service-scope=global-only

By labeling a service or namespace with solo.io/service-scope, you make a service available across clusters throughout a multicluster mesh setup. In the Solo distribution of Istio 1.27 and earlier, supported values included global to make services available across all peered clusters through a global hostname, and global-only to ensure that traffic requests to the service are always routed to the global hostname and never to the service’s in-cluster local hostname.

In the Solo distribution of Istio 1.28 and later, the global-only value for solo.io/service-scope is deprecated. Instead, you can use the cluster, segment, or global values for the solo.io/service-scope label, and replicate the same functionality of all traffic routing through the service’s global hostname by using the new solo.io/service-takeover=true label.

For more information about the updated solo.io/service-scope label, see Global vs segment scope with solo.io/service-scope. For more information about the new solo.io/service-takeover label, see Local traffic takeover with solo.io/service-takeover.

🗑ī¸ Removed features

No features were removed.

🚧 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.
    • 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.