@jan3 wrote:
two ideas for using the loadbalancer with the ingress:
a) the tunnel names are too verbose to propperly debug, so it would be helpful if the tunnel id would be prefixed with the service name from the ingress definition
b) for load balanced normal operation the current setup is good enough, but i would propose a second mode for load balanced ingresses (if the pool annotation is present):
if the ingress references not a normal service but a headless k8 service, not the service is treated as one origin but every matched pod is one origin in the load balancer, the ingress controller would in this case not use the cluster internal resolution but use the headless service for pod discovery and forward traffic directly to the pod ips. the advantages of this setup: currently to achieve this, we need to create a service with pod label matching and ingress for every pod in a stateful set, the proposed operation would allow to just use the headless service that most stateful sets need anyways for discovery, so a lot reduced configuration. secondly because the additional lookup phase from service ip to pod ip would be gone, as well as the kube-proxy overhead of managing the iptables for this step, the latency should be reduced.