Kubernetes Networking in Azure Kubernetes Service (AKS)
This document provides a comprehensive guide to understanding and configuring networking for Azure Kubernetes Service (AKS) clusters. Effective network configuration is crucial for the communication, security, and performance of your containerized applications.
Core Networking Concepts in AKS
AKS leverages several Azure networking components and Kubernetes native networking features. Understanding these interplays is key to managing your cluster's network:
1. Virtual Networks (VNets) and Subnets
AKS clusters are deployed within an Azure Virtual Network. This provides an isolated and secure network environment for your cluster's nodes and pods. You can either let AKS create a VNet for you or deploy your AKS cluster into an existing VNet.
- Pod CIDR: A large IP address range from which pod IP addresses are assigned. This range should not overlap with your VNet subnet CIDR.
- Service CIDR: A IP address range from which Kubernetes service IP addresses are assigned. This range should not overlap with your VNet subnet or pod CIDR.
2. Azure CNI Network Plugin
AKS supports two primary network plugins:
-
Azure CNI: In this mode, each pod gets an IP address directly from the VNet subnet. This provides full native VNet integration, allowing pods to be addressed like any other Azure resource. This mode offers the most flexibility but consumes more IP addresses.
Note: Ensure your subnet has enough available IP addresses for your nodes and the expected number of pods.
- kubenet: With kubenet, nodes get an IP address from the VNet subnet, and pods are assigned IP addresses from a virtual network overlay. Network traffic is then routed by the node. This is simpler and conserves IP addresses.
3. Ingress Controllers
Ingress controllers manage external access to services in a cluster, typically HTTP and HTTPS. AKS offers:
- AKS Ingress Controller (Nginx): A common choice for basic HTTP/S routing.
- Application Gateway Ingress Controller (AGIC): Integrates with Azure Application Gateway to provide advanced L7 load balancing, SSL termination, and Web Application Firewall (WAF) capabilities.
You can install an Ingress controller using Helm or during cluster creation.
4. Network Security Groups (NSGs)
NSGs are applied to subnets or network interfaces to filter network traffic. AKS automatically manages NSGs for its control plane and node subnets to allow necessary traffic for cluster operation.
5. Azure Firewall
For advanced network security and centralized management, you can integrate AKS with Azure Firewall to control egress traffic from your cluster.
Common Networking Scenarios
Exposing Applications
You can expose your applications in AKS using several Kubernetes service types:
- ClusterIP: Exposes the service on a cluster-internal IP. Only accessible from within the cluster.
- NodePort: Exposes the service on each Node's IP at a static port. Accessible from outside the cluster via
<NodeIP>:<NodePort>. - LoadBalancer: Exposes the service externally using a cloud provider's load balancer. For AKS, this typically provisions an Azure Load Balancer.
- Ingress: Provides HTTP and HTTPS routing to services, enabling features like name-based virtual hosting and SSL termination.
Network Policies
Network Policies are Kubernetes resources that control the traffic flow at the IP address or port level (OSI layer 3 or 4) between pods. They are implemented by a network plugin that supports them, such as Azure CNI.
Example Network Policy to allow ingress from specific pods:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-specific-ingress
spec:
podSelector:
matchLabels:
app: my-backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: my-frontend
ports:
- protocol: TCP
port: 8080
Private Clusters
For enhanced security, you can create AKS clusters with private API server endpoints, meaning the control plane is not exposed to the public internet. This requires careful network configuration for access.
Best Practices for AKS Networking
- Plan your IP addressing: Carefully design your VNet and subnet CIDRs, and your Pod and Service CIDRs, to avoid overlaps and ensure sufficient address space.
- Choose the right network plugin: Azure CNI offers more flexibility and direct VNet integration, while kubenet is simpler and conserves IPs.
- Utilize Ingress controllers effectively: Choose AGIC for advanced L7 features or the Nginx controller for simpler deployments.
- Implement Network Policies: Enforce granular traffic control between your pods for a zero-trust security posture.
- Secure egress traffic: Use Azure Firewall or NSGs to control outgoing connections from your cluster.
- Monitor network performance: Use Azure Monitor and Kubernetes tools to track network latency and throughput.
For detailed configuration steps and advanced scenarios, please refer to the official Azure Kubernetes Service documentation.