external-dns VS crossplane

The second one is a combination of tools: External DNS, cert-manager, and NGINX ingress. Using these as a stack, you can quickly deploy an application, making it available through a DNS with a TLS without much effort via simple annotations. When I first discovered External DNS, I was amazed at its quality.

One of the reasons why I chose Hetzner was that it WAS supported by the ExternalDNS project. I didn't quite understand why the Hetzner provider was pulled, but I saw that an attempt of re-adding it was refused, on the ground that the upcoming webhook architecture would have allowed to better maintain providers.

Write a custom controller for the external DNS controller, or setup some form of ArgoCD app / appset templating.

so I am looking at having an automated way for new routers registered in Traefik to also have the corresponding DNS entry added to my Pihole instance similar to external-dns but obviously, this is exclusive to ingress on k8s environments. my current setup is traefik in a container on unraid.

You technically don’t need to run a load balancer or have a virtual IP for your control plane. If you control your dns, you can add an A record pointing to all IPs for your control plane nodes. It won’t load balance your traffic, but combined with something like External DNS it gives you HA for the control plane.

I normally deploy external-dns, which automatically updates DNS with the ingress controller's external IP address.

Background: Having a look I can see this https://github.com/kubernetes-sigs/external-dns

3) Use the Kubernetes External-DNS. I've never used this, but this is assuming it can update DNS for each pods/app to point to the correct Node (it'd need to update my Homelab DNS running on Windows Server)

So here’s the solution I have taken for our current stack. EKS and its dependencies are created through terraform using the eks module as well as provision a route53 subdomain and a wildcard cert. Once we have that created, I have installed this deployment into the cluster via the helm module: https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.4/. This allows me to use kuberentes resources (load balancers or ingress objects) and it will handle all the provisioning of load balancers and security groups for me, based on my application yaml and annotations. We also use https://github.com/kubernetes-sigs/external-dns to manage all of our specific host names for the applications through annotations. So to generally put, terraform manages out Kubernetes clusters, and Kubernetes manages the deployment of anything needed for the application including volumes, load balancers, hostnames though Kubernetes system deployments

Metallb for your load balancer (layer2 mode will do) NginX-ingress, will be spot on for internal home apps External-dns to publish your dns record to your Dns server at home, https://github.com/kubernetes-sigs/external-dns

did anyone adopt in production https://crossplane.io ?

- https://github.com/crossplane/crossplane/blob/master/design/one-pager-composition-environment.md

In the overall scheme of things , look at services like backstage.io , crossplane.io and opslevel.com to get ideas. This is not necessarily an endorsement of the services. If all you want is to handle cloud resources and that's it, Terraform can be enough with what ever flavor of web technologies you and your team are comfortable with and can support it along the way. Doesn't take much to create a js based website to collect data from a form, or use other means to collecting data as long as its recorded and transparent for accountability.

XRs are written in a fully declarative manner. And when I am building my XR from underlying managed resources provided by some crossplane provider I need to parametrize resources, use conditionals and create arrays of resuorces The issues of declarativeness in the world of automation are well known- we typically resort to some form of templating and we invent some imperative expressions into that templating language/format. This is currently not very well supported with Crossplane however Crossplane team realizes this issue and they are conteptualizing solution here

I have an idea for a project that would interface with Crossplane. The project has some code that would save tons of time if I could use it directly in my project, but it is located in the internal directory. I can't import the modules directly, but the project is open sourced under an Apache 2.0 license, so the code itself is available for use under that license.

There are always new projects like crossplane that sit on top on architecture systems like terraform, vagrant. The pressure to abstract away any sort of resources is mounting, companies can save a lot by for example by alt hosting S3 endpoints. The train is going the direction not to tie anything to a specific platform implementation if its not a must. Most of the companies I work with use AWS as a hosting provider, but Microsoft for github and related CI matters. As I learned, AWS quality is very dependent on location, eu-central-1 is dead stable for our use cases serving about millions requests a day.

Practically, you'll be replacing stock k8s resources (deployments) with custom ones like Argo Rollouts with Keda autoscaling, so you have to plan the respective Gitops CD pipeline (fluxcd/argocd with some crossplane), as well.