NodePort Range not Exposed

[cawoodm]

I'm having difficulty exposing any NodePorts (following this guide).

This is made difficult by the fact that I do not know, when creating a cluster, which ports I will be using. Nevertheless I expose 100 ports at startup thusly:

k3d cluster create myb-dev --agents 3 -p "30000-30100:30000-30100@server[0]

My assumption is that this will map port 30010 on my host to 30010 on the cluster?

It does not work however - I have a NodePort on 30010 and it is inaccessible.

1. How to view the port mapping k3d has set up?
2. How to change the port mapping without destroying the cluster?
3. How to debug such connectivity issues?

I know I can use port-forwarding but this is tedious and gets lost each time a pod is destroyed.

[iwilltry42]

Hi @cawoodm , thanks for starting this discussion!
I'm pretty sure I answered this somewhere else already, but I cannot find it right now 🤷‍♂️

I do not know, when creating a cluster, which ports I will be using

k3d v5 will bring a relief to that 😉

It does not work however - I have a NodePort on 30010 and it is inaccessible

I tried exactly your command without issues and have that exact port-mapping setup though 🤔

How to view the port mapping k3d has set up?

k3d passes exactly that through to docker: 30000-30100:30000-30100.
You can additionally check it via docker ps (shows 073d04db2553 rancher/k3s:v1.21.3-k3s1 "/bin/k3s server --t…" 4 minutes ago Up 4 minutes 0.0.0.0:30000-30100->30000-30100/tcp, :::30000-30100->30000-30100/tcp k3d-myb-dev-server-0 for me)
Then, a docker inspect on that ID (for me docker inspect 073d04db2553) shows you all the details, including the exact port-mapping for those ranges, which is 1:1 for me as you wanted it to be.

How to debug such connectivity issues?

What's the response you get and how do you try to access it?

I know I can use port-forwarding but this is tedious and gets lost each time a pod is destroyed.

Would using Ingress be an option? Also, I'm not sure, but if you use kubectl port-forward on a Service instead of a Pod, it may keep the connection even if the Pod behind it goes down (didn't try though).