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:

đŸ”Ĩ Breaking changes

Review details about the following breaking changes. 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 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 (OSS 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.

Ambient-sidecar interoperability

In the community distribution of ambient mesh, Envoy-based proxies such as ingress gateways and sidecar-enabled workloads can communicate with ambient mesh components via the HBONE protocol by default. However, Envoy-based proxies cannot utilize waypoint proxies. This means that traffic between Envoy-based proxies and ambient mesh components that requires policy application either fail or do not perform correctly, because the expected policies enforced by the waypoint proxy do not apply to requests from the Envoy-based proxies.

In the Solo distribution of Istio, interoperability between waypoints and sidecars and between waypoints and ingress proxies is supported.

  • Sidecars: Client policies, such as routing rules, are applied either at the client sidecar, or at one waypoint if a waypoint exists. When a sidecar detects that a request must be sent to a service that uses a waypoint, the sidecar disables any client-side policies (such as skipping virtual services), and instead sends the request directly to the waypoint. Note that policy enforcement for some sidecar-inbound policies that can also be applied at the service’s waypoint might behave differently.
  • Ingress: By default, ingress proxies cannot determine the destination service for a request without applying the route. For this reason, the istio.io/ingress-use-waypoint: true label must be applied to any services that should respect waypoint proxies, so that the ingress proxy can send requests for the service’s route directly to the waypoint.

Because interoperability is supported, you can use the Solo distribution of Istio to run both sidecar and ambient components in your cluster. For example, you can peform a zero-downtime migration from a sidecar mesh to an ambient mesh, in which ambient waypoints can route to sidecars during the migration process. In some cases, interoperability can be used intentionally, such as in multicluster sidecar mesh setups. In this setup, you install the Istio ambient components in each workload cluster to successfully create east-west gateways and establish multicluster peering, even if you plan to use a sidecar mesh. However, sidecar mesh setups continue to use sidecar injection for your workloads, and your workloads are not added to an ambient mesh.

For more information, see Ambient-sidecar interoperability.

Automated multicluster peering (beta)

In multicluster setups, you can configure Gloo Mesh (OSS APIs) to automate multicluster mesh peering by including the --set featureGates.ConfigDistribution=true setting in your management plane installation. Then, you use the istioctl multicluster expose command included in the Solo distribution of Istio to quickly create east-west gateways. The Gloo management plane watches for these east-west gateways, and generates one istio-remote resource in the management cluster for each connected workload cluster. Gloo Mesh (OSS APIs) then distributes the gateway to each cluster respectively. These gateways use the istio-remote GatewayClass, which allows the istiod control plane in each cluster to discover the east-west gateway addresses of other clusters.

Note that because the istio-remote resource requirement for automated peering is lightweight, scaling automated peering up to multiple clusters has little impact on performance. When you add a cluster to the multicluster setup, Gloo Mesh (OSS APIs) must only distribute one additional istio-remote resource to each existing cluster, and distribute the existing istio-remote resources to the new cluster.

To get started, follow the Gloo Operator guides to install an ambient or sidecar multicluster mesh.

For more information, see Lifecycle management in the service mesh options overview.

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.

gloo CLI

A new Solo CLI, gloo, is introduced to provide new tooling for your Gloo environment. For example, this CLI contains a set of commands to help you migrate to an ambient mesh.

To download the gloo CLI:

  curl -sL https://storage.googleapis.com/gloo-cli/install.sh | sh -

export PATH=$HOME/.gloo/bin:$PATH

For more information, including example commands, see the ambient migration guide.

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.
  • SYS0027: A count of cluster configuration resources that are common across all Gloo product installations.
  • SYS0029: A count of cluster configuration resources that are specific to Gloo Mesh.

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.

SPIRE ambient mesh integration

SPIRE offers robust workload attestation capabilities that provide significantly more controls around how, when, and if identities are granted to workloads. The Solo distribution of Istio includes Enterprise support for using SPIRE node agents (over an Envoy SDS socket) to attest and grant identities to the ambient mesh workloads they proxy. This allows Istio to use these identities for mTLS connections between the ambient mesh workloads.

With the SPIRE integration, the ztunnel can act as a trusted spire-agent delegate on the node by using the SPIRE DelegatedIdentity API. Ztunnel can integrate with SPIRE to leverage SPIRE’s existing node and workload attestation plugin framework directly, as well as request workload certificates that are issued by SPIRE on the basis of those attestations.

To get started, check out Secure workload identities with SPIRE.

🔄 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 ambient or sidecar service meshes in single or multicluster mesh setups. To get started, check out Install a managed ambient mesh with the Gloo Operator. 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.

🗑ī¸ 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.
    • Ambient mode requires the Solo distribution of Istio version 1.22.3 or later (1.22.3-solo). Multicluster setups require the Solo distribution of Istio version 1.24.3 or later (1.24.3-solo), including the Solo distribution of istioctl.
    • 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.
    • Due to a lack of support for the Istio CNI and iptables for the Istio proxy, you cannot run Istio (and therefore Gloo Mesh (OSS 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.