Web Application Routing on AKS
Exposing your web applications on Azure Kubernetes Service (AKS) has gotten a little bit easier. In this post, I will cover the new Web Application Routing feature for AKS and discuss reasons why you may want to implement it within your cluster.
Exposing your app
You have a lot of options when it comes to exposing your application Pods to the world. If you’re using a managed-Kubernetes service in the cloud, you could deploy a Service and set the type to LoadBalancer and your cloud provider will provision one with a public IP. The Service sits in front of your Pods and if all you need is a public IP, you’re good to go.
Most use cases aren’t that simple. You may need to expose HTTP(S) traffic and do some more advanced things like SSL/TLS termination or direct traffic to specific pods based on routing rules. For this, an Ingress is a commonly used. The Ingress sits in front of your Service and requires an Ingress Controller to satisfy requests.
Ingress options on AKS
With AKS, you have a few options for Ingress:
- Deploy your own open-source ingress controller. Most opt for Kubernetes Ingress which is built on open-source NGINX, but installation and support will come from you and/or the community.
- Deploy the AKS HTTP application routing add-on which is essentially a managed version of Kubernetes Ingress mentioned above. This will save you the work of installing the resource in your cluster; however, this is not intended for production scenarios.
- Deploy the Azure Application Gateway Ingress Controller (AGIC) which leverages the Azure Application Gateway service. The Application Gateway service will be supported by Azure; however, installation and maintenance of the ingress controller will be your responsibility.
- Deploy the AKS AGIC add-on in which case the ingress controller will be managed and supported by Azure.
So there are two “bring-your-own” (BYO) ingress options and two AKS-managed options. Here “managed” sounds appealing, but when it comes to “managed” options, AGIC sounds like the only choice. And for those that are coming from OSS ingress, the differences between AGIC annotations and NGINX annotations might be a deal-breaker.
Now what? Well… there’s one more “managed” option and it just might check all the right boxes 😊
Web Application Routing Add-On
The Web Application Routing add-on for AKS was announced at Microsoft Build 2022. At the time of this writing the add-on is still in Public Preview; which means you should explore it but it’s not intended for production workloads just yet… unless you like living on the edge 😅 But here are four reasons why you should consider it once it becomes Generally Available.
Managed NGINX ingress controller
First, the add-on will provide you with a highly-available, managed Kubernetes Ingress based on open-source NGINX. This is similar to the HTTP application routing add-on but is intended for production use and will be fully supported by Azure.
Manages DNS records
Second, the add-on provides an optional integration with Azure DNS and uses an external-dns controller to manage DNS records on your behalf. The older “HTTP application routing add-on” also provided this functionality; however, the difference here is that the new add-on can link to your custom Azure DNS resource.
As an example, let’s say you have a custom domain called myawesomesite.com and delegated it to your Azure DNS resource’s nameservers. When you deploy an Ingress with a host name of store.myawesomesite.com, an A record will automatically be added to your Azure DNS resource to point the store subdomain to the Ingress’ public IP.
Manages TLS certificates
Third, the add-on provides another optional integration with Azure Key Vault using the azure-keyvault-secrets-provider AKS add-on. When combined with the Web Application Routing add-on, the ingress controller will be able to load TLS certificates from Azure Key Vault and save it as a Kubernetes TLS secret with secret rotation.
As an example, if you have a TLS certificate for store.myawesomesite.com, simply upload the .pfx file to Azure Key Vault and bind the certificate to the Ingress using the kubernetes.azure.com/tls-cert-keyvault-uri annotation.
Integrates with Open Service Mesh (OSM)
Finally, if you have security requirements such as needing end-to-end encryption between your Ingress and your backend pods, there is out-of-the-box support for Open Service Mesh (OSM). OSM is an open-source light-weight service mesh to help secure intra-cluster communications.
In most cases, TLS termination is done at the ingress, and traffic flows un-encrypted to the backend pods. With OSM, you can configure it to proxy connections between Ingress and IngressBackends using mutual TLS (mTLS). This ensures traffic is encrypted all the way down.
OSM can be manually installed and configured for NGINX. However, if you combine the OSM add-on with the Web Application Routing add-on, configuration for NGINX is automatically added for you 🥳
Summary
The Web Application Routing add-on for AKS can be thought of as an evolution to the original HTTP application routing add-on with a additional capabilities that make it “production-ready”. The goal of this add-on is to make it easier for you to expose your application to the world in a secure manner while reducing some of the operational overhead that goes into that.
Get hands-on
If you’d like to dive deeper into this feature, check out the resources listed below. In addition to the docs, you can head over to the Web Application Routing with Azure Kubernetes Service lab in the OSS Labs Repo and take it for a spin.
As always, let me know what you think in the comments below or via Twitter @pauldotyu. I’d love to hear your feedback on this.
Til next time, cheers!