I use Cluster API and FluxCD
https://cluster-api.sigs.k8s.io
https://github.com/siderolabs/cluster-api-bootstrap-provider-talos
https://github.com/siderolabs/cluster-api-control-plane-provider-talos

https://fluxcd.io

@rachel

@praxiscode @rachel Is it possible to adopt a cluster into cluster-api post install? That's what I can't seem to figure out.

(Background, I would love to see my cluster being managing itself through cluster API similar to how OpenShift does it.)

Adopting an existing cluster post-deploy into Cluster API is an exercise in tedium.

You have to manually create *all* of the CAPI objects, while keeping them paused (.spec.paused: true), including all of the interconnecting bits (owners, including their UIDs, etc). You have to create all of the associated secrets, machine objects, (provider)machine objects, (provider)machinetemplate, etc etc etc.

So, technically doable, but not fun at all.

(1/N)

@sheogorath @rachel

Last year I accidentally destroyed my CAPI cluster, and had to rebuild and adopt in my current clusters. The approach that worked was to extract the necessary secrets from the existing cluster and create those objects, then I provisioned a new control plane. I had to set the IPAM address range not to re-use the existing node IPs. I also set the TalosControlPlane object's status to indicate that it had already been initialized, so it wouldn't create a new etcd.

(2/N)

@sheogorath @rachel

The first control plane node joined the existing control plane cluster, then took it over. The subsequent control plane nodes joined right in. Since the secrets had been populated from the existing cluster, the worker nodes just carried right along. I decommed the old CP nodes, then spun up all-new workers with CAPI, and drained/shut down the old workers, migrating all the services to the new nodes.

Much less tedious that way.

(3/3)

@sheogorath @rachel