In this 3rd configuration profile, I will walk through the resulting configuration of AKS and its effect on the Load Balancer, Virtual Network, VM network interface card, deploy and test a web application into the Azure Kubernetes Service (AKS) cluster. The configuration profile is mainly around the Azure CNI network model and enabling the HTTP Application Routing Feature.
The HTTP application routing solution makes it easy to access applications that are deployed to your Azure Kubernetes Service (AKS) cluster. When the solution’s enabled, it configures an Ingress controller in your AKS cluster. As applications are deployed, the solution also creates publicly accessible DNS names for application endpoints.
Please read the Part 1 intro of this blog series if you haven’t already. This will explain the background and what each configuration setting means. Here is the previous blog post for Part 3 Azure CNI.
Configuration Profile 3
- Network Model/Type: Advanced (Azure CNI)
- Http application routing: Enabled
- Virtual Machine Scale Set: Disabled
Scale: 1 Node/VM
AKS Resource – Networking
Resources in the AKS Infrastructure Resource Group
Note the DNS zone created due to HTTP Application Routing.
Two Public IP Addresses. One of them for outbound traffic.
Load Balancing rules
Due to the Advanced Azure CNI plugin, the Network interface card for the Node/VM has setup the IP addresses for the pods.
I have deployed a sample app by following the documentation AKS Http Applicaiton Routing – Use Http Routing.
DNS Zone – A Record
An ‘A’ record is created based on the Ingress resource.
This is the URL to the application hosted in AKS via the HTTP Application Routing
Kubernetes Ingress resource as show from the Kubernetes Dashboard. Compare to the two previous scenarios, I did not have to deploy an ingress controller.
And Also, the following three deployments are created due the HTTP Application Routing configuration setting. By seeing the name of the deployment, AKS has setup an Nginx ingress controller.
Test the application with the DNS URL.
In summary, the HTTP Application Routing has the convenience of not needing to manually deploy an Ingress controller and having the out of the box capability to configure a DNS URL for easy setup of user friendly URLs.
Read the next blog post in this series for Part 5 on my concluding analysis and recommendations.
Complete Blog Post Series
- Comparing Azure Kubernetes Networking Scenarios – Part 1 Intro
- Comparing Azure Kubernetes Networking Scenarios – Part 2 Kubenet
- Comparing Azure Kubernetes Networking Scenarios – Part 3 Azure CNI
- Comparing Azure Kubernetes Networking Scenarios – Part 4 Http App Routing
- Comparing Azure Kubernetes Networking Scenarios – Part 5 Concluding Analysis
3 thoughts on “Comparing Azure Kubernetes Networking Scenarios – Part 4 Http App Routing”
Pingback: Comparing Azure Kubernetes Networking Scenarios – Part 1 Intro – Roy Kim on Azure, Office 365 and SharePoint
Pingback: Comparing Azure Kubernetes Networking Scenarios – Part 5 Concluding Analysis – Roy Kim on Azure, Office 365 and SharePoint
Pingback: Build5Nines Weekly: January 20, 2020 | Build5Nines