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

  • No high-impact breaking 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-impact breaking changes are currently reported.

ℹī¸ Low

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

  • No low-impact 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.8 and that you can enable in your environment.

Go version bump

In 2.8.1, the Go version that is used in Gloo Mesh (Gloo Platform APIs) was upgraded to 1.24. This upgrade introduced the following changes:

  • RSA key generation: The minimum size for the RSA key that is used in the generated RootTrustPolicy was increased to 1024 bytes. If an existing RSA key is used with a size below 1024 bytes, the key size is increased and a warning is logged.
  • BoringCrypto version: The BoringCrypto version was upgraded to comply with FIPS 140-3. Because of this, all Gloo Mesh (Gloo Platform APIs) images are now FIPS 140-3 compliant. Note that this change does not include Istio images.

Debug report tool in the Gloo UI

If you need to open a support ticket, you can now use the new Debug Report tool in the Gloo UI. This tool automatically gathers details that can help the Solo support team understand your environment, which you can use to submit a ticket. For more information, see Generate a debug report in the Gloo UI.

Dynamic metadata from the rate limiter

Now, you can add dynamic metadata, such as the descriptor status and overall code, to the response message after a request is filtered by the rate limiter. This way, the metadata is available for use in downstream filters, most commonly for access logs. The metadata might be used for cases such as reporting on API usage and limits.

Available dynamic metadata from the rate limiter:

  • overallCode: The rate limit decision, such as OVER_LIMIT.
  • descriptorStatus: Details for the decision of each descriptor, such as OK.

For more information, see the Rate limit server guide.

jsonToProto dynamic metadata in Inja template tranformations

If you use Inja templates in transformation policies, you can now specify the dynamicMetadataValues.jsonToProto setting in your template. Note that this setting is supported only in Istio versions 1.22 and later.

Route to external TCP services

In version 2.8.3, 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.

New insights

The following new insights are added in version 2.8. For more information, see Insights.

Gloo Mesh insights:

  • CFG0067: Checks Istio and Kubernetes version compatibility in your cluster.
  • CFG0077: A service is labeled to use a waypoint proxy, but the referenced waypoint cannot be found or is missing.
  • CFG0078: A ServiceEntry is labeled to use a waypoint proxy, but the referenced waypoint cannot be found or is missing.
  • CFG0079: Checks whether an AuthorizationPolicy can be enforced at a waypoint for each target reference.
  • CFG0080: Checks whether an AuthorizationPolicy only has L4 attributes when a workload selector is defined.
  • CFG0081: A service is trying to use a waypoint in a different namespace, but the waypoint does not allow its route.
  • CFG0082: A ServiceEntry is trying to use a waypoint in a different namespace, but the waypoint does not allow its route.
  • CFG0083: Checks whether HTTPRoute L7 policies can be applied to a service or ServiceEntry.
  • CFG0084: A service uses a waypoint that does not support the service traffic type.
  • CFG0085: A ServiceEntry uses a waypoint that does not support the service traffic type.
  • CFG0086: Check the peering status for clusters in the multicluster mesh.
  • HLT0041: Reports the Gloo Mesh RouteTable status.
  • HLT0042: Reports the Gloo Mesh VirtualDestination status.
  • SYS0027: A count of cluster configuration resources that are common across all Gloo product installations.
  • SYS0030: A count of cluster configuration resources that are specific to Gloo Mesh (Gloo Platform APIs).

Gloo Gateway insights:

  • CFG0068: Checks Gloo Gateway and Kubernetes Gateway API version compatability.
  • CFG0069: Checks for orphaned RouteOptions.
  • CFG0070: Checks for invalid references in RouteOptions.
  • CFG0071: Checks for invalid targets in VirtualHostOptions
  • CFG0072: Checks for invalid references in VirtualHostOptions.
  • CFG0073: Checks for invalid targets in HttpListenerOptions.
  • CFG0074: Checks for invalid targets in ListenerOptions.
  • CFG0075: Checks for invalid parent references in HTTPRoutes.
  • CFG0076: Checks Gateways for invalid GatewayParameter references.
  • SYS0028: A count of cluster configuration resources that are specific to Gloo Gateway.

Tracing configuration for the rate limit server

OpenTelemetry trace span exports can now be optionally enabled for the rate limit server component for enhanced observability and distributed tracing in your Gloo setup. You can configure the tracing settings in the rateLimiter.rateLimiter.tracing Helm values of the gloo-platform Helm chart, such as when you install the rate limiter during Gloo installation. To get started, see the Rate limit server setup guide.

OPTIONAL_MUTUAL setting on VirtualGateways

In version 2.8.2, 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.8.2. 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.

General availability of the Gloo Operator

The Gloo Operator has been promoted to the general availability (GA) feature maturity status in Gloo Mesh 2.8. You can use the Gloo Operator to easily manage the lifecycle of your sidecar service meshes in single or multicluster mesh setups. To get started, check out Install Gloo-managed service meshes. For more information about feature status, see Solo feature maturity.

Metadata field change in output of translated resources

Previously, when the Gloo management server translated resources, the output resources were created with the metadada.annotations.cluster.solo.io/cluster=<cluster> annotation to indicate the cluster where the resource is originally defined. Now, the metadata.generateName=<cluster> field replaces this annotation. Note that this field is only used internally by Solo for tooling that consumes snapshots, and simply serves as informational metadata when you examine translated resources.

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

  • No features are removed in version 2.8.

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