External LoadBalancing/IP overwrite for gateway-service

As I was trying out linkerd with our infrastructure I encountered a problem with the required service with type loadbalancer. We have an external loadbalancer which sends everything to the node, where ambassador is running with a service type nodeport.

Are there ways to overwrite the used IP for the gateway? As I understand the IP gets read from the service-status, and not even externalIPs from the service-definition are used. ( An annotation on the service would also be enough)

Or are there any known plans to include functionality to support external loadbalancers instead of the service-type loadbalancer?

Cheers and I’m thankful for any help I can get on this issue.

@stebenz are you using Linkerd for mutli-cluster? Just want to make sure that we are talking about the same gateway-service.

Since Linkerd relies on Kubernetes functionality, I don’t think that there are plans to support external load balancers. You might try starting a discussion on GitHub.

@cpretzer yes, the idea was to build a multi-regional cockroachdb with the help of linkerd and multiple clusters based on google cloud vms.
The clusters each have a running ambassador with nodeport service where an external loadbalancer handles the traffic to the nodes which share 1 external IP (to be exact 2 as the kubeapi has a seperate IP).

So Linkerd doesn’t need to support external load balancer, but it would have to support another way to provide the external IP besides the requirement to support service with type LoadBalancer.

When you say “provide the external IP”, do you mean that the external IP for the Linkerd gateway should be configurable?

For most cloud providers which support automatic allocation of IP addresses for a LoadBalancer type, you can specify the address from a pool of static IP addresses that you reserve.

I think that this is a great scenario for an RFC to outline the requirements for this functionality and the design for the solution. Are you interested in writing that up?

No, not exactly, if there is no service type LoadBalancer possible, but there is a load balancer in place outside of the k8s-cluster, there is no possibility to use this IP as the gateway.
Because the IP used in a multicluster scenario can only be read directly from the kubeAPI, as resource-field .status.loadbalancer.ingress .

As the IP is technically used by the nodes, but connected trough nodeports directly to ambassador, a service type LoadBalancer is no option.

@stebenz I saw your post in GitHub discussions and the additional context makes sense to me now.

What do you think about the approach with the Link CRD?