Kubernetes ingress concepts can be confusing and hopefully this helps make things a little more clear with an emphasis of some things specific to Azure. In this technical post – I walk through deploying an NGINX controller which exposes a public IP address with a DNS label on top of a Kubernetes cluster provisioned to Azure.
Likely very soon after provisioning some workload on top of K8s you will want to have public access to that application or service. Kubernetes services allow you to “expose” them which when paired with a cloud provider that means it will provision some form of loadbalancer and public IP address (assuming your cloud provider has the code hooks provisioned). For very simple “hello world” / development and testing this can work fine to expose the service(s) directly.
If you need an API gateway, want fine-grained control over the traffic and DNS names, add additional protection via a web application firewall (i.e. see ModSecurity), or simply don’t want to expose / pay-for / manage multiple public IP addresses for each service, then an Ingress controller and resource is the way to go. This article does a good job going deeper into ingress.
Important Azure Specific Ingress Note:
Some cloud providers will automatically provision or contain an ingress controller once you provision an ingress resource. Any type of kubernetes cluster running on Azure (acs-engine, ACS, AKS) at the time of this post does not do this, so you must manually deploy an ingress controller so the ingress rules deployed will function.