ingress-nginx VS application-gateway-kubernetes-ingress

ingress-nginx

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.

resource "helm_release" "icrelease" { name = "nginx-ingress" repository = "https://kubernetes.github.io/ingress-nginx" chart = "ingress-nginx" version = "4.9.1" namespace = kubernetes_namespace.icnamespace.metadata[0].name set { name = "controller.ingressClassResource.default" value = "true" } }

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx --create-namespace -f custom/ghost/nginx.yaml

For example, if you chose Nginx Ingress, you will use some of its dozens of annotations that are not portable if you decide to switch to another Ingress implementation like Apache APISIX.

The controller is installed with helm upgrade --install ingress-nginx ingress-nginx --repo https://kubernetes.github.io/ingress-nginx --namespace ingress-nginx --create-namespace

helm repo add jetstack https://charts.jetstack.io helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo add rancher-latest https://releases.rancher.com/server-charts/latest helm repo update helm repo list

Everything in the YAML snippets below — except for ingress configuration — relates to configuring the NGINX ingress controller. This includes customizing the default configuration.

Keep Documentation Handy: Always have the official NGINX Ingress documentation accessible.

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).