Feature Request: Support Customization of Generated HTTPRoute in Flagger for GatewayAPI

[kahirokunn]

Describe the feature

Currently, the HTTPRoute resource generated by Flagger for GatewayAPI does not allow customization. This limits the ability to fine-tune traffic management for advanced use cases such as custom filters, matches, and timeouts.

What problem are you trying to solve?

In many scenarios, users require additional flexibility when configuring traffic routing. For instance, adding specific filters (e.g., headers transformations), defining matches for traffic segmentation (e.g., path or header-based routing), or configuring timeouts for HTTP requests are critical for optimizing traffic behavior. The inability to customize these aspects makes it challenging to align Flagger's generated resources with complex application requirements or organizational policies.

Proposed solution

Add a mechanism to customize the HTTPRoute resource generated by Flagger. This could involve extending the Canary CRD to include additional fields for specifying filters, matches, and timeouts that would be applied to the generated HTTPRoute.

For example:

spec:
  gateway:
    http:
      filters:
        - type: RequestHeaderModifier
          requestHeaderModifier:
            add:
              x-custom-header: value
      matches:
        - path:
            type: Prefix
            value: /custom-path
      timeouts:
        request: 5s

Benefits

• Provides greater flexibility to tailor HTTPRoute behavior.
• Reduces the need for manual post-processing or additional tooling to modify generated HTTPRoute resources.
• Aligns Flagger with more complex GatewayAPI use cases.

Drawbacks

• Adds complexity to the Canary CRD and its reconciliation logic.
• Requires users to understand GatewayAPI specifications, which might increase the learning curve.

Any alternatives you've considered?

1. Manual modification of HTTPRoute: Users can manually edit the generated HTTPRoute resources, but this is not sustainable as changes will be overwritten during reconciliation.
2. Custom controllers: A custom controller could be created to patch the HTTPRoute resources after Flagger generates them, but this adds operational overhead and maintenance burden.
3. CRD annotations or external configuration: Using annotations or external configuration to specify customization. However, this approach might not provide the same level of flexibility and could lead to configuration drift.

Allowing HTTPRoute customization directly within Flagger's configuration would be a more user-friendly and maintainable solution.

[kahirokunn]

move to #1741