Metallb: Listen to UDP broadcast traffic

[ofcourseican]

Is this a bug report or a feature request?:
not sure

What happened:
I run a server inside a Raspberry PI Cluster that listens to UDP broadcast traffic on a specific port to discover clients. This does not work. I'm not sure if I just misconfigured something or if this is an actual bug.

What you expected to happen:
I would expect that UDP Broadcast traffic to be routed to the service pod.

How to reproduce it (as minimally and precisely as possible):
My service description:

apiVersion: v1
kind: Service
metadata:
  name: lms-web
  namespace: lms
  annotations:
    metallb.universe.tf/allow-shared-ip: lms
spec:
  type: LoadBalancer
  ports:
  - name: http
    protocol: TCP
    port: 9000
    targetPort: 9000
  selector:
    app: lms

---
apiVersion: v1
kind: Service
metadata:
  name: lms-cli
  namespace: lms
  annotations:
    metallb.universe.tf/allow-shared-ip: lms
spec:
  type: LoadBalancer
  ports:
  - name: cli
    protocol: TCP
    port: 9090
    targetPort: 9090
  selector:
    app: lms

---
apiVersion: v1
kind: Service
metadata:
  name: lms-control-udp
  namespace: lms
  annotations:
    metallb.universe.tf/allow-shared-ip: lms
spec:
  type: LoadBalancer
  ports:
  - name: control
    protocol: UDP
    port: 3483
    targetPort: 3483
  selector:
    app: lms

---
apiVersion: v1
kind: Service
metadata:
  name: lms-control-tcp
  namespace: lms
  annotations:
    metallb.universe.tf/allow-shared-ip: lms
spec:
  type: LoadBalancer
  ports:
  - name: control
    protocol: TCP
    port: 3483
    targetPort: 3483
  selector:
    app: lms

My metallb configmap:
```apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: my-ip-space
protocol: layer2
addresses:
- 192.168.1.221-192.168.1.235

**Anything else we need to know?**:
If it helps, I'm trying to run a Logitech Media Server on Kubernetes which needs the UDP traffic to discover its payers.


**Environment**:
- MetalLB version: 0.7.3
- Kubernetes version: v1.11.1
- OS (e.g. from /etc/os-release): 

PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
HYPRIOT_OS="HypriotOS/armhf"
HYPRIOT_OS_VERSION="v2.0.1"
HYPRIOT_DEVICE="Raspberry Pi"
HYPRIOT_IMAGE_VERSION="v1.9.0"
```

• Kernel (e.g. uname -a):
  Linux k8s-node04 4.14.34-hypriotos-v7+ #1 SMP Sun Apr 22 14:57:31 UTC 2018 armv7l GNU/Linux

[danderson]

Kubernetes's LoadBalancer logic (which MetalLB relies on) does not support forwarding broadcast traffic into pods, so this simply will not work in k8s, sorry. The only option you have is to run the pods with hostNetwork=true and try to wrangle something with that, but you won't get stable IPs with that setup.

Nothing I can do about this, it's a shortcoming burned into k8s.

[Queuecumber]

@danderson Do you mind elaborating on that? I think this its worth making a feature request to kubernetes so I want to make sure I understand the problem before I propose a solution

[varac]

@danderson I'd also like to follow up the main k8s issue with this, can you please point us to any existing issue which documents this limitation ?