Local Garden Dev on Windows

[guydc]

How to categorize this PR?
/area dev-productivity
/kind enhancement
/priority normal

What this PR does / why we need it:

Fixes local-garden containers' host machine address and api-server binding, such that the nodeless gardener dev env will work on WSL2 with WSL2-integrated docker for windows.

Release note:

The Nodeless Development Environment also works on windows, using WSL2 and docker for windows

[vpnachev]

Thanks for the contribution of support for local setup running on windows.

Could you add some info about it in the local setup. Basically a disclaimer that windows is supported for local development (we have not declared so far that it was working only on MacOS and Linux distros, this will have to be mentioned, too)
Also, list the limitations and prerequisites, if any.

[timebertt]

Thanks for enabling the local setup on WSL!
/lgtm from a code perspective, but I can't test it on windows...

/ok-to-test

[vpnachev]

/ok-to-test

[vpnachev]

Just a minor improvement of the documentation.
Otherwise looks good to me as I am also not able to validate it.

[timebertt]

/status author-action

[gardener-robot]

@guydaichs The pull request was assigned to you under author-action. Please unassign yourself when you are done. Thank you.

[danielfoehrKn]

@mandelsoft are you able to test this as to my knowledge you at least have a windows machine?

[guydc]

There is one issue that I didn't manage to solve: gardenlet fails to establish the VPN tunnel to the shoot. I'm not sure if it's a general limitation, or something related to the firewall setup on my machine. It's not critical, as you can still develop most g/g features locally without this. Would you like me to add some disclaimer? Maybe label this option as best-effort/experimental ?

[timebertt]

There is one issue that I didn't manage to solve: gardenlet fails to establish the VPN tunnel to the shoot. I'm not sure if it's a general limitation, or something related to the firewall setup on my machine. It's not critical, as you can still develop most g/g features locally without this. Would you like me to add some disclaimer? Maybe label this option as best-effort/experimental ?

What do you mean by that? The gardenlet doesn't establish a VPN tunnel to the shoots, only the kube-apiserver does (if the KonnectivityTunnel feature gate is disabled). Do you mean the step in the Shoot reconciliation where gardenlet tries to check, if the VPN/tunnel connection works?
I'm not sure, but I think this shouldn't be related to your firewall setup, as this is just a plain REST call to the /portforward subresource on the VPN pod with SPDY transport (I think).

[vpnachev]

/lgtm
/reviewed ok-to-test

[timebertt]

@guydaichs and I checked offline and the problem was not due to the WSL setup and rather misconfiguration in the Shoot's networking section.
So, not related this PR :)
/lgtm
/approve

[timebertt]

Can you run git commit --amend --reset-author to kick out Gardener CI/CD as commiter?

[guydc]

Thanks @tim-ebert. Indeed, the entire local dev env works after fixing my misconfiguration. I fixed the commit author as well.

[timebertt]

Thanks!
/lgtm

[vpnachev]

/lgtm