DIY Ingress on Azure: Roll Your Own Unmanaged Controller

Table of Contents

DIY Ingress on Azure: Your Guide to an Unmanaged Controller¶

Hey folks! Ever wrestled with getting traffic flowing smoothly to your Kubernetes services on Azure? An Ingress controller is your ticket to easy reverse proxying, traffic routing, and TLS termination. Think of it as a smart traffic cop for your cluster. This guide walks you through setting up an NGINX ingress controller on your Azure Kubernetes Service (AKS) cluster, so you can access multiple services through a single IP. Ready to roll? Let’s dive in!

image just illustration

Prep Work: Before You Start¶

Before we get our hands dirty, make sure you’ve got the following sorted:

• Helm 3: We’ll be using Helm 3 for this setup, so ensure you have the latest version and access to the ingress-nginx Helm repository. Older versions might not play nicely.
• AKS Cluster with ACR: You’ll need an existing AKS cluster with an integrated Azure Container Registry (ACR). If you don’t have one, check out the Azure docs on creating one.
• Kubernetes API Endpoints: The healthz endpoint is old news. Use livez and readyz instead, depending on your needs.
• Azure CLI (if using): Version 2.0.64 or later. Run az --version to check, and upgrade if necessary.
• Azure PowerShell (if using): Version 5.9.0 or later. Run Get-InstalledModule -Name Az to check, and upgrade if needed.

Simple Setup: Basic Configuration¶

If you’re happy with the defaults, setting up the NGINX ingress controller is a breeze with Helm. This basic configuration gets you up and running quickly:

Customizing Your Ingress Controller¶

Want more control? Let’s look at customizing your ingress controller. You can choose between an internal static IP or a dynamic public IP address.

Importing Images to Your ACR¶

(Detailed steps for importing images would be added here if the JSON data provided instructions. Since the JSON data only mentions this step without specific instructions, this section remains as a placeholder.)

Creating the Ingress Controller¶

Now, let’s use Helm to install ingress-nginx. Remember, the controller needs to run on a Linux node, not Windows. We’ll use a node selector to make sure of that.

For extra reliability, we’ll deploy two replicas of the ingress controller. This setup works best with more than one node in your AKS cluster.

We’ll also create a Kubernetes namespace called ingress-basic. Feel free to use a different name if you like. If your AKS cluster isn’t using role-based access control (RBAC), add --set rbac.create=false to the Helm commands.

Setting Up an Internal IP Address¶

By default, the ingress controller gets a dynamic public IP. But if you want to restrict access to internal users only, you’ll need an internal, private IP address. Use the --set controller.service.loadBalancerIP and --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-internal"=true parameters to assign the internal IP. Choose an unused IP address within your virtual network.

Checking the Load Balancer¶

Once deployed, check the load balancer service with kubectl get services --namespace ingress-basic -o wide -w ingress-nginx-controller. You should see an EXTERNAL-IP assigned. If you browse to that IP now, you’ll get a 404 page. Don’t worry, we’ll fix that soon!

Demo Time: Running Sample Applications¶

Let’s see the ingress controller in action! Deploy two simple “Hello world” applications. You can use the YAML provided in the original article to create aks-helloworld-one.yaml and aks-helloworld-two.yaml files. Then, apply them using kubectl apply -f aks-helloworld-one.yaml --namespace ingress-basic and kubectl apply -f aks-helloworld-two.yaml --namespace ingress-basic.

Routing Traffic with Ingress¶

With our applications running, we need to tell the ingress controller how to route traffic. Create a Kubernetes ingress resource with rules defining which application gets traffic based on the URL path.

Use the hello-world-ingress.yaml provided in the original article and apply it using kubectl apply -f hello-world-ingress.yaml --namespace ingress-basic. This YAML defines routes for /hello-world-one, /hello-world-two, and /static.

Testing, Testing: Is This Thing On?¶

Time to test! Browse to the EXTERNAL_IP of your ingress controller. You should see the first demo application. Then, try adding /hello-world-two to the IP. The second application should appear!

Testing with an Internal IP¶

To test an internal IP, create a test pod in your cluster and install curl. Then, use curl to access the internal IP address of your ingress controller with and without paths to see the routing in action.

Cleaning Up¶

Finished playing? Clean up by deleting the entire namespace or individual resources using Helm and kubectl. The original article provides the commands for both methods.

What’s Next?¶

This guide gets you started with an unmanaged Ingress controller. Want to learn more? Explore adding TLS, HTTP application routing, and dive deeper into Helm and NGINX. Let us know in the comments if you have any questions or want to share your experiences! Happy routing!