Store manifest used to reconcile a cluster on the target cluster

[xmudrii]

To ensure it's possible to easier handle cluster upgrades, recover from potential disasters, or modify the cluster once it's reconciled, we should store the original manifest used to reconcile a cluster on the target cluster.

That way we know how exactly we provisioned the cluster and can use the manifest to create the same cluster or modify and upgrade that one while keeping track of the original cluster.

It is up to be decided how exactly we want to store manifests and what information will we store. There are two options for storing manifests:

1. Store manifest as a ConfigMap or Secret — the easiest to implement, but may be tricky to parse and store additional information
2. Move from manifests to Kubernetes objects — instead of having pure-YAML manifest like we do right now, we could use a Kubernetes object based on CRDs. It's harder to implement, but much easier to manage. We get Status subresources, so we can more easily store additional information about the target cluster and we get some nice features such as versioning.
   • We could use cluster.k8s.io/v1alpha1 resource to be more compatible with Cluster API or create our own resource

It is also up to be decided do we want to store additional information about the target cluster (i.e. cluster status) and what exactly we want to keep track of. That could include information about what nodes we created and what version nodes are running.