Skip to content

Add support for envoy gateway#5150

Open
smatting wants to merge 64 commits intodevelopfrom
WPB-23903-routes-1
Open

Add support for envoy gateway#5150
smatting wants to merge 64 commits intodevelopfrom
WPB-23903-routes-1

Conversation

@smatting
Copy link
Copy Markdown
Contributor

@smatting smatting commented Mar 23, 2026

This PR:

  • Introduces a new Helm chart wire-ingress that targets Envoy Gateway. It is intended as a
    replacement for the nginx-ingress-services chart, which uses ingress-nginx.
    The wire-ingress chart is not production-ready yet.

  • Changes the integration test suite: all tests now run against the wire-ingress chart. The
    ingress solution can be selected via the WIRE_INGRESS_MODE environment variable.
    The federation domains change in Envoy mode — see comments in the code.
    Changes to the federator and integration charts are made to accommodate both variants for
    testing. As a consequence, any changes to nginx-ingress-services will be untested once this PR
    is merged. I've added a check integration-setup-federation.sh that prevents any changes to
    nginx-ingress-services to avoid this being overlooked.

  • Changes the temporary filenames used in the integration test suite. This fixes issues with
    filenames that were too long for nginz to handle.

  • Deletes the unused file hack/helmfile-federation-v0.yaml.gotmpl.

  • Add a post-upgrade to all objects needed for testing. This makes running tests on the cluster manually more convenient

Checklist

  • Add a new entry in an appropriate subdirectory of changelog.d
  • Read and follow the PR guidelines

@smatting smatting force-pushed the WPB-23903-routes-1 branch from c4a1b87 to 28aad07 Compare March 23, 2026 13:59
@zebot zebot added the ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist label Mar 23, 2026
@wartraxx51
Copy link
Copy Markdown

wartraxx51 commented Mar 24, 2026

Naming thing that bugs me across the whole PR, the chart is wire-ingress, the file is ingress-envoy.yaml the route is nginz-websockets. None of thes have any Ingress in them. My point of view, name it like the replacement wire-gateway , gateway-envoy.yaml etc... not blocking when I open a file called ingress-envoy.yaml and the first thing I see is kind: gateway. I have to stop and double check.

@wartraxx51
Copy link
Copy Markdown

A BackendTrafficPolicy is missing for WebSockets, the default timeouts will terminate long-lived connections, I didn't check the default value, https://gateway.envoyproxy.io/latest/api/extension_types/#backendtrafficpolicy

@smatting smatting force-pushed the WPB-23903-routes-1 branch from 8e81e3f to 83b86e7 Compare March 25, 2026 14:02
@smatting
Copy link
Copy Markdown
Contributor Author

Naming thing that bugs me across the whole PR, the chart is wire-ingress, the file is ingress-envoy.yaml the route is nginz-websockets. None of thes have any Ingress in them. My point of view, name it like the replacement wire-gateway , gateway-envoy.yaml etc... not blocking when I open a file called ingress-envoy.yaml and the first thing I see is kind: gateway. I have to stop and double check.

I changed the ingress-envoy.yaml filename. But I couldn't find other occurences. Everywhere the filenames should be <kind>...
Can you please more concrete?

@smatting
Copy link
Copy Markdown
Contributor Author

smatting commented Mar 25, 2026

A BackendTrafficPolicy is missing for WebSockets, the default timeouts will terminate long-lived connections, I didn't check the default value, https://gateway.envoyproxy.io/latest/api/extension_types/#backendtrafficpolicy

Thank you! Added the policy. We need to run QA tests against this on staging to see if it really works

@smatting smatting marked this pull request as ready for review March 25, 2026 14:26
@smatting smatting requested review from a team as code owners March 25, 2026 14:26
- type: Inline
inline: |
function envoy_on_request(request_handle)
local ssl = request_handle:connection():ssl()
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something feels off here, we are trusting a header that the client may be able to forge themselves. Since we do not remove it first, it looks spoofable. Is that really expected on the Federator side?

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
name: {{ include "wire-ingress.fullname" . }}-federator-cert-header
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other policies in this chart set namespace: {{ .Release.Namespace }} ?

- type: Inline
inline: |
function envoy_on_request(request_handle)
local ssl = request_handle:connection():ssl()
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same headers():add issue

name: {{ printf "%s/%s/https" .Release.Namespace $gatewayName | quote }}
operation:
op: add
path: "/filter_chains/0/filters/0/typed_config/strip_trailing_host_dot"
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't you use the same approach las in charts/wire-ingress/templates/envoypatchpolicy-federator.yaml:36-41

@@ -0,0 +1,154 @@
{{- if .Values.envoy.enabled }}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

None of the five kinds here carry chart/release label

apiVersion: v1
kind: Service
metadata:
name: account-pages-http
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no label, no namespace

apiVersion: v1
kind: Service
metadata:
name: team-settings-http
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no label, no namespace

kind: Service
metadata:
name: {{ .Release.Namespace }}-fed
namespace: {{ .Values.gateway.controllerNamespace }}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no label

apiVersion: v1
kind: Service
metadata:
name: webapp-http
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no label, no namespace

apiVersion: v1
kind: Service
metadata:
name: {{ .Release.Namespace }}-fed
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The -fed suffix here is also hardcoded in integration/_helpers.tpl .Both need to stay aligned renaming one side breaks federation discovery with no obvious error.
Ideally a shared helper ? otherwise at least a cross-reference comment in both files pointing to each other ? that would also explain why we don't use wire-ingress.fullname here like everywhere else

# -----END PRIVATE KEY-----
#
# When federator.enabled is true, a ConfigMap named `federator-ca` with a `ca.crt` key
# must exist in the release namespace. It is created by the wire-server chart
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This ConfigMap is created by the federator chart, not wire-server ?

### Gateway API

Install the [Gateway API](https://gateway-api.sigs.k8s.io/) into your cluster.
This chart makes use of the of the kinds defined in the `gateway.networking.k8s.io/v1` API.
Copy link
Copy Markdown

@wartraxx51 wartraxx51 Apr 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use of the of the, bad copy paste :)

controllerName: gateway.envoyproxy.io/gatewayclass-controller
```

You need to refer to this object in the `gateway.className` paramter.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

parameter

| `config.dns.base` | Only used for CSP header rendering, which is a multi-ingress feature |
| `tls.verify_depth` | Envoy Gateway `ClientTrafficPolicy` does not expose a direct verify-depth knob; the CA chain itself controls this |
| `tls.enabled` | Removed — had no effect; all routes are always TLS-terminated |
| `secrets.tlsClientCA` | No longer supplied via values. The `federator-ca` ConfigMap is created by the wire-server chart and referenced directly. |
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is created by federator chart ?

@@ -0,0 +1,75 @@
{{/* vim: set filetype=mustache: */}}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getCertificateSecretName, getCustomSolversSecretName, getIssuerName, getGatewayName
I would use it without get, because in Helm charts you usually use short names focused on the result but that's just my opinion

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ok-to-test Approved for running tests in CI, overrides not-ok-to-test if both labels exist

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants