High Level CAPN Goals about cluster-api-provider-nested HOT 12 CLOSED

Thanks @kfox1111, yeah. I was taking a look at that recently as it was shared on the SCL mailing list. Looks like a neat implementation. I like that it's orchestrated with kubeadm at parts even though the templating is done upfront.

We currently have a similar approach which is backed by a controller that we're in essence reimplementing the API in this project. https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/virtualcluster

Probably useful to share things between these two projects.

from cluster-api-provider-nested.

@salaxander @Fei-Guo @weiling61 @charleszheng44

from cluster-api-provider-nested.

Please add more Goals/Non-Goals for CAPN

from cluster-api-provider-nested.

Though manging Etcd is not our goal, to increase the development velocity, can we implement a basic NestedEtcd controller that creates in-mem Etcds for NestedControlPlanes? In the future, we can make CAPN compatible to some third-party Etcd-operators.

from cluster-api-provider-nested.

Some high level goals I'd like to include:

• To reinforce responsibility boundaries between cluster provider and cluster consumer / Service plane vs data plane.
• To shift content out of consumer-visible (kubeconfig) cluster data plane to service control plane. Externalizes etcd, kube-{apiserver|controller}, scheduler, auth, identity to management cluster.
• To reduce cost per cluster by deploying control planes as pods to the management cluster rather than target traditional virtual/physical/infrastructure hosts.
• To enable heterogeneous architectures for data plane compute nodes. E.g Virtual nodes (as in https://github.com/kubernetes-sigs/multi-tenancy/tree/master/incubator/virtualcluster) vs virtual/physical/infrastructure hosts.

cc @ironcladlou @csrwng

from cluster-api-provider-nested.

Though manging Etcd is not our goal, to increase the development velocity, can we implement a basic NestedEtcd controller that creates in-mem Etcds for NestedControlPlanes? In the future, we can make CAPN compatible to some third-party Etcd-operators.

Yes, agree @charleszheng44.

from cluster-api-provider-nested.

@enxebre these are great and I agree should be added.

One thing, with "reduce cost per cluster"? I'm concerned that might be all dependent on where the control planes are provided. At least w.r.t physical "$". Am I misinterpreting what you mean?

from cluster-api-provider-nested.

/kind design

from cluster-api-provider-nested.

I wonder if this helm chart might help with an initial bootstrapping implementation:
https://github.com/kvaps/kubernetes-in-kubernetes/tree/master/deploy/helm/kubernetes

It is pretty easy to map crd values to a helm chart values file and deploy that way. This can allow iterating with the api to get it right much more quickly then trying to write it from scratch in something like go. Once the api is nailed down, then it can potentially be replaced by a go operator that does the templating itself?

from cluster-api-provider-nested.

/milestone v0.1.0

from cluster-api-provider-nested.

/close

from cluster-api-provider-nested.

@christopherhein: Closing this issue.

from cluster-api-provider-nested.