Open mheap opened 5 months ago
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)
A question about naming of translated services: how should we name the translated Kong services, as they can come from different HTTPRoutes
:
httproute.<namespace>.<name>.<rule index>
of the "first" HTTPRoute
rule in some consistent order (like alphabetical order of NS and name)svc.<ns>.<name>
as Ingress
doHTTPRoute
s. (1) could give a more controllable pattern of names.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.
Also it would be very useful to know k8s service and namespace in access log
@mheap I want to discuss what are included in the "target ref" to group Kong services:
*_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.
Is there an existing issue for this?
Does this enhancement require public documentation?
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:
Acceptance Criteria