Kubernetes Services in Azure AKS - Network integration

Azure Kubernetes Services (AKS) is a managed Kubernetes service in Azure. Not only does it provides a managed cluster, it also integrates with Azure services.

In this article we’ll explain the integration between Kubernetes’ services and Azure Networking. We won’t give code sample though as we’ll keep that for a future article.

Update (30-08-2018): See the following article in order to deploy and test the concepts established here using an ARM Template.

Anatomy of Services

Let’s dive right in. I like to think about a Kubernetes service in the following way:


From the ground up:

Component Description
Container Image Contains all the files enabling a container runtime. It also holds the ports configuration.
Container Based on an image, it runs within the image context. It also maps VM ports to inside-container ports.
Pod A pod can run one or many containers. A pod has its own IP. A pod maps the VM ports used by the container the IP of the pod.
Replica Set Pods are ephemeral and can die. A Replica set ensures a number of pods following the same template (e.g. container images) are up and running. A selector allows the replica set to aggregate its pods.
Service A service exposes a bunch of pods as a single... service. A service also has its own IP. It maps the pods port to that IP. It aggregates multiple pods via a selector.

A few observations:

Services in AKS

Kubernetes is designed to integrate to cloud environments. It has different plugins implemented differently on different cloud platforms.

There are two network modes for AKS: Basic & Advanced.

Under basic networking, AKS manages its own Virtual Network. Pods IPs are accessible from within the cluster. Only publicly exposed services are accessible outside the cluster.

Under advanced networking, AKS’s nodes are deployed within a specified Azure Virtual Network we control. This allows us to keep the services running on AKS on private IPs. It also allows us to make them accessible from on premise network.

Advanced Networking scenario

There are many ways to leverage Kubernetes in AKS. To simplify the discussion, let’s take one scenario:

This is a simple scenario for Advanced Networking. The last point, i.e. port mapping, is somewhat complicated. We chose that configuration to show port mapping.

Let’s see how this scenario lands in AKS.

Virtual Network

First, we have our Virtual Network before we deploy AKS in it.

Virtual Network

We configure it with two subnets:

Deploying AKS

Now we deploy AKS in Advanced Networking mode. We specify the AKS subnet.


Under the hood, AKS deploys 3 VMs with a NIC each. Each VM has a private IP. In Kubernetes, those are the Nodes IPs.

Deploying a replica set

Now let’s deploy our replica set. This deploys 3 pods on our cluster.

Each pod is given a private IP within the same subnet as the VM. The pod expose port 85. It remaps the container port 80 to port 85.


Under the hood, those IPs belong to the VMs and are assigned at creation. They are mapped to pods as pods are created.

Deploying a service

Finally, we deploy our service using Azure Load Balancer. We specify Services Subnet as the target subnet.

The Azure Load Balancer has a private IP and forwards traffic to pods. It exposes the port 90 and forwards traffic from that port to the pods’ port 85.

In Kubernetes lingo this is called the External IP.


The service also has an Internal IP. That internal IP doesn’t belong to the Virtual Network. It is a virtual address routable only from within the cluster. That IP simply routes to the load balance private IP.


We hope this overview of Services in Kubernetes and AKS clarified some of the mechanisms at play.

In a future article, we will give explore to implement what we’ve explore in this article.

Leave a comment