undefined

points

[-]

In virtual mode, the only pods running directly on the host are the K3s servers and agents. All "virtual cluster pods" run within these components, meaning they do not appear as individual pods on the host cluster.

The only trade-off is that K3s currently requires privileged mode to operate. We are actively exploring ways to address this limitation and improve security, such as implementing user namespaces or microVMs.

by weitzj5 hours ago|

parent|

[-]

Thank you for your feedback.

I understood from the host cluster perspective you won’t see the child cluster pods. And what is the perspective on nodes?

Can you have like a host cluster spawning on host nodes and the host cluster has control over spawning separate physical nodes which contain the child cluster (api server) + workload pods ?

by enrichman5 hours ago|

parent|

[-]

As I understand it, the virtual cluster pods are treated as standard workloads by the host. This means if you scale the nodes up or down, they will be rescheduled accordingly. You can currently use node selectors to manage this behavior, though we are developing a more flexible approach using affinity rules.

by weitzj3 hours ago|

parent|

[-]

Thank you

by ithkuil6 hours ago|

prev|

[-]

Aren't OCI caches content addressed?

by weitzj5 hours ago|

parent|

[-]

I was thinking of people were to use an image…:$my_tag on the host cluster and some roughe pod on the child cluster (but same underlying physical nodes) somehow overwriting the local cached :my_tag, you could do something on the parent cluster.

But I don’t fully understand what you meant with content adressed :)

Maybe one has to ensure in the host cluster that the image pull policy is set to Always or all references to images have to be based on the shasum rather than Tags.