application-gateway-kubernetes-ingress VS external-dns

Unfortunately in some cases it works poorly. For more insights, read this - https://github.com/Azure/application-gateway-kubernetes-ingress/issues/1124

My main concern is about zero-downtime deployments - https://github.com/Azure/application-gateway-kubernetes-ingress/blob/master/docs/how-tos/minimize-downtime-during-deployments.md

However, you better read and understand some specific behaviors of AGIC which are caused by its architecture - https://github.com/Azure/application-gateway-kubernetes-ingress/blob/master/docs/how-tos/minimize-downtime-during-deployments.md & https://github.com/Azure/application-gateway-kubernetes-ingress/issues/1124

application-gateway-kubernetes-ingress (Azure only)

Probably something like this https://azure.github.io/application-gateway-kubernetes-ingress/

AKS Application Gateway Ingress Controller is an ingress controller that configures the Azure Application Gateway.

AGIC has a lack of annotations that I find nginx+ offers like server snippets and custom headers. granted you can write re-write rules for AGIC with the help of the portal, it resets everything if one pod fails and this is a major showstopper for me. More info about the exact issue I'm talking about is in this issue. Apart from this, like the previous comments, the extra WAF rules and compliances offered makes AGIC a good choice if you don't have any extra header addition requirements like i do.

If you want Azure to manage ingress, you can use Azure application gateway and application gateway ingress controller (agic). However, if you want a public/private combination, fox example if you have 8 microservices out of which you want 6 to have private endpoint and 2 to have public endpoint over https, then it cannot be dones as agic only supports one ip per port. Also one agic can only use one application gateway (With auto management, meaning it automatically manages the listeners, https settings, backendpools, probes etc. on app gateway). If you it as shared gateway, then you need to manage application gateway manually (with az cli). Also, its github page has good how tos (https://github.com/Azure/application-gateway-kubernetes-ingress).

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