Service Types

Kubernetes Services: The Traffic Directors of Your Cluster

The Story of the Pizza Shop

Imagine you own a super popular pizza shop with 10 kitchens (that’s like having 10 Pods running your app). Customers keep calling to order pizza, but how do they reach the right kitchen? They don’t call each kitchen directly—that would be chaos! Instead, they call one phone number, and someone (the Service) connects them to an available kitchen.

That’s exactly what Kubernetes Services do. They give your Pods a stable address and distribute traffic to them.

What Are Services? (Services Overview)

A Service in Kubernetes is like a receptionist for your Pods.

The Problem Services Solve

Pods are temporary. They come and go. Each time a Pod restarts, it gets a new IP address. Imagine if your pizza shop changed its phone number every hour—customers would never reach you!

# A Pod's IP changes when it restarts
Pod-A: 10.0.0.5  → restarts → 10.0.0.12
Pod-B: 10.0.0.6  → restarts → 10.0.0.15
# How do other apps find them?

The Solution

A Service provides:

• Stable IP address that never changes
• Stable DNS name (like my-app.default.svc.cluster.local)
• Load balancing across all matching Pods

graph TD
    A["Client"] --> B["Service<br/>Stable IP: 10.96.0.1"]
    B --> C["Pod 1<br/>10.0.0.5"]
    B --> D["Pod 2<br/>10.0.0.6"]
    B --> E["Pod 3<br/>10.0.0.7"]

Simple Example

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

What this does: Any Pod with label app: pizza gets traffic from this Service!

ClusterIP Service: The Internal Phone Line

ClusterIP is the default Service type. Think of it as an internal phone line that only works inside your building (cluster).

When to Use It

• Apps talking to each other inside the cluster
• Database connections
• Microservices communication

How It Works

graph TD
    A["Frontend Pod"] -->|calls| B["ClusterIP Service<br/>10.96.0.100:80"]
    B --> C["Backend Pod 1"]
    B --> D["Backend Pod 2"]
    E["Outside World"] -.->|Cannot reach| B

Example

apiVersion: v1
kind: Service
metadata:
  name: backend-service
spec:
  type: ClusterIP  # This is the default
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 3000

Real Life: Your frontend app calls backend-service:80 and Kubernetes automatically sends the request to a healthy backend Pod.

Key Points

NodePort Service: The Building Entrance

NodePort opens a specific door (port) on every building (node) in your cluster. Anyone who knows the building address can walk in!

When to Use It

• Quick testing and development
• When you don’t have a cloud load balancer
• Simple external access needs

How It Works

graph TD
    A["User"] -->|Node IP:30080| B["Node 1"]
    A -->|Node IP:30080| C["Node 2"]
    B --> D["NodePort Service<br/>Port 30080"]
    C --> D
    D --> E["Pod 1"]
    D --> F["Pod 2"]

Example

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080  # Opens this port on ALL nodes

Access it: http://<any-node-ip>:30080

Port Range

NodePort must be between 30000-32767 (by default).

Key Points

LoadBalancer Service: The Professional Reception Desk

LoadBalancer is the VIP entrance. It automatically creates a cloud load balancer (in AWS, GCP, Azure) that distributes traffic professionally.

When to Use It

• Production applications
• When running on cloud providers
• High-traffic apps needing reliability

How It Works

graph TD
    A["Users"] --> B["Cloud Load Balancer<br/>203.0.113.50"]
    B --> C["Node 1"]
    B --> D["Node 2"]
    B --> E["Node 3"]
    C --> F["Pod"]
    D --> G["Pod"]
    E --> H["Pod"]

Example

apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: production-web
  ports:
    - port: 80
      targetPort: 8080

Magic: Kubernetes asks your cloud provider to create a real load balancer with a public IP!

Key Points

Headless Services: Direct Line to Each Kitchen

Sometimes you don’t want a receptionist—you want to call each kitchen directly. That’s a Headless Service.

When to Use It

• StatefulSets (databases like Cassandra, MongoDB)
• When you need to know individual Pod IPs
• Custom load balancing logic

How It Works

Set clusterIP: None and suddenly each Pod gets its own DNS entry!

graph TD
    A["Client"] -->|DNS Lookup| B["Headless Service"]
    B -->|Returns ALL Pod IPs| A
    A -->|Direct connection| C["Pod-0: 10.0.0.5"]
    A -->|Direct connection| D["Pod-1: 10.0.0.6"]
    A -->|Direct connection| E["Pod-2: 10.0.0.7"]

Example

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  clusterIP: None  # This makes it headless!
  selector:
    app: database
  ports:
    - port: 5432

DNS Magic

With a headless service, DNS returns all Pod IPs:

# Normal Service DNS returns:
my-service → 10.96.0.1 (Service IP)

# Headless Service DNS returns:
my-headless → 10.0.0.5, 10.0.0.6, 10.0.0.7 (Pod IPs)

Headless vs ClusterIP: The Key Difference

Let’s compare our receptionist (ClusterIP) vs direct line (Headless):

Visual Comparison

graph LR
    subgraph ClusterIP
        A["Client"] --> B["Service IP"]
        B --> C["Pod 1"]
        B --> D["Pod 2"]
    end
    subgraph Headless
        E["Client"] --> F["Pod 1 directly"]
        E --> G["Pod 2 directly"]
    end

When to Choose Which?

Choose ClusterIP when:

• You want simple load balancing
• You don’t care which Pod handles the request
• Typical web apps and APIs

Choose Headless when:

• You need to talk to specific Pods
• Running StatefulSets (databases)
• Building custom service discovery

Service Session Affinity: Sticky Customers

Imagine a customer calls your pizza shop and talks to Kitchen #3. They want to call back later and talk to the same kitchen. That’s Session Affinity!

What It Does

Session Affinity makes requests from the same client go to the same Pod.

Types of Session Affinity

Example

apiVersion: v1
kind: Service
metadata:
  name: sticky-service
spec:
  selector:
    app: web
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 3600  # Sticky for 1 hour
  ports:
    - port: 80

How It Works

graph TD
    A["Client A<br/>192.168.1.10"] -->|Always goes to| B["Pod 1"]
    C["Client B<br/>192.168.1.20"] -->|Always goes to| D["Pod 2"]
    E["Client C<br/>192.168.1.30"] -->|Always goes to| F["Pod 3"]

When to Use Session Affinity

• Shopping carts stored in memory
• User sessions not in a shared database
• WebSocket connections

Warning

Session affinity can cause uneven load distribution. If one client sends way more requests, one Pod gets overloaded!

Service Type Comparison: The Complete Picture

Let’s put it all together! Here’s your ultimate comparison guide:

Quick Reference Table

Visual Summary

graph TD
    subgraph "Inside Cluster Only"
        A["ClusterIP<br/>Internal communication"]
        B["Headless<br/>Direct Pod access"]
    end
    subgraph "External Access"
        C["NodePort<br/>Port 30000-32767"]
        D["LoadBalancer<br/>Cloud provider IP"]
    end

Decision Flowchart

graph TD
    A["Need external access?"] -->|No| B["Need individual Pod IPs?"]
    A -->|Yes| C["Have cloud provider?"]
    B -->|No| D["ClusterIP"]
    B -->|Yes| E["Headless"]
    C -->|No| F["NodePort"]
    C -->|Yes| G["LoadBalancer"]

Real-World Examples

Cost Consideration

• ClusterIP: Free
• NodePort: Free
• Headless: Free
• LoadBalancer: Costs money (cloud provider charges)

Your Confidence Checklist

After reading this, you should feel confident about:

• [ ] Understanding why Services exist (Pods have changing IPs)
• [ ] Creating a ClusterIP Service for internal apps
• [ ] Using NodePort for quick external access
• [ ] Deploying LoadBalancer for production
• [ ] Knowing when to use Headless Services
• [ ] Understanding the difference between Headless and ClusterIP
• [ ] Configuring Session Affinity for sticky sessions
• [ ] Choosing the right Service type for any scenario

Quick Recap: The Pizza Shop Story

You’re now ready to orchestrate network traffic in Kubernetes like a pro!