Ignore a service of type=LoadBalancer

[deitch]

Is there a way to have metallb ignore a Service of type=LoadBalancer? I couldn't find it in the docs or a brief search in the code.

From a UX perspective, I could see three ways to do this:

1. Annotation on the service, e.g. metallb.universe.tf/ignore=true or similar
2. configmap, where I can explicitly list services to ignore
3. My favourite, configmap, where I can provide annotations that, if set, would cause metallb to ignore the service.

The last is my favourite, as it is is very similar to the standard taints/tolerations. Short of that, I would do service annotation, followed by configmap.

But if it already exists, I will take whatever it has.

[johananl]

AFAIK there is no k8s equivalent to ingress class for service objects. I think this feature is similar in essence.

It makes sense to me to look into having some way to tell MetalLB to ignore a service (can be opt-in or opt-out). I'm curious about the use case though. Could you share some info regarding why you need this @deitch?

[deitch]

Could you share some info regarding why you need this @deitch?

Sure. Some services might not need (or want) to be managed by metallb. E.g. I may have a cluster with some services deployed where a LoadBalancer is managed by something else, some where it is managed by metallb.

All told, I probably could get the same effect with service.spec.externalIP, but I haven't tried it yet. That wouldn't help if I wanted something else to manage it, though.

[aledbf]

I'm curious about the use case though.

One use case is inlets. We could desire a service type=LoadBalancer in an IP address of the LAN but also with external connectivity using DO.
Right now I use the annotations in a service I don't want to be handled by metallb

    dev.inlets.manage: "true"
    metallb.universe.tf/address-pool: "dummy" #there is no such pool

[deitch]

That is smart, just adding a dead address pool. I would prefer a proper method, but that would work.

[aledbf]

@deitch me too :)

[aledbf]

@johananl I can help with this if makes sense. Like a new annotation metallb.universe.tf/manage: "false" to opt-out?

[johananl]

Thanks a lot @aledbf. I'd like to hear what @rata and @daxmc99 think about this before we decide to implement.

[champtar]

See also #607

[andersmarkendahl]

Hi!

Some thoughts on the topic.
The first part is mostly focusing on MetalLB controller and I comment on speaker at the end.

From our point of view, such a function would be useful in clusters which is running multiple customers where some customers use MetaLB and some do not.

In such a case, the function would be best implemented as an opt-in solution instead of an opt-out. Imagine CustomerA and CustomerB is deploying in parallel in a single cluster, where CustomerA will rely on MetalLB and CustomerB will solve it using another LB solution. CustomerB does not want to modify its manifest with an annotation to say that it will not use a software that might exist in some clusters. It becomes more tricky if the number of customers not using MetalLB grows.
For this reason it makes more sense to have MetalLB be configured in a way so that users must opt-in to use it.

Taking this into account I would like us to consider the already existing function for addresspools auto-assign. If set to false it means that metallb controller will not assign VIPs to services unless one of the following two things is done by customer (service manifest):

1. Use the metallb annotation for address pools

2. Requesting a specific VIP using loadBalancerIP.

Either of the two means that customer is making a decision to opt-in for MetalLB.
Using a metallb annotation obviously, but also picking a specific VIP since if you are sharing a cluster you are assumed to be aware of the IP plan and which IP ranges are yours.

In my mind this solution would suffice to cover this need. I am interested to hearing your thoughts...

I am unsure how the speaker behaves in case where another controller (not MetalLB) assigns a VIP, does it still announce it? (Please comment if you have knowledge on the topic)
If so this could possibly be solved by a change that MetalLB speaker checks the IP ranges in configmap and ignore any VIPs not showing there (it means another sw is managing it).

Best Regards
Anders

[juanrgm]

I am trying run multiple metallb controller on the same cluster but the address pool assignments are out of control, both controllers point to the same service and they are fighting continually by assigning the address.

So i think it would be util a optional service annotation for specify the controller.

metallb.universe.tf/controller-name: metallb-1

[andersmarkendahl]

Hi!

@juanrgm : I do not think multiple metallb controllers in a single Kubernetes cluster is officially supported.
MetalLB is a cluster-wide service in a Kubernetes cluster and is not meant to be running in parallel.

Also, I do think that your question is somewhat another topic, "running multiple MetalLB" much broader subject, likely to have other questions that must be resolved.

Best Regards
Anders

[rata]

@juanrgm I think several metallb controllers on the same cluster are really a different issue than this. Can you please open a new issue for that and explain the use case: why you need that, how you propose to address it, etc.?

[juanrgm]

Basically I want that metallb controller don't touch one service (ignore a service like says the issue title) because it will be consumed by other load balancer (casually other metallb).

So metallb controller only will use whose services that they have the same controller-name.