Cluster-api: RFE: Pod based control plane provider
Folks have been asking here and there for a pod-based control plane. With v1alpha3, we introduced support for control plane providers, which users can use to specify which provider they'd like to use to manage their control plane.
/kind feature
/kind design
/milestone Next
vincepri
All 12 comments
/cc @christopherhein
vincepri
on 30 Jul 2020
/cc @hardikdr
detiber
on 30 Jul 2020
Gardener deploys pod-based control-planes and also follows the core principles of cluster-api. I am generally interested in developing the control-plane provider for it, but haven't been able to spend enough time yet, would be more than happy to collaborate if there is an added interest.
- A very minimal start: https://github.com/hardikdr/gardener-controlplane-provider
- Essentially it'd be about mapping the cluster-object with the shoot-object, and MachinePoolAPI to gardener's MachineAPI, similar to the AKS integration with CAPI.
- I am sure, there would be more open design-aspects surfacing during development though.
hardikdr
on 4 Aug 2020
/cc @munnerz
/cc @salaxander
christopherhein
on 4 Aug 2020
@hardikdr do you plan on using something that would define the control plane template? Or are you thinking that each release of the controlplane provider would map to a specific k8s version that gets created?
christopherhein
on 4 Aug 2020
/cc @Fei-Guo
christopherhein
on 6 Aug 2020
do you plan on using something that would define the control plane template?
Yes, basically I'd hope to introduce a GardenerManagedContolPlane CRD with a field of Spec.Version to allow users to configure the k8s version of choice. The CRD would then simply map to the cluster-resource of the gardener-orchestrator at runtime, and the rest of the responsibility of spawning the cluster should then be taken care of by gardener.
- In a similar way, the MachinePoolAPI of cluster-api can be mapped to the gardener's MachineAPI.
hardikdr
on 6 Aug 2020
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale
fejta-bot
on 4 Nov 2020
/lifecycle frozen
vincepri
on 4 Nov 2020
Is this essentially CAPN now, and do we need this?
randomvariable
on 19 Jan 2021
/close
This RFE is in a different repository as @randomvariable mentioned, https://github.com/kubernetes-sigs/cluster-api-provider-nested
vincepri
on 19 Jan 2021
@vincepri: Closing this issue.
In response to this:
/close
This RFE is in a different repository as @randomvariable mentioned, https://github.com/kubernetes-sigs/cluster-api-provider-nested
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
k8s-ci-robot
on 19 Jan 2021
Related issues
alexeldeib
路
4Comments
fabriziopandini
路
3Comments
mboersma
路
5Comments
ncdc
路
5Comments
jsturtevant
路
5Comments
Most helpful comment
Gardener deploys pod-based control-planes and also follows the core principles of cluster-api. I am generally interested in developing the control-plane provider for it, but haven't been able to spend enough time yet, would be more than happy to collaborate if there is an added interest.