Marcel Fest
Marcel Fest
@chrisarnott86 you can use it with metallb. Just watch the status of the service kube-vip and metallb will fight there. Just disable status update on kube-vip should solve your problem.
```yaml - name: disable_service_updates value: "true" ```
Just inform here if it solved your issue.
@chrisarnott86 did you capture some logs from the 0.9.1 trial? There was an issue in 0.9.1 with map concurrency read/write.
@chrisarnott86 you could just disable the metallb speaker and only use kube-vip as the speaker and metallb-controller only for the IP management.
Having two ARP speakers could lead to unexpected behaviors if you do not use loadbalancerclass or the label for kube-vip.
@chrisarnott86 which cni do you use? As with calico we documented a fix which ensures the rule stays as it should. Otherwise we need a bit more info on your...
Do you have multiple nodes and multiple replicas? And spread the replicas across the nodes? Then only the current leader can originate traffic for the loadBalancerIP as the others don’t...
@chrisarnott86 is it the same behavior with new and old egress implementation?
@antoinemichea your comment does not really fit to this issue. Did you try the v0.9.2 release? Can you copy your comment into a new issue?