feat(gateway-api): Add custom backendRef and filters support for HTTPRoute

[kahirokunn]

Description

This PR adds support for custom backend references in Flagger's primary and canary services. This enhancement allows users to specify different routing configurations and intermediate services for primary and canary traffic, enabling more complex deployment patterns and better integration with existing infrastructure.

Key Changes

• Added backendRef and filters to spec.service.canary and spec.service.primary
• Updated Gateway API router to support custom backend references
• Modified service reconciliation logic to handle custom backend configurations
• Added support for service-specific filters
• Maintained backward compatibility with existing configurations

Use Cases

This feature enables several important scenarios:

1. Routing through security proxies
2. Adding service-specific monitoring
3. Implementing different circuit breaker configurations
4. Supporting complex mesh architectures
5. Applying different filtering rules for primary and canary traffic

Example Configuration

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: my-app
spec:
  service:
    primary:
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            set:
              - name: x-route
                value: primary
    canary:
      backendRef:
        name: canary-proxy
        namespace: monitoring
        port: 3456
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            set:
              - name: x-route
                value: canary

Breaking Changes

None. This is a backward-compatible change that maintains existing behavior when custom backend references are not specified.

Additional Context

This change also allows for cases where different backends are referenced for canary and primary, as shown in the attached image.
For details, please refer to the following PR.
#1714

Issue

#1741

TODO

• add finalize ReferenceGrants

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 42.57426% with 232 lines in your changes missing coverage. Please review.

Project coverage is 39.42%. Comparing base (21acd7e) to head (66df957).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/router/gateway_api.go	67.24%	52 Missing and 5 partials ⚠️
...ped/gatewayapi/v1beta1/fake/fake_referencegrant.go	22.05%	52 Missing and 1 partial ⚠️
...g/apis/gatewayapi/v1beta1/zz_generated.deepcopy.go	41.37%	50 Missing and 1 partial ⚠️
pkg/apis/flagger/v1beta1/zz_generated.deepcopy.go	0.00%	29 Missing and 2 partials ⚠️
...ernalversions/gatewayapi/v1beta1/referencegrant.go	0.00%	21 Missing ⚠️
...rsioned/typed/gatewayapi/v1beta1/referencegrant.go	0.00%	9 Missing ⚠️
...lient/listers/gatewayapi/v1beta1/referencegrant.go	0.00%	4 Missing ⚠️
...oned/typed/gatewayapi/v1beta1/gatewayapi_client.go	0.00%	2 Missing ⚠️
...s/externalversions/gatewayapi/v1beta1/interface.go	0.00%	2 Missing ⚠️
pkg/client/informers/externalversions/generic.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1742      +/-   ##
==========================================
- Coverage   39.42%   39.42%   -0.01%     
==========================================
  Files         284      288       +4     
  Lines       22422    22740     +318     
==========================================
+ Hits         8840     8965     +125     
- Misses      12632    12818     +186     
- Partials      950      957       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kahirokunn]

Dear @stefanprodan

I hope this message finds you well.

I am reaching out to request your review on an enhancement I am working on for the Flagger gateway API. My goal is to support the integration of Envoy Gateway with KEDA HTTPScaledObjects through this enhancement.

I would greatly appreciate your feedback and insights on this matter.

Thank you for your time and consideration.

Best regards,
kahirokunn

[aryan9600]

thank you for this PR @kahirokunn! have you tested how this change behaves when performing a canary rollout with session affinity enabled? that code also makes use of backend specific filters, so its important to verify that any userland configuration will not break that feature.

[kahirokunn]

Thank you so much for your feedback regarding session affinity! I will do my best to verify that these changes won’t break any existing session affinity behavior. However, to avoid any misunderstanding or missing test scenarios, would you mind sharing a bit more detail on the specific cases or concerns you have in mind about backend-specific filters and userland configurations? Your insights would be really helpful, and I appreciate your cooperation.

[aryan9600]

i'd recommend following the tutorial in the docs and seeing if the behaviour is as expected (in terms of request-response and how the HTTPRoute definition looks like)

[kahirokunn]

Hello,

Following your recommendation, I walked through the tutorial in the docs. I executed the tests as described using the Canary resource defined below:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  progressDeadlineSeconds: 60
  autoscalerRef:
    apiVersion: autoscaling/v2
    kind: HorizontalPodAutoscaler
    name: podinfo
  service:
    port: 9898
    targetPort: 9898
    hosts:
      - www.example.com
    gatewayRefs:
      - name: gateway
        namespace: istio-ingress
    primaryBackend:
      backendRef:
        name: hoge
        namespace: kube-system
        port: 10250
    canaryBackend:
      filters:
        - type: URLRewrite
          urlRewrite:
            hostname: www.example.com
  analysis:
    interval: 1m
    threshold: 5
    maxWeight: 50
    stepWeight: 10
    metrics:
    - name: error-rate
      templateRef:
        name: error-rate
        namespace: flagger-system
      thresholdRange:
        max: 1
      interval: 1m
    - name: latency
      templateRef:
        name: latency
        namespace: flagger-system
      thresholdRange:
        max: 0.5
      interval: 30s
    webhooks:
      - name: smoke-test
        type: pre-rollout
        url: http://flagger-loadtester.test/
        timeout: 15s
        metadata:
          type: bash
          cmd: "curl -sd 'anon' http://podinfo-canary.test:9898/token | grep token"
      - name: load-test
        url: http://flagger-loadtester.test/
        timeout: 5s
        metadata:
          cmd: "hey -z 2m -q 10 -c 2 -host www.example.com http://gateway-istio.istio-ingress/"

Based on this request, I confirmed that the following resources were created as expected:

1. ReferenceGrant

   • The ReferenceGrant resource was created in the kube-system namespace with the proper hash annotation and owner label, granting the gateway permission to reference the primary service (hoge).

2. HTTPRoute

   • The HTTPRoute resource in the test namespace was created with the correct configuration:
     • It has the expected hostname (www.example.com).
     • The parentRefs correctly points to the gateway in the istio-ingress namespace.
     • The rules include both backend references—one for the primary service and another (with a URL rewrite filter) for the canary—as well as the default match on the path /.

Moreover, tests have been written to validate this behavior. With these outcomes, the resources appear to adhere to the expected request-response behavior and the corresponding HTTPRoute definition matches.