> I guess this cluster API project is maybe something Crossplane would use under the hood?
It’s more likely the other way around: Cluster API needs a so-called infrastructure provider that creates cloud resources to get a Kubernetes cluster running. The logic to join/create a Kubernetes cluster within the VMs created by that is managed by a separate provider, the bootstrap provider.
So, I guess it would be possible to externalise the creation of cloud resources to Crossplane and write a small shim infrastructure provider that just translates your cluster specification into Crossplane resources.
Crossplane has a different use case than Cluster API (create any cloud resources vs create a Kubernetes cluster), so Crossplane using Cluster API doesn’t make a lot of sense. Crossplane basically is „what if Terraform was a Kubernetes Operator“, so that somewhat sounds like what you’re interested in with the later parts of your post.
It’s more likely the other way around: Cluster API needs a so-called infrastructure provider that creates cloud resources to get a Kubernetes cluster running. The logic to join/create a Kubernetes cluster within the VMs created by that is managed by a separate provider, the bootstrap provider.
So, I guess it would be possible to externalise the creation of cloud resources to Crossplane and write a small shim infrastructure provider that just translates your cluster specification into Crossplane resources.
Crossplane has a different use case than Cluster API (create any cloud resources vs create a Kubernetes cluster), so Crossplane using Cluster API doesn’t make a lot of sense. Crossplane basically is „what if Terraform was a Kubernetes Operator“, so that somewhat sounds like what you’re interested in with the later parts of your post.