Tim Ebert

Thanks for coming back to this PR @listx @stevekuznetsov. @oliver-goetz is currently on leave as well and will be back on Monday :)

Hi @kwitsch, can you provide some examples to elaborate on what you mean (e.g. `user-data`, resulting `sources.list` file and so on)? Also, have you checked https://cloudinit.readthedocs.io/en/latest/topics/modules.html#apt-configure? `cloud-config` has settings for...

> The currently used sources.list is a debian one which doesn't work on raspbian. I'm not sure, I can follow you. Have you tried switching to `https://download.docker.com/linux/debian`? raspiOS is pretty...

Ah, good to know, that this behaves differently on armhf. Let me test this on my Pis and see if we can/should change the default mirror for the `armhf` images.

No. Haven't tried it out so far. Feel free to contribute, once you got something working :)

Thanks for summarizing, @vlerenc! Here are some additional thoughts from my side. They don't have to be discussed here, just wanted to put them on the record somewhere for future...

> But I get your point. How about: > `kubectl shoot --control-plane` Yes, something like this would work for me. And is probably even cleaner semantically... > There are two...

Well, I can imagine different flows for this: - `k clone` to clone the current kubeconfig - `k shoot|seed|... --clone` to target a new cluster but get a cloned/"isolated" kubeconfig...

> Let's say, your current `kubeconfig` is one in a local folder backing a `git` repo or whatever. Where would you physically clone the `kubeconfig` to? That would only work...

I was just talking about that we will anyways need some local directory structure for caching the topology detection results and also to store the kubeconfigs with the encrypted credentials...