Networking

Pod vs Container

• Pod is the smallest deployable unit in Kubernetes, not a container.

• Each pod generally contains one main container (e.g., PostgreSQL, Elasticsearch, app containers).

• Purpose of Pod abstraction:

  • Encapsulates one or more containers

  • Provides shared networking and storage context

---

Why Pod Abstraction is Critical?

Port Allocation Challenges Without Pods

• Containers on the same host require unique host ports for binding services.

  • Example: PostgreSQL running inside Docker

    • Host port 5000 mapped to container port 5432

• Multiple containers can be run with unique host ports, but:

  • Scalability suffers with hundreds of containers

  • Port tracking becomes difficult

Kubernetes Solution: IP-per-Pod

• Each pod gets a unique IP address within the cluster.

  • Eliminates the need for host port mappings

• Pods behave like isolated virtual machines with:

  • Their own IP address

  • Their own range of internal ports

• Enables:

  • Multiple pods with apps on the same port (e.g., 10 services on port 8080)

  • No conflicts due to IP isolation

---

Pod Network Behavior

Network Namespace and Virtual Interface

• When a pod is created:

  • Gets its own network namespace

  • Connected via virtual Ethernet (veth) pair to the host network

• Treat each pod as:

  • A self-contained host

  • Similar to a physical laptop/server in networking behavior

---

Creating Multiple Pods with the Same App

Demonstration: PostgreSQL Example

• Created one pod with PostgreSQL container using YAML

• Applied it via kubectl apply

• No conflict in ports even with multiple identical pods (e.g., postgres, postgres2)

• Useful for replicas or scaling

---

Runtime Abstraction Benefits

• Pod-level abstraction allows swapping container runtimes (e.g., Docker, containerd, CRI-O)

  • Kubernetes remains agnostic to the runtime

• Replacing Docker with another runtime does not affect pod configuration

---

Multi-Container Pods

When to Use

• Helper or sidecar containers for:

  • Synchronization

  • Backup

  • Scheduling

  • Authentication gateways

Example Use Case

• Pod with:

  • Main container: NGINX

  • Sidecar container: Curl-based utility with curl, netstat, delay logic (sleep)

---

Container Communication Inside a Pod

Shared Network Namespace

• All containers in a pod share:

  • Same IP address

  • Same localhost network interface

• Communication:

  • Via localhost:<port>

  • Just like processes on a single machine

Demonstration:

• Entered the curl container

• Verified:

  • netstat shows NGINX listening on port 80

  • curl localhost:80 returns NGINX default page

  • NGINX logs confirm request from sidecar container

---

Pause (Sandbox) Containers

Role of Pause Containers

• Created automatically for every pod

• Maintains the network namespace shared by containers

• Ensures:

  • Network consistency if containers restart

  • Pod IP remains unchanged if a container is restarted

• If the pod itself dies, a new pod gets a new IP address

---

Inspecting Pod Containers in Minikube

Accessing Minikube Docker Host

• Minikube runs in a separate VM

• Docker containers inside Minikube are not visible from the host

• Use:

  eval $(minikube docker-env)

  • Redirects Docker CLI to use Minikube’s Docker daemon

Verifying Containers

• docker ps inside Minikube shows:

  • Main containers

  • Pause containers for each pod

• Identified pause container for the NGINX pod