Unable to Connect to Call External IP

[Sean Smith]

I'm using kubernetes on a cluster of raspberry pis on my home network. I've installed metallb to act as a load balancer. I'm not 100% sure this is a metallb issue but I'm really running out of avenues to explore.

My application has a simple endpoint that returns the word "root." when called at the root endpoint. This works whenever I call the LoadBalancer Ingress IP from inside the cluster, but if I call from outside the cluster (but still inside the network), I get the error.

Inside the cluster:
curl 192.168.1.150
root.

Outside the cluster (but inside the network):
curl 192.168.1.150
curl: (7) Failed to connect to 192.168.1.150 port 80: No route to host

The loadbalancer service:

$ kubectl get services -n goprom -o wide

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
goprom-lb LoadBalancer 10.110.156.125 192.168.1.150 80:31531/TCP 80s app=goprom

$ kubectl describe service -n goprom

Name: goprom-lb
Namespace: goprom
Labels: <none>
Annotations: <none>
Selector: app=goprom
Type: LoadBalancer
IP: 10.110.156.125
LoadBalancer Ingress: 192.168.1.150
Port: <unset> 80/TCP
TargetPort: 3333/TCP
NodePort: <unset> 31531/TCP
Endpoints: 10.244.1.26:3333,10.244.2.21:3333,10.244.2.22:3333
Session Affinity: None
External Traffic Policy: Cluster

My Metallb Config

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: address-pool-1
      protocol: layer2
      addresses:
      - 192.168.1.150-192.168.1.254

[Johannes Liebermann]

This curl error usually means the client didn't get a response to the ARP request it has sent, so this could be related to MetalLB since in layer 2 mode MetalLB is responsible for responding to ARP requests.

I would check the entire output of `kubectl describe service -n goprom`. You should see an event with a message such as "announcing from node X". If you don't, it means MetalLB isn't announcing the service for some reason. In this case I would check the logs of the MetalLB speaker pods for clues. If you do, I would run tcpdump on the node which appears in the output and ensure the ARP requests actually make it to the node and aren't dropped by a firewall.

If you suspect you've encountered a MetalLB bug, please open an issue at https://github.com/metallb/metallb/issues and include the exact steps to reproduce this issue.

Thanks!

--
You received this message because you are subscribed to the Google Groups "metallb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metallb-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/metallb-users/8007792d-558f-437e-ba86-8142b4991583n%40googlegroups.com.

--

Johannes Liebermann

Kinvolk GmbH | Adalbertstr. 6a, 10999 Berlin | tel: +491755589364
Geschäftsführer/Directors: Alban Crequy, Chris Kühl, Iago López Galeiras
Registergericht/Court of registration: Amtsgericht Charlottenburg
Registernummer/Registration number: HRB 171414 B
Ust-ID-Nummer/VAT ID number: DE302207000

[Sean Smith]

Hey Johannes,

Thank you very much for getting back to me about this issue I was having. I'm happy to report that it was not a MetalLB bug. I saw the event messages you mentioned "announcing from node X", and everything from what I could tell looked good. The problem ended up being that I needed to change a configuration in my router. I added the mac addresses of my raspberry PIs to the DHCP Access Control list.

Thanks again for getting back to me!

Sincerely,

Sean Smith

[Johannes Liebermann]

Sure, glad you've figured it out :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/metallb-users/eff7dc02-58e2-47c0-9c82-083a2a5e2917n%40googlegroups.com.