Update Gateway API to v1.3.0, target Envoy Gateway v1.5.0, expose new APIs#62
Merged
Conversation
Updated e2e test to avoid assertion failure on the `OverlappingTLSConfig` condition. Future work will be done to remove the v4 and v6 hostnames from being programmed on Gateways, which will remove this condition.
Before these changes, downstream gateways were being provisioned with listeners which are considered to have overlapping hostnames. This is a result of configuring the `<uuid>.<targetDomain>` hostname on a listener, along with the `[v4|v6].<uuid>.<targetDomain>` hostnames on listeners. When this occurs, Envoy Gateway will disable HTTP2 on the listeners, requiring explicit ALPN configuration via a ClientTrafficPolicy. To make sure we provide users with gateways which support HTTP2 out of the box, the decision was made to no longer configure the gateway with the v4 or v6 prefixed hostnames. These addresses will remain in DNS, responding only with A or AAAA records. In an effort to make it more clear to users which hostnames a gateway will accept, the system now injects default HTTP and HTTPS listeners into gateways created by the user which have the `<uuid>.<targetDomain>` hostname. The user may remove these listeners if they wish. All three DNS addresses will remain in the `Status.Addresses` field of the Gateway, which now makes this field more aligned with the intent defined in the spec. The default listener names are now `default-http` and `default-https`, which will result in the reconfiguration of some gateway resources upon deployment - particularly those maintained via HTTPProxy resources. See: https://gateway-api.sigs.k8s.io/geps/gep-3567/
…in the HTTPProxy reconciler, move the HTTPProxy reconciler to accumulate hostnames based on listeners and their status, instead of addresses.
Due to limitations in how Envoy Gateway programs listeners, a ClientTrafficPolicy cannot be applied to non-TLS listeners with overlapping ports. Application to TLS listeners works without issue, however the inconsistency is undesirable. Future TLS settings can be provided via the Gateway Listener's TLS configuration. Header manipulation, while not "early", can be accomplished today via `RequestHeaderModifier` filters. Timeouts can also be defined in existing route rules. Remaining features are mostly around tuning, where there can be generous defaults set on the platform.
Update Gateway API to v1.3.0, target Envoy Gateway v1.5.0.
Default Gateway hostname changes to avoid issues outlined in GEP-3567.
… HTTPRouteFilters, SecurityPolicies. Validation for BackendTrafficPolicies is complete. Validation for Backends, HTTPRouteFilters, and SecurityPolicies will come next, along with test coverage. A generic resource replicator has been created to replicate resources from upstream control planes into the downstream control plane, while transforming namespace names. In addition to the Envoy Gateway types now supported, there's default support to replicate ConfigMaps and Secrets which are labeled appropriately. Additional work is required to replicate downstream resource status into upstream resources. This will come in after validation and validation test suites are complete.
Add support for Envoy Gateway APIs: Backends, BackendTrafficPolicies, HTTPRouteFilters, SecurityPolicies.
…d SecurityPolicies. The next set of changes will add validation options to BackendTrafficPolicies, and wire validation options in from the service configuration. In the future, many of these limits may be influenced by quotas.
…figuration, setting sane defaults.
…JSON marshaling implementation, leverage defaulter-gen instead of direct defaulting functions.
…urce replicator. Each GVK can have a status transformer to rewrite fields such as namespaces or controller names. In addition, a handler can be registered to rewrite condition messages for specific condition types and reasons. This code was largely written with support by the gpt-5-codex model. I have reviewed both the reconciler and test suite to ensure it meets expectations.
Validation for Backends, BackendTrafficPolicies, HTTPRouteFilters, and SecurityPolicies.
Sync downstream resource status to upstream resources in gateway resource replicator.
…pdate downstream RBAC with necessary access for the operator.
Add new ProtectedResource entries for Envoy Gateway API Extensions
…d via Flux Kustomizations.
Move the webhook kustomization to be a Component so it can be included via Flux Kustomizations.
…nd not via a helm chart, required for use in Flux Kustomization.
…lease-artifact Install Gateway API and Envoy Gateway API CRDs via direct manifests
…gement Allow management of secrets in the downstream control plane.
Prefix cluster names obtained from UserInfo.Extra with a slash.
This suite expects to run against two control planes, which can be the same ones used for e2e tests. Run with: make test-conformance GATEWAY_CONFORMANCE_CLASS=network-services-operator-datum-external-global-proxy Other changes include: - Configuration option to allow Service backends for conformance testing. - Changing the label selector used by the Gateway resource replicator to "networking.datumapis.com/gateway-sync" for both ConfigMaps and Secrets.
…t and conformance suite execution.
- Upgraded controller-runtime dep to align with otel dep upgrade from Envoy Gateway dep. - Allow HTTPRouteFilter to be used as ExtensionRef filters in rules.
Gateway API conformance suite implementation.
…way API. Considering BackendTLSPolicy is moving from v1alpha3 to v1 in the v1.4.0 release of the Gateway API, we'll expose that version for users to integrate with. The v1alpha3 version is also available to use, and will auto upgrade to v1. There are currently no structural changes between the v1alpha3 and v1 versions of the CRD. The operator will configure downstream BackendTLSPolicies with v1alpha3, until Envoy Gateway is updated to support v1. The only restriction added to BackendTLSPolicies is that they must target Backend resources only. The generic resource replication controller has been configured to replicate BackendTLSPolicies between the upstream and downstream clusters, with a tweak to update the upstream resource's status using the v1 version of the CRD.
Support v1 BackendTLSPolicies from the v1.4.0-rc2 release of the Gateway API.
…d viewer roles with necessary permissions.
Add ProtectedResource for BackendTLSPolicies, update gateway admin and viewer roles with necessary permissions.
Forgot to add the BackendTLSPolicy ProtectedResource to the kustomization.
scotwells
previously approved these changes
Oct 3, 2025
…way APIs are installed. The Makefile was changed to not deploy envoy-gateway to the standard cluster during prepare-e2e, which results in this need.
…eady before GatewayClass resource is created.
scotwells
approved these changes
Oct 3, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The following CRDs will be installed into project control planes and available to users to tweak gateway resource configuration:
Note
The HTTPProxy resource has not been directly updated to support features provided by the above API types. However, users can apply policies that target the underlying Gateway and HTTPRoute resources managed by an HTTPProxy if they wish.
Default Gateway hostnames
From #49
Before these changes, downstream gateways were being provisioned with listeners which are considered to have overlapping hostnames. This is a result of configuring the
<uuid>.<targetDomain>hostname on a listener, along with the[v4|v6].<uuid>.<targetDomain>hostnames on listeners. When this occurs, Envoy Gateway will disable HTTP2 on the listeners, requiring explicit ALPN configuration via a ClientTrafficPolicy.To make sure we provide users with gateways which support HTTP2 out of the box, the decision was made to no longer configure the gateway with the v4 or v6 prefixed hostnames. These addresses will remain in DNS, responding only with A or AAAA records.
In an effort to make it more clear to users which hostnames a gateway will accept, the system now injects default HTTP and HTTPS listeners into gateways created by the user which have the
<uuid>.<targetDomain>hostname. The user may remove these listeners if they wish. All three DNS addresses will remain in theStatus.Addressesfield of the Gateway, which now makes this field more aligned with the intent defined in the spec.The default listener names are now
default-httpanddefault-https, which will result in the reconfiguration of some gateway resources upon deployment - particularly those maintained via HTTPProxy resources.See: https://gateway-api.sigs.k8s.io/geps/gep-3567/
Conformance suite and e2e tests
The Gateway API conformance suite and Envoy Gateway e2e tests have been incorporated into the project, providing significant test coverage for both control plane and data plane concerns.
Syncing ConfigMaps and Secrets
APIs introduced in these changes may need to reference ConfigMaps or Secrets to be useful. Users must add the
networking.datumapis.com/gateway-synclabel to these resources in order for them to be synced to edge clusters. This requirement is in place to prevent replication of unrelated secrets (metric exports, future services), and to avoid what would be a significant amount of code to support replicating only resources which are referenced by configurations.References
PRs that went into this integration branch:
Closes: