Combine Gateway Services when using HTTPRoute about kubernetes-ingress-controller HOT 5 OPEN

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)

from kubernetes-ingress-controller.

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.

from kubernetes-ingress-controller.

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.

from kubernetes-ingress-controller.

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

from kubernetes-ingress-controller.

@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.

from kubernetes-ingress-controller.