Configuration management with Cluster API
| Created | State | Summary |
|---|---|---|
| 2021-11-10 | obsolete | Config maps to represent YAML templates in CAPI cluster releases. Share a Git repo for configuration with the customer. Later add cluster definitions to GitOps as well. |
This RFC describes how we can handle configuration management with Cluster API - focusing on defaulting, upgrades and interactions.
Context
During our transition to cluster-api we have decided to no longer directly couple operator versions to cluster versions.
The version of a cluster should completely be determined by the configuration of the cluster.
An example to show this changed approach is the following:
- Cluster
deu01has configurationXand is reconciled bycapi-controllerin version1.1.0. capi-controlleris updated to version1.2.0. Clusterdeu01remains completely unchanged.- A new cluster
peu01with configurationXis exactly the same asdeu01. - The configuration of
deu01is changed toYwhich causes the cluster to upgrade. The lifecycle of the cluster is therefore fully determined by its configuration and no longer determined by the operator reconciling it.
A new concept for Giant Swarm: releases are completely decoupled from the operators and only consist of cluster configuration!
Content
This RFC contains three parts which are in decreasing level of maturity:
- Releases as gitops managed configmaps
- Sharing responsibility and customization with customers
- Re-using release structures for gitops cluster management
We plan to use this RFC to have an open discussion on these topics before writing a more technical spec. Please voice concerns as well as alternative ideas here.