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

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

Envoy version 1.31 upgrade

The Envoy dependency in Gloo Gateway 1.18 was upgraded from 1.29.x to 1.31.x. This upgrade includes the following changes. For more information about these changes, see the Envoy changelog documentation.

  • Opencensus: Opencensus was marked as deprecated in previous Envoy releases. Starting in the 1.31.x Envoy release, Opencensus is now disabled by default. If Opencensus is set, Envoy rejects the configuration. If you still need time to transition off Opencensus, you can use Envoy’s layered_runtime section to enable deprecated configuration so that you can continue using Opencensus. However, note that Opencensus is completely removed in Envoy version 1.32.x.
  • JWT tokens: The behavior for extracting JWT tokens changed in the 1.29.x Envoy release. Previously, the JWT token was cut into non-base64 characters. Now, the entire JWT token is passed for validation. You can no longer revert this change by setting envoy.reloadable_features.token_passed_entirely to false as this option was removed in the 1.31.x Envoy release.
  • JWT_authn: Provider URIs that are defined in the jwt_authn section are now validated for RFC-compliance. Envoy might fail to start correctly if non-compliant URIs are found. If the URI validation is too strict, you can temporarily disable it by setting the runtime guard envoy.reloadable_features.jwt_authn_validate_uri to false. Common URI issues that were previously ignored, include:
    • Hostname contains an underscore character (_)
    • URL contains non-English characters (ASCII code > 127)
    • URL contains an unencoded character such as a space ( )
    • URL contains TAB (ASCII code 9) or FormFeed (ASCII code 12) characters
  • JWT_authn: The provider forward configuration changed. Previously, JWTs could only be removed from headers. Starting in Envoy version 1.31.x, JWTs can now be removed from query parameters. You can temporarily revert this change by setting envoy.reloadable_features.jwt_authn_remove_jwt_from_query_params to false.
  • access_log: The following access log format specifiers changed:
    • The upstream connection address is now used for the %UPSTREAM_REMOTE_ADDRESS%, %UPSTREAM_REMOTE_PORT% and %UPSTREAM_REMOTE_ADDRESS_WITHOUT_PORT% access log format specifiers. Previously, the upstream host address was used. You can temporarily revert this change by setting the runtime guard envoy.reloadable_features.upstream_remote_address_use_connection to false.
    • The %UPSTREAM_CLUSTER_RAW% access log formatter was added to log the original upstream cluster name, regardless of whether alt_stat_name is set.
    • SNIs are automatically sanitized for potential log injection. The invalid characters are replaced by underscores _ with an invalid: marker. To disable this feature, set envoy.reloadable_features.sanitize_sni_in_access_log is set to false.
  • YAML parsing: The behavior for parsing YAML configuration changed. Previously, malformed boolean values and fraction objects that set true or false as a string value were still interpreted as boolean values. Now, true or false string values are no longer interpreted as boolean values. You can revert this change by setting envoy.reloadable_features.reject_invalid_yaml to false.
  • HTTP/2: HTTP/2 colon prefixed headers are now sanitized by Envoy. Previously, sanitation was performed by the nghttp2 library, which caused pseudo headers with upper case letters to fail validation. Now, these pseudo headers pass validation. You can temporarily revert this change by setting the runtime guard envoy.reloadable_features.sanitize_http2_headers_without_nghttp2 to false.
  • Local ratelimit: The token bucket implementation changed. Previously, a timer-based token bucket was used to assign tokens to connections. In Envoy 1.31.x, the new AtomicToken bucket is used that is no longer timer-based. Tokens are now automatically refilled when the token bucket is accessed. Because of this change, the x-ratelimit-reset header is no longer sent. You can temporarily revert this change by setting the runtime guard envoy.reloadable_features.no_timer_based_rate_limit_token_bucket to false.

🔔 Medium

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

Kubernetes Gateway API version 1.1.0 and 1.2.0

Gloo Gateway is fully conformant with the Kubernetes Gateway API version 1.1.0 and 1.2.0. When upgrading from version 1.17.x to 1.18.x, make sure to first upgrade the Kubernetes Gateway APIs. Then, continue with the Gloo Gateway upgrade.

Review the changes that were introduced to Gloo Gateway:

  • TCPRoute support: You can now use TCPRoute resources to set up a TCP listener on your Gateway. Note that in order to use TCPRoutes, you must use the experimental channel of the Kubernetes Gateway API.

      kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/experimental-install.yaml

    If you do not want to use TCPRoutes, you can install the CRDs from the standard channel.

      kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.0/standard-install.yaml

  • EndpointSlices API support: Gloo Gateway now supports the EndpointSlices API when creating Upstream endpoints. The EndpointSlice API reached general availability (GA) in Kubernetes version 1.21. kube-proxy on both Linux and Windows uses EndpointSlices by default. To read more about EndpointSlices and how they affect scalability, see this blog.

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

  • No installation changes are currently reported.

🌟 New features

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

AI Gateway

Starting in 1.18.0, you can now use Gloo Gateway’s AI Gateway capabilities. AI Gateway unleashes developer productivity and accelerates AI innovation by providing a unified API interface that developers can use to access and consume AI services from multiple Large Language Model (LLM) providers. Because the API is part of the gateway proxy, you can leverage and apply additional traffic management, security, and resiliency policies to the requests to your LLM provider. This set of policies allows you to centrally govern, secure, control, and audit access to your LLM providers.

With AI Gateway, you have access to the following capabilities:

  • Centralized credential management
  • Access control
  • Prompt enrichment
  • Prompt guards
  • Rate limiting
  • Retrieval augemented generation (RAG)
  • Semantic caching

For more information, see About AI Gateway and the AI Gateway Tutorials.

Direct response support

You can use the DirectResponse custom resource to directly respond to incoming requests without forwarding them to services. The DirectResponse resource lets you set up a pre-defined response body and HTTP status that you want to return to the client.

For more information, see DirectReponse.

JWT policies for routes

Now, you can apply JWT policies to specific routes by configuring the jwtProvidersStaged settings in the RouteOption resource. Previously, JWT policies applied at the gateway level and were configured in only the VirtualHostOption resource. With this new feature, you can apply JWT policies at both the route and gateway level. For more information and example steps, see Add JWT policy to routes.

Kubernetes 1.30 and 1.31 support

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

🔄 Feature changes

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

  • No feature changes are currently reported.