Open nacx opened 1 year ago
This is perfect, thank you @nacx - as we proceed we need to refactor the variables so we can customize each cluster when we define it, but probably next month or so resolution. I was thinking about the above further, and did align myself towards enabling external-dns
and allocating a zone per cluster... so eventually the elements like that can be completely done using gitops
... and minimize the tf
influence, but it is a time investment on itself, basically need help or time on getting external-dns
added for the clusters. wdyt?
I agree. I thought several times about adding external-dns, because it would also help expose people's declared IngressGateways. I already have an external-dns setup for GCP, but lacking AWS/Azure config expertise to add it in those so I parked that :) But happy to help there. I can probably get started with the GCP bits, put the structure, etc, and then let you or someone else parameterize the bits/values for Azure/AWS
I can take on expanding towards AWS/Azure - actually I do know how to do it on Azure but never done it for GCP.
JFTR, GKE example bits for external-dns: https://github.com/tetratelabs/zta-demo-2022/tree/master/k8s/gke
Once https://github.com/tetrateio/tetrate-service-bridge-sandbox/pull/247 this could be easily achieved by configuring this overlay in the CP: https://github.com/tetrateio/eshop-demo/blob/main/vm/02-control-plane-patch.yaml#L9-L25
Today we generate an empty mesh expansion configuration in the CPs. We could easily add some config bits to allow configuring which clusters should have mesh expansion enabled, and we could also generate a proper FQDN for the vmgateway (something like
vm<cluster_id>-<tsb_fqdn>
), configure it in the provider DNS, and generate the corresponding certificate, so that the cluster is ready to be used to onboard VMs.I have a WIP branch for this and plan to submit a PR soon.