Gardener: Local dev setup without k8s cluster

[timebertt]

What would you like to be added:
It would be nice to have an option for local development without the need for a local k8s cluster (like docker-for-desktop or kind).
@rfranzke @zanetworker proposed to use standalonekube-apiserver and etcd containers for that.

Why is this needed:
This would make the local setup more lightweight and easier wrt to choice of k8s versions and being independent of docker-for-desktop updates (which might break your local gardener setup).

[timebertt]

/assign

[vpnachev]

What container runtime will run the kubernetes and etcd containers on MacOS/Windows?
What would be the advantage over kind when MacOS/Windows is used?

If the etcd/kubernetes are running as native binaries(not containers), that will be best, but I'm puzzled that containers has to be used.

[zanetworker]

@vpnachev Docker is the go-to runtime here unless you have other perferences, then we can discuss them.

What would be the advantage over kind when MacOS/Windows is used?

The advantage over using kind is that you don't need to have a full cluster, no dependencies on kubeadm or delays waiting for a new version support (when 1.18 is available, it is also available in your local setup), you also have other customization options like special alpha features which might be problematic to run over a kind setup (e.g., ephemeral containers).

If the etcd/kubernetes are running as native binaries(not containers), that will be best, but I'm puzzled that containers has to be used.

Sure you can do that, but you will have to deal with port management on your local host, with containers though you can portmap and thus have an option to avoid port conflicts and not having to be creative about choosing the right numbers. Furthermore, you just need the image and off you go, no need run of kubernetes source-code to run a build of the apiserver / controllermanager /etcd and no need to upgrade the version of the binaries. Basically, utilize the benefits of containers :)

[vpnachev]

Nice. I was thinking that kind is sufficient for local development, but I have to be honest that I mainly use minikube, so I am not aware of its disadvantages.

So the idea is to implement something similar to kind, but with the full freedom to configure easily everything of the master components, am I right?

[timebertt]

Yes, the proposed approach would give you a nodeless local cluster with much less dependencies than a fully-fledged kind/minikube/docker-for-desktop cluster, greater configuration flexibility and would also be much more lightweight.
The basic idea behind it is very similar to the concept of having a nodeless cluster as the garden cluster (virtual garden) with the main difference being that you would be running the needed control plane componenents directly (in containers, if you want) on your development machine instead of on a k8s cluster of some kind.