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. To review when breaking changes were released, you can use the comparison feature of the open source changelog or enterprise 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

Envoy version upgrade

The Envoy dependency in Gloo Gateway 1.19 was upgraded from 1.31.x to 1.33.x. This change includes the following upstream breaking changes. For more information about these changes, see the Envoy changelog documentation.

  • Trust internal addresses: Envoy sanitizes certain headers and statistics for non-trusted addresses. By default, Envoy is configured to trust internal addresses that adhere to the RFC1918 standard. However, in Envoy 1.33, this behavior is changed. RFC1918 addresses must now be added to the HCM internal_address_config for Envoy to trust them. For example, if you have tooling, such as probes on your private network, make sure to include these IP addresses or CIDR ranges in the internal address config. To try out or enable this upcoming behavior change, you can set the envoy.reloadable_features.explicit_internal_address_config runtime guard to true. For more information, see the related pull request in Envoy.
  • Access log handlers: Access log handlers that are added by filters are now evaluated before access log handlers that are configured in the access_log configuration. To disable this behavior, you can set the envoy.reloadable_features.filter_access_loggers_first runtime guard flag to false.
  • Cluster name change in Kuberetes Gateway API: When you route to Kubernetes Services or Upstreams, the Envoy cluster name format is changed to extract more details about the service. The new format uses underscores to list service details, such as upstreamName_upstreamNs_svcNs_svcName_svcPort. If you enabled the Kubernetes Gateway API integration with kubeGateway.enabled=true, both the Gloo Edge and Kubernetes Gateway API proxies use the same format for these cluster names.
  • Extproc tracing changes: In previous releases, tracing spans that were generated by the extProc filter were sampled by default. Now, these traces are not automatically sampled. Instead, the tracing decision is inherited from the parent span.
  • Opencensus tracing extension removed: Support for the Opencensus tracing extension is removed in Envoy 1.33.
  • Opentracing extension removed: Support for the Opentracing extension is removed in Envoy 1.32. For more information, see the related Envoy issue.

🔔 Medium

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

ℹī¸ 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.

⚒ī¸ Installation changes

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

  • No installation changes are currently reported.

🌟 New features

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

Kubernetes 1.32 support

Starting in version 1.19.0, Gloo Gateway can now run on Kubernetes 1.32. For more information about supported Kubernetes, Envoy, and Istio versions, see the version support matrix.

Istio 1.25 support

Starting in version 1.19.0, Gloo Gateway can now run with Istio 1.25. For more information about supported Kubernetes, Envoy, and Istio versions, see the version support matrix.

TLSRoute support

TLSRoute support was added to Gloo Gateway. With TLSRoutes, you can pass through requests to a TLS backend. The Gateway does not terminate the TLS connection. Because of that, the backend must be capable to handle incoming TLS connections and to terminate them.

For an example, see TLS passthrough.

New AI Gateway features

The following AI capabilities were released with the 1.19.0 release:

  • Function Calling: Send function calls to an LLM through Gloo AI Gateway.
  • Streaming support: Stream responses from the LLM to the end user through Gloo AI Gateway.
  • Advanced guardrails: Use the Guardrail Webhook API to set up your own custom guardrail controls for Gloo AI Gateway.
  • Langchain and LlamaIndex: Gloo AI Gateway can now be integrated with popular AI frameworks, such as Langchain and LlamaIndex.
  • AI tracing: Use tracing tools, such as Jaeger to observe requests to your LLM, troubleshoot issues, and identify performance bottlenecks.

Enhanced support for HTTP/2

Previously, enabling HTTP/2 for an upstream service required an Upstream resource to be in place that was configured for HTTP/2. Starting in 1.19.0, you can now configure HTTP/2 on your Kubernetes service directly by defining one of the following values in the appProtocol for the port:

  • http2
  • grpc
  • grpc-web
  • kubernetes.io/h2c

Example configuration:

  apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app.kubernetes.io/name: nginx
  ports:
    - protocol: TCP
      port: 8080
      targetPort: http-web-svc
      appProtocol: http2

For more information, see the HTTP/2 guide.

Additional Gateway TLS options

You can now configure your HTTPS/TLS listener with additional TLS settings, such as the cipher suites, and minimum and maximum TLS version to use during the TLS handshake. For more information, see Additional TLS settings

Match conditions on validation webhook

You can now specify match conditions on the Gloo Gateway or Kubernetes validating admission webhook level to filter the resources that you want to include or exclude from validation. Match conditions are written in CEL (Common Expression Language).

For example to exclude a secret with the label “foo” from being validated with the Kubernetes webhook, add the following values to your Helm values file.

  gateway:
  validation:
    kubeCoreFailurePolicy: Fail # For "strict" validation mode, fail the validation if webhook server is not available
    kubeCoreMatchConditions:
    - name: 'not-a-secret-or-secret-with-foo-label-key'
      expression: '!(request.kind.kind == "Secret" && "labels" in object.metadata && "foo" in object.metadata.labels)'

To exclude these secrets from the Gloo Gateway validation webhook, add the following values.

  gateway:
  validation:
    FailurePolicy: Fail # For "strict" validation mode, fail the validation if webhook server is not available
    matchConditions:
    - name: 'not-a-secret-or-secret-with-foo-label-key'
      expression: '!(request.kind.kind == "Secret" && "labels" in object.metadata && "foo" in object.metadata.labels)'

For more information, see Exclude resources from validation.

ListenerSets

With Gloo Gateway 1.19 and Kubernetes Gateway API 1.3.0 experimental channel, you can now use ListenerSets. ListenerSets provide another place to define listeners instead of inline in the Gateway resource. With ListenerSets, you can group together listeners that have their own unique configuration, such as different protocols, ports, hostnames, or TLS settings. Then, you map the ListenerSet to a Gateway resource. This way, you can decentralize route configuration in a multitenant environment at scale. If you’re hitting the limit of 64 listeners per Gateway, ListenerSets can be particularly helpful.

For more information, see the Listeners overview and the updated listener guides.

New insights

The following new insights are added to the Gloo UI in version 1.19. For more information about insights, including steps to install the Gloo UI, see Set up the Gloo UI.

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

New common category for CRs

A new common category was added to all Gloo Gateway custom resources. This common category allows you to easily list all Gloo Gateway custom resources in your environment.

To list all Gloo Gateway resources across all namespaces:.

  kubectl get gloo-gateway -A

To list all enterprise custom resources only:

  kubectl get solo-io -A

New glooctl debug command

Collect Kubernetes, Gloo Gateway controller, and Envoy information from your environment, such as logs, YAML manifests, metrics, and snapshots by using the glooctl debug and glooctl debug yaml commands. This information can be used to debug issues in your environment or to provide this information to the Solo.io support team.

🔄 Feature changes

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