In addition to clusterctl as binary provide an Operator that handles the same lifecycle-Operations like Clusterctl, just based on CRDs. This proposal also expands upon the basic template tunction of Clusterctl towards a more powerful templating engine.
In its current form clusterctl isnt optimized for day2 operations on big n-Infra or n-Core installations and upgrades are not hazzle-free. Having Clusterctl as an Operator that automatically handels upgrades based upon CRDs would make Day2-Operations easier and allow for reducing administrative Overhead.
Also the templating feature in clusterctl is very basic and doesnt really cover more than the first few steps with CAPI. Having Clusterctl as an Operator that supports Templating based on Ansible-like "Inventory" Structures would make it possible to significantly improove the User experience with more complex deployments and would also make Day2-Operations easier.
- enable Lifecycle of CAPI-Components via CRDs
- allow Users to define their single Infra, n-Infra or n-Core Environments with CRDs and have Clusterstl-Operator roll out an management-cluster
- allow integration with secret Managemnt tools like Hashicorp Vault for protecting Secrets needed for the Infrastructure Providers and CAPI
- allow Users to roll out Clusters by defining common parts within thetemplating "Inventory" and only defining an minimal ammount of config per Cluster, all other details are inherited.
- Handle Upgrades of Clusters due to changes within the templating "Inventory"
- Implement any features that reside with existing CAPI components (like actual upgrade handeling)
- Do any state-tracking for upgrades (e.g. more advanced Upgrades than CAPI currently spoorts out-of-the-box)
The Clusterctl-Operator is reponsible for reconciling the state in the CRDs with the installed CAPI components and the versions thereof. The Operator can optionally also interact with Hashicorp Vault to get the credentials for the Infra-Providers or CAPI in general from there.
Templating is relized within Go, altough our PoC currently uses Jinja and Python to check the feasibility of how we want to inherit variables. It should utilize variable input templates to decouple the Cluster-API CRDs from its input and allow it to include small changes in the CAPI-CRDs without changes, just by updating the assotiated template.
Our PoC currently utilizes this abstraction Classes, which would be CRDs:
- Environments
- Customers
- Sites
- Infra-Providers
- Clusters Sites and Infra-Providers can most likely be collapsed into one.
Priority would be in this Order (lower overwrites upper), but could ideally be configured by another CRD
- Environment
- Customer
- Site
- Infra-Provider
- Cluster
- Infra-Provider
- Site
- Customer