Admiralty about cluster-api-provider-nested HOT 11 CLOSED

I think so.

from cluster-api-provider-nested.

Interesting, I'm not super familiar with this project. Seems like something we could eventually look into supporting, given that the nested clusters don't actually run schedulers it would end up being the management/super cluster that runs the scheduler and the CAPN cluster wouldn't have any idea about what is going on behind the scenes.

That being said, I'd love to learn more.

/cc @Fei-Guo who is also interested in what multi-supercluster could look like.

from cluster-api-provider-nested.

/kind design

from cluster-api-provider-nested.

It is similar to what I have been thinking about to some extend but our solution should be simpler ( to understand and to implement) since there is no VK sitting in between.

from cluster-api-provider-nested.

Yeah, maybe the cluster-api-provider-nested could deploy a virtual kubelet / admiralty per cluster it manages and hook it up to a control plane.

It may be a bit heavier weight then doing without VK, but the amount of shared code need to get it all to work, with all the schedulers and such may make up for it? So much less needed to implement?

from cluster-api-provider-nested.

/assign @Fei-Guo

from cluster-api-provider-nested.

I took a close look at Admiralty. The fundamental concept wise difference is that Admiralty uses a VK to hide underlying node topology. From the user's perspective, all Pods are scheduled in the same vk node. While in VC, there is one to one mapping between a tenant vNode and a super cluster physical node so entire K8s node semantics are preserved. Also, I don't see how Admiralty handles synchronizing other objects such as secrets/serviceaccount/configmap etc. In terms of scheduling, for vc, the scheduling is done in super cluster. The entire architecture is much simpler (no delegate Pod sit in between). Overall, in my opinion, as long as the Pod provider is a K8s cluster, there is no point of using virtual kubelet. VK only makes sense if the Pod provider is not a native K8s.

On the other hand, can CAPN be used in Admiralty use cases? Yes, it can since control plane management is an orthogonal issue which is not Admiralty's focus. In that regarding, deploying Admiralty in CAPN can be included as one of the CAPN use cases.

from cluster-api-provider-nested.

Would you two say we can close this issue for now, it sounds like CAPN wouldn't need to implement anything to support Admirality more that Admirality could potentially integrate through native k8s hooks with CAPN. Seem reasonable @Fei-Guo @kfox1111?

from cluster-api-provider-nested.

/remove-kind design

from cluster-api-provider-nested.

/close

from cluster-api-provider-nested.

@christopherhein: Closing this issue.

from cluster-api-provider-nested.