As its definition says – “Azure Front Door is a global, scalable, and secure entry point for fast delivery of your web applications. It offers dynamic site acceleration, SSL offloading, domain and certificate management, application firewall, and URL-based routing”. We can consider this as an Application Gateway at global scale with CDN profile thrown in to spice it up. AGIC or Application Gateway as Ingress Controller is already available and widely used. I received this question recently, asking whether Azure Front Door can be used in the same way. I didn’t have to reinvent the wheel as so many blog posts and YouTube videos are already there on this topic. In this article, I will only discuss different options to implement Azure Front Door with AKS and will add some critical tips you should be aware of. In general, using Azure Front Door with Azure Kubernetes Service has following benefits:
- Improve the performance and availability of your web applications by routing the traffic to the closest and healthiest AKS cluster, in case you have multiple such deployments of AKS clusters.
- Protect your web applications from malicious attacks by using Azure Front Door's application firewall and SSL encryption.
- Reduce the complexity and cost of managing multiple domains and certificates by using Azure Front Door's domain and certificate management.
Prerequisites
To follow this guide, you will need the following:
- An Azure subscription. If you don't have one, you can create a free account.
- An Azure Front Door resource (Premium).
- An AKS cluster.
- A web application deployed to your AKS cluster as a deployment or an independent pod. You can use any web application that supports HTTP or HTTPS protocols. To make your life easier, use a simple HTTP based web app.
- Private Link and Private Endpoint – you will create it while going forward.
Option1: Using Internal Load Balancer
In this option you will create an internal load balancer within your AKS cluster (under the same namespace) to expose your web app running within the deployment or pod created earlier. This means the load balancer will have an internal IP instead of an external or internet facing IP. This as you may already know, can be done using annotations. Beyond this you will add few more annotations to add a private link to this internal IP of the load balancer. Next, you will connect your Azure Front Door using a private end point to this private link. A detailed blog post can be found here: Connect Azure Front Door Premium to an AKS App origin with Private Link | by James Dumont le Douarec.... Here is a YouTube video that describes the whole process: Publish Your AKS Services with Azure Private Link and Front Door (youtube.com).
Tips:
- You don’t need to use all the annotations shown in the video or the blog post. Some of them has default values and will be picked up automatically. For example, Subnet Name, it will be the same subnet of the AKS cluster if not mentioned separately. IP address count id default “1”, hence, you don’t have to mention it exclusively if you want one only. In my case I used something like:
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
service.beta.kubernetes.io/azure-pls-create: "true"
service.beta.kubernetes.io/azure-pls-name: "<name of your pls>"
service.beta.kubernetes.io/azure-pls-visibility: "<your subscription ID>"
- From your Front Door Menu, under Front Door Manager>default-route>Forwarding protocol, select “HTTP only”.
- Also, under Front Door Manager>default-origin-group>Probe method, select “Get”.
Option 2: Using Ingress with Internal IP
The previous option of using internal load balancer, although easy to implement, but has a few limitations:
- If you have multiple such web applications, you end up using multiple load balancers. This in turn, uses available IPs from the Virtual Network. This issue is more evident when you are using Azure CNI and all your pods are assigned with new IPs from the IP space of your virtual network.
- Although Azure Front Door has so many features, but it is not same as an ingress controller. Both have their different purposes. So, if you are looking for flexibilities you get from standard Ingress Controller such as NGINX or Trafeik, then the previous option may not be suitable. One such example is path-based routing. Standard, in-cluster ingress gives you more preferences.
Using an ingress will help you to overcome both the issues mentioned above. In this case also we will use a private IP, private link, and private endpoint. Unlike to previous option you do not add annotations to the Ingress declaration (YAML). There is a Techcommunity post with detailed info along with Bicep code, YML etc. to create the whole environment: How to expose NGINX Ingress Controller via Azure Front Door and Azure Private Link Service - Microso....
But before using artifacts from the post mentioned above, I’ll ask you to try it yourself once using a bit simpler method. You already have an AKS cluster and Azure Front End ready. Use following tips to reuse it to check how to use Ingress.
Tips:
- I have used NGINX Ingress controller, first I used values file to add annotations while installing the Helm charts for NGINX. Detail about values file is available here: ingress-nginx/charts/ingress-nginx/values.yaml at main · kubernetes/ingress-nginx (github.com). Content of my values.yaml file looks like:
controller:
service:
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
service.beta.kubernetes.io/azure-pls-create: "true"
service.beta.kubernetes.io/azure-pls-name: "<your pls name>"
service.beta.kubernetes.io/azure-pls-visibility: "<your subscription ID>"
- Now install NGINX Ingress using Helm chart. Make sure you refer the values file:
helm install nginx-ingress ingress-nginx/ingress-nginx -f values.yaml \
--set controller.replicaCount=2 \
--set controller.nodeSelector."kubernetes\.io/os"=linux \
--set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
--set controller.admissionWebhooks.patch.nodeSelector."kubernetes\.io/os"=linux
- 3. You can now create a ClusterIP type service for your deployment/pod and an Ingress to connect to that ClusterIP service. You will see, the Ingress will have an internal IP assigned and a private link is also created. The rest is same as the option 1.
Conclusion
In this blog post, I have shown you how to use Azure Front Door with Azure Kubernetes Service to improve the performance and security of your web applications. You have learned how to:
- Configure Azure Front Door to route the traffic using a load balancer.
- Configure Azure Front Door to route the traffic using an ingress.
- You can use an AGIC with your AKS and connect it to Azure Front Door as well, but this is beyond the discussion point of this article.
I hope you have found this guide useful and informative. If you have any questions or feedback, please feel free to leave a comment below.
