Combine Gateway Services when using HTTPRoute

[mheap]

Is there an existing issue for this?

• [X] I have searched the existing issues

Does this enhancement require public documentation?

• [X] I have added an Acceptance Criteria item for adding and/or adjusting public documentation (if applicable)

Problem Statement

When using HTTPRoute, multiple Kong services are generated that point to the same backend. This has an impact on functionality (per-service rate limiting) and pricing.

Proposed Solution

Reuse services when HTTPRoute definitions are identical

Additional information

Notes from @czeslavo:

There are Gateway API cases that we need to take into account (allowing multiple backend refs in a single rule is a fundamental one). I think that we could slightly improve by generating fewer Kong Services from HTTPRoutes e.g. by merging Kong Services from different HTTPRoutes if they are using exactly the same target refs (not only Kubernetes Services behind them, but also their weights, and potentially filters if we decide to support them - currently we don’t). But that still won’t work the same way as Ingress does where you may expect almost 1-1 Kong Service - Kubernetes Service mapping (with an exemption of different ports of a single Kubernetes Service generating separate Kong Services). We’d still have to distinguish the Kong Service is generated from HTTPRoute and the httproute in their names is about that.

Acceptance Criteria

• [ ] All HTTPRoutes that use identical targetRefs (same service, weight, filters) point to a a single Kong Service

[jeromeguillaume]

There is an impact on Konnect - API Product too. Right now if you define, for instance, 3 HTTPRoutes concerning the same Kubernetes Service, you have 3 Gateway Services and consequently 3 API Products. So finally we have 3 entries in the Developer Catalog whereas it's the same API (i.e. same Kubernetes service)

[randmonkey]

A question about naming of translated services: how should we name the translated Kong services, as they can come from different HTTPRoutes:

• Use the same pattern httproute.<namespace>.<name>.<rule index> of the "first" HTTPRoute rule in some consistent order (like alphabetical order of NS and name)
• Use attributes of backends like the pattern svc.<ns>.<name> as Ingress do
• Use a hash of the attributes of backends I would choose (1) because there are too many attributes on backends of HTTPRoutes. (1) could give a more controllable pattern of names.

[piotrwielgolaski-tomtom]

I would love ingress format, but it could be problematic if different filtered are used.

Version relying on index of first route sound risky, as adding new route could change service name

maybe ingress format followed by has of parameters like filters.

[piotrwielgolaski-tomtom]

Also it would be very useful to know k8s service and namespace in access log

[randmonkey]

@mheap I want to discuss what are included in the "target ref" to group Kong services:

• Should we include filters? In the current supported filters, we translate them to plugins attached to Kong routes. So filters does not affect attributes of services. And also we do not support per backend filters. If we do not translate them (also no potential supporting filters) to fields or plugins of Kong services, I think it is OK to ignore filters in grouping Kong services.
• Should we consider timeouts? The timeouts of rules affects *_timeout of Kong service, but the existing logic of combining services already grouped rules with same backends but different timeouts.

Also, should we put this feature behind a feature gate and disable it by default? I think yes (like what we have done for CombinedRoutes and CombinedServices) because it is a significant and user facing change, and there will be pontetial changes happen to the feature itself.