Introduction to AKS Networking

Networking is a critical component of any Kubernetes cluster, and Azure Kubernetes Service (AKS) provides robust options to manage network traffic for your applications.

AKS offers two primary network plugins: Azure CNI and Kubenet. Each has its own advantages and use cases depending on your specific requirements for IP address management, network performance, and integration with Azure networking services.

Azure CNI

Azure CNI is the default and recommended network plugin for AKS. It integrates directly with your Azure Virtual Network (VNet), providing each pod with a unique IP address from the VNet's subnet.

  • Pod IP Allocation: Pods receive IP addresses directly from your VNet's subnet.
  • Performance: Offers higher network throughput and lower latency as traffic doesn't traverse a NAT layer for pod-to-pod communication within the cluster.
  • Network Policies: Supports Kubernetes Network Policies for fine-grained traffic control.
  • Azure Integration: Seamless integration with Azure Load Balancer, Azure Firewall, and other Azure networking constructs.
(Diagram showing Pods with VNet IPs, directly communicating via Azure VNet)

Configuration with Azure CNI

When creating an AKS cluster with Azure CNI, you specify the VNet and subnet where the cluster's nodes and pods will reside. It's crucial to ensure sufficient IP addresses are available in the chosen subnet to accommodate the nodes and all expected pods.

az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --network-plugin azure \
    --vnet-subnet-id "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVnet/subnets/aks-subnet" \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --docker-bridge-address 172.17.0.1/16

Kubenet

Kubenet is a simpler networking solution that uses a virtual network managed by Kubernetes. Each node gets an IP from the VNet, but pods receive IP addresses from a bridge network on the node.

  • Pod IP Allocation: Pods are assigned IP addresses from a bridge network. Traffic to and from pods is NAT'd to the node's IP address.
  • Simplicity: Easier to set up and requires less planning for IP address space.
  • Limitations: May have performance limitations compared to Azure CNI for high-traffic scenarios.
  • Azure Integration: Relies more on Kubernetes Services and Ingress for external access.
(Diagram showing Nodes with VNet IPs, Pods on node bridge networks, NAT for external traffic)

When to use Kubenet

Kubenet is suitable for development environments, smaller clusters, or scenarios where the complexity of managing a dedicated VNet subnet for pods is not desired.

Load Balancing

AKS integrates with Azure Load Balancer to distribute incoming traffic across the pods that back a Kubernetes Service of type LoadBalancer.

  • Internal Load Balancer: For exposing services within your VNet.
  • Public Load Balancer: For exposing services to the internet.

When you create a Service of type LoadBalancer, AKS automatically provisions and configures an Azure Load Balancer. You can then configure it further using annotations.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  type: LoadBalancer

Ingress Controllers

For more advanced HTTP and HTTPS routing capabilities, AKS supports Ingress controllers.

An Ingress controller provides features like:

  • Host-based and path-based routing
  • TLS termination
  • Load balancing of external HTTP(S) traffic

The most common Ingress controller used with AKS is the NGINX Ingress Controller, which can be installed via Helm or the AKS Add-on.

(Diagram showing Ingress Controller routing external traffic to different Services)

AKS Application Gateway Ingress Controller (AGIC)

AGIC allows you to use Azure Application Gateway as the ingress for your AKS cluster. This provides benefits like Web Application Firewall (WAF) capabilities and SSL offloading.

Network Policies

Network Policies are Kubernetes resources that control the flow of traffic between pods and network endpoints. They act like firewalls at the pod level.

To use Network Policies, your AKS cluster must be configured with a Network Policy provider. Azure CNI supports Network Policy. You can enable it during cluster creation or update an existing cluster.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

This example policy denies all ingress traffic to all pods in the namespace unless explicitly allowed by another policy.

Service Discovery

Kubernetes Services provide a stable endpoint for accessing a set of pods. Pods can discover other services using DNS.

When using Azure CNI, pods can communicate directly with each other using their VNet IP addresses. When using Kubenet, communication often involves NAT.

DNS in AKS

AKS uses CoreDNS for in-cluster DNS resolution. Each cluster gets a default DNS service IP address (e.g., 10.0.0.10) that pods use to resolve service names and external domains.

You can configure custom DNS servers or conditional forwarding if needed.