Networking in Kubernetes
Kubernetes services provide connectivity to pods both internally and externally. Note that when we refer to “services,” we mean the Kubernetes objects used to manage and control network access—not the generic concept of services. AKS networking handles three primary traffic types:- Internal Traffic
- Incoming Direct Traffic
- Incoming Non-Direct Traffic
Internal Traffic
Internal communication within the Kubernetes cluster utilizes the ClusterIP service. This default service assigns a single IP address to a group of ports, facilitating seamless internal communication. The diagram below demonstrates how traffic is directed to a ClusterIP on port 80 before being forwarded into the cluster.
Incoming Direct Traffic
For exposing services externally on a specific port, Kubernetes uses the NodePort service. This service allocates a static port (for example, port 31000) on every node. External traffic addressed to this port is then forwarded to the appropriate pod port (port 80 in this instance), functioning similarly to NAT rules in a firewall environment.Incoming Non-Direct Traffic
The LoadBalancer service is utilized when external traffic is not addressed directly. This service is commonly used in production scenarios, where an Azure Load Balancer distributes inbound traffic from port 80 to the corresponding backend pods. The process is depicted in the diagram below:
Creating Services with Manifests
Kubernetes services in AKS are defined using YAML manifests. These manifests specify selectors, ports, and the service type (such as ClusterIP, NodePort, or LoadBalancer) required for your application. Tools likekubectl are used to deploy these manifests into your cluster.
Review your YAML manifests carefully to ensure that service selectors and port mappings correctly mirror your application’s requirements.
Container Network Interface (CNI)
A critical concept in container networking is the Container Network Interface (CNI). CNI establishes a standard framework for developing and deploying network plugins in container orchestration platforms like Kubernetes. This framework ensures efficient communication between containers and external endpoints while allowing for the integration of diverse networking solutions.Networking Options in Azure
When managing container networks in Azure, you have two primary options:| Networking Option | Description | Advantages | Considerations |
|---|---|---|---|
| Azure CNI | Direct integration with Azure virtual networks where each pod receives an IP address from the subnet | Leverages native network security features such as Network Security Groups (NSGs), route tables, and firewalls | Can result in higher IP consumption |
| Kubenet | A lightweight networking plugin that performs NAT for pods using Azure infrastructure | Lower IP consumption with a simplified networking setup | Offers less granular control over network traffic compared to Azure CNI |
Using Azure CNI is generally recommended for production workloads due to its superior security features and comprehensive network control.