quickstart fails to properly deploy BBR

[davidbreitgand]

What happened:

Following the quickstart guide to deploy BBR with Istio. The following error happens:

% helm install body-based-router
--set provider.name=istio
--version v1.0.0
oci://registry.k8s.io/gateway-api-inference-extension/charts/body-based-routing
Pulled: registry.k8s.io/gateway-api-inference-extension/charts/body-based-routing:v1.0.0
Digest: sha256:1105436ffd7a5a2d3d4cf142023e0427094bc8f1c40db7359a642cb9a783d9f5
Error: INSTALLATION FAILED: 1 error occurred:

• EnvoyFilter.networking.istio.io "body-based-router" is invalid: spec.configPatches[0].match: Invalid value: "object": no such key: context evaluating rule: only support waypointMatch when context is WAYPOINT

What you expected to happen:

I expected to deploy without error in the Envoy filter configuration.

How to reproduce it (as minimally and precisely as possible):

Run BBR deployment step accodrding to this guide.

Anything else we need to know?:

The BBR pod starts OK. There is the configuration problem with Envoy filter.

Environment:

• Kubernetes version (use kubectl version): v1.30.13
• Inference extension version (use git describe --tags --dirty --always): 22e2dbf-dirty
• Cloud provider or hardware configuration: Apple M1 Max, Sequoia 15.6.1 (local kind cluster)
• Istio: 1.28-alpha.dd911f922bed8e25a3e36ea93b5abff64bc1c80f
• Install tools:
• Others:

[davidbreitgand]

The context in ./config/charts/body-based-routing/templates/istio.yaml is intentionally left unspecified.
From looking at the Istio EnvoyFilter validation, it seems that the context can indeed be left unspecified, because the validator skips most of the checks and specifically WAYPOINT.

From looking at the CRD level, it also appears that it can be left unspecified.
kubectl get crd envoyfilters.networking.istio.io -o yaml, because the CRD defines the context property with an enum (ANY, SIDECAR_INBOUND, SIDECAR_OUTBOUND, GATEWAY, WAYPOINT) but does not mark it as required.

There is no required listing for context, and no x-kubernetes-validations forcing presence. So a CR that omits context is valid against this CRD

When I used ANY to test whether behavior would change, the behavior indeed changed. The helm chart apparently successfully deployed with no error, but in fact the filter was not added as follows from inspecting the Istio configuration 🤷‍♂️.

This seems to be the culprit.

Used in this validation function uses the "user provided" data for CRD validation as in the test yaml above.

I'm under impression that with Istio 1.28 the context cannot be left unspecified.

[davidbreitgand]

Forgot to add:

1. Local validation:

helm install body-based-router ./config/charts/body-based-routing
--set provider.name=istio \
--set inferenceGateway.name=inference-gateway
Error: INSTALLATION FAILED: 1 error occurred:

• EnvoyFilter.networking.istio.io "body-based-router" is invalid: spec.configPatches[0].match: Invalid value: "object": no such key: context evaluating rule: only support waypointMatch when context is WAYPOINT

davidbr@Davids-MBP gateway-api-inference-extension % git describe --tags --dirty --always
v1.0.2
davidbr@Davids-MBP gateway-api-inference-extension % git status
On branch release-1.0
Your branch is up to date with 'upstream/release-1.0'.

nothing to commit, working tree clean

2. Using ANY as the value for context in

./config/charts/body-based-routing/templates/istio.yaml:

{{- if eq .Values.provider.name "istio" }}

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
name: {{ .Values.bbr.name }}
namespace: {{ .Release.Namespace }}
spec:
configPatches:

• applyTo: HTTP_FILTER
  match:

  context omitted so that this applies to both sidecars and gateways

  context: ANY
  listener:
  filterChain:
  filter:
  name: "envoy.filters.network.http_connection_manager"
  patch:
  operation: INSERT_FIRST
  value:
  name: envoy.filters.http.ext_proc
  typed_config:
  "@type": type.googleapis.com/envoy.extensions.filters.http.ext_proc.v3.ExternalProcessor
  failure_mode_allow: false
  allow_mode_override: true
  processing_mode:
  request_header_mode: "SEND"
  response_header_mode: "SKIP"
  request_body_mode: "FULL_DUPLEX_STREAMED"
  response_body_mode: "NONE"
  request_trailer_mode: "SEND"
  response_trailer_mode: "SKIP"
  grpc_service:
  envoy_grpc:
  cluster_name: outbound|{{ .Values.bbr.port }}||{{ .Values.bbr.name }}.{{ .Release.Namespace }}.svc.cluster.local

---

apiVersion: networking.istio.io/v1
kind: DestinationRule

The bbr pod starts, but curl to the second inference pool fails and the logs in bbr are empty (except the initialization), so it appears that the bbr EnvoyFilter does not execute.

kc logs body-based-router-cd864b869-2cqdd
2025-10-23T16:34:53Z INFO setup cmd/main.go:76 Flags processed {"flags": {"grpc-health-port":9005,"grpc-port":9004,"kubeconfig":"","metrics-port":9090,"streaming":true,"v":3,"zap-devel":true,"zap-encoder":{},"zap-log-level":{},"zap-stacktrace-level":{},"zap-time-encoding":{}}}
2025-10-23T16:34:53Z INFO setup cmd/main.go:119 Manager starting
2025-10-23T16:34:53Z INFO controller-runtime.metrics server/server.go:208 Starting metrics server
2025-10-23T16:34:53Z INFO runnable/grpc.go:35 gRPC server starting {"name": "health"}
2025-10-23T16:34:53Z INFO runnable/grpc.go:44 gRPC server listening {"name": "health", "port": 9005}
2025-10-23T16:34:53Z INFO controller-runtime.metrics server/server.go:247 Serving metrics server {"bindAddress": ":9090", "secure": false}
2025-10-23T16:34:58Z INFO runnable/grpc.go:35 gRPC server starting {"name": "ext-proc"}
2025-10-23T16:34:58Z INFO runnable/grpc.go:44 gRPC server listening {"name": "ext-proc", "port": 9004}