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