[FIX] do not ignore --no-hostip and don't try to inject if network = host

[konradmalik]

Fix for: #470 + implemented the suggestion that docker host injection should not be performed when network=host.

[ammmze]

Not sure if I'm missing something else, but with this fix I am able to create my cluster with --network host --no-hostip, however it may be worth noting, the kubeconfig points to the incorrect api port. It still points to the random port that normally would have gone to the k3d-proxy / serverlb that proxies to the api server on 6443. So effectively the kubeconfig changes aren't valid out of the gate.

[konradmalik]

I also noticed this behavior. I may be wrong but I think this is unrelated to this fix.
The issue you are describing is because when network is host the load balancer is not created, but kubeconfig still points to a random port, as this is the default imposed by api-port argument.

I can look into it and fix here or in another PR soon but need to ask someone (@iwilltry42 probably):
Not sure how should api-port argument be handled in this case. It defaults to random, but when network is host, it will be 6443 by default because of k3s (unless anything custom is provided to k3s-server-arg). Changing api-port via k3d cli will not work, in this case all is dependent on k3s.
My idea would be:
if network is host

• try to extract any custom api port provided by the user via k3s-server-arg. This will be the ground truth that overwrites anything else.
• If nothing was provided, pass through anything that is in api-port, so either a random value or the thing that user specified.
• The result of this will go into kubeconfig.

An alternative is to completely ignore k3s-server-arg and handle only the 2 and 3 point abouve, as k3s-server-arg is a "hack" of sorts and assume that if a user uses that, he/she is aware that manual work may be needed. I'm thinking also about all the other k3s custom arguments that k3d probably won't cover and automate as this is not the point.

[ammmze]

👍 I think it is reasonable to have it be a separate issue and can be addressed in a separate PR. I haven't tested this specifically, but I think you can easily work around it if you include --api-port 6443 when creating your cluster.

[iwilltry42]

Hi @konradmalik , thanks for this PR!
That's indeed a nice little bug you found there 😬
I will merge it right away 👍

For the other issue mentioned in the comments, please open a separate issue (or even PR :)).
I think (without checking) we could solve this "easily" by simply not defaulting to a random exposed port when network=host is set. That way, the kubeconfig shouldn't get modified there and use k3s' default value of 0.0.0.0:6443 (or 127.0.0.1:6443), which should work then, right?

[iwilltry42]

LGTM! Thank you :)

[konradmalik]

I think (without checking) we could solve this "easily" by simply not defaulting to a random exposed port when network=host is set. That way, the kubeconfig shouldn't get modified there and use k3s' default value of 0.0.0.0:6443 (or 127.0.0.1:6443), which should work then, right?

Sure, I think I tried to overcomplicate things. I'll do this in a separate PR soon ;)