Kubernetes Networking & Traffic Management

Kubernetes Networking & Traffic Management defines how pods communicate with each other, how services are exposed, and how traffic flows inside and outside the cluster.

In simple terms, it ensures that your applications can talk internally within the cluster and be accessed externally in a controlled and reliable way.

Why Networking is Important in Kubernetes

In Kubernetes, pods are ephemeral (temporary) in nature:

Pods can be created, restarted, or deleted anytime
Each pod gets a new IP address when recreated
Pod IPs are not stable or fixed

This creates a challenge:

How do services communicate if IPs keep changing?

Core Kubernetes Networking Concepts

1. Pod-to-Pod Communication

In Kubernetes, every pod gets its own unique IP address, and all pods inside the cluster can communicate with each other directly.

Every pod gets a unique IP address
Pods can communicate directly (no NAT required)
Communication is fast and internal within the cluster
Pod IPs are temporary and change when pods restart
We should NOT use Pod IPs in real applications
Instead, we use Kubernetes Services for stable communication

Example

Step 1: Create Pod A (nginx)

apiVersion: v1
kind: Pod
metadata:
  name: pod-a
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Step 2: Create Pod B (busybox)

apiVersion: v1
kind: Pod
metadata:
  name: pod-b
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sh", "-c", "sleep 3600"]

Step 3: Get Pod IP

kubectl get pods -o wide

Example output:

pod-a   10.244.1.5

Step 4: Access Pod A from Pod B

kubectl exec -it pod-b -- sh
wget [<http://10.244.1.5>](<http://10.244.1.5/>)

Problem

If Pod A restarts:

Its IP changes (example: 10.244.1.5 → 10.244.2.8)
Old IP stops working

2. Services (Stable Networking Layer)

A Service in Kubernetes provides a stable IP address and DNS name for a group of pods.

? Since pod IPs change frequently, Services act as a fixed entry point to access applications.

Provides stable access to pods
Uses labels to connect with pods
Automatically does load balancing
Gives fixed IP + DNS name

Types of Services:

a) ClusterIP (Default)

Used for internal communication inside cluster

Example

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

b) NodePort

Used to expose service outside the cluster (for testing)

Example

apiVersion: v1
kind: Service
metadata:
  name: test-service
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

Access Example:

http://<NodeIP>:30080

c) LoadBalancer

Used to expose service to internet (production)

Example

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer
  selector:
    app: frontend
  ports:
    - port: 80
      targetPort: 8080

3. Ingress (Smart Traffic Routing)

Ingress in Kubernetes is used to manage external HTTP/HTTPS traffic in a smart and centralized way.

Instead of exposing multiple services separately, Ingress gives you one entry point for all external traffic.

Key Features

URL-based routing (e.g. /api, /ui)
Domain-based routing (e.g. api.example.com, app.example.com)
SSL termination (HTTPS support)
Load balancing across services
Single entry point for multiple services

Example (Ingress)

Step 1: Backend Service

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

Step 2: Frontend Service

apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  selector:
    app: frontend
  ports:
    - port: 80
      targetPort: 3000

Step 3: Ingress Rule

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  rules:
  - http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: backend-service
            port:
              number: 80
      - path: /ui
        pathType: Prefix
        backend:
          service:
            name: frontend-service
            port:
              number: 80

4. Traffic Flow in Kubernetes

In Kubernetes, the request from a user does not go directly to a pod. It follows a structured flow to ensure security, scalability, and proper routing.

Typical Traffic Flow

User Request → Ingress → Service → Pod

Explanation:

User Request: User sends request to the application (e.g. http://myapp.com/api).
Ingress: Ingress receives external request and routes it based on URL or domain.
Service: Service forwards request to the correct pod and balances traffic.
Pod: Pod runs the application and processes the request.

5. Load Balancing

Kubernetes automatically distributes incoming traffic across multiple pods to ensure smooth performance and reliability.

Key Points

Traffic is automatically shared between multiple pods
Prevents any single pod from getting overloaded
Improves application performance and speed
Ensures high availability if one pod fails
Works automatically using Kubernetes Services

Simple Example

If you have 3 pods running:

Pod-1, Pod-2, Pod-3

? Traffic flow:

Request 1 → Pod-1  
Request 2 → Pod-2  
Request 3 → Pod-3

6. Network Policies (Security Layer)

Network Policies in Kubernetes are used to control and restrict traffic between pods.

? In simple words: They decide which pod can talk to which pod.

Key Points

Controls communication between pods
Improves cluster security
Allows only permitted traffic
Blocks unwanted or direct access
Works like a firewall inside Kubernetes

Example Network Policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend
spec:
  podSelector:
    matchLabels:
      app: database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

Explanation:

Only pods with label backend can access the database
All other pods are blocked by default (if policy is applied)

Real-World Example

In a real Kubernetes-based web application:

Frontend is exposed to users using Ingress
Backend is exposed internally using a ClusterIP Service
Database is accessible only inside the cluster (not public)
Network Policies control and restrict who can access the database

Conclusion

Pods communicate using internal Kubernetes networking
Services provide stable and reliable access to pods
Ingress manages external HTTP/HTTPS traffic
Network Policies add security between pods
Load balancing ensures traffic is evenly distributed and stable