Your backend Pod just crashed.

Kubernetes created a new Pod with a completely different IP address.

Yet your application didn't notice anything changed.

How?

Because applications don't talk directly to Pods.

They talk to Kubernetes Services.

A Service provides a stable virtual IP and DNS name, while kube-proxy quietly programs the networking rules that route traffic to the right Pods.

In this post, we'll go beyond the usual "Service types" explanation and look at how traffic actually reaches your Pods under the hood.

What is a Kubernetes Service?

A Service provides a stable virtual IP (ClusterIP) and DNS name for a dynamic set of Pods.

Think of it as a permanent front door for Pods that may come and go.

Key points:

• Services provide a stable endpoint for applications.
• Pods behind a Service can change without affecting clients.
• Services use labels and selectors to automatically discover matching Pods.
• The Service IP is virtual—there is no process directly listening on that IP.

Important:

A ClusterIP doesn't belong to a real network interface, and no process is directly listening on that IP.

Instead, kube-proxy programs networking rules on every node so packets sent to the ClusterIP are transparently redirected to backend Pods.

How Does a Service Find Its Pods?

Kubernetes uses labels and selectors to determine which Pods belong to a Service.

Example:

Service selector:
app=backend

Matching Pods:
app=backend

Non-matching Pods:
app=frontend

Only the matching Pods become Service endpoints and receive traffic from the Service.

Why Do We Need Services?

Imagine a Deployment with three Pods:

backend-1 → 10.244.1.5
backend-2 → 10.244.2.8
backend-3 → 10.244.3.12

If backend-2 crashes, Kubernetes creates:

backend-4 → 10.244.2.15

The old IP disappears.

Without Services, every client would need to know the new Pod IPs constantly.

Services solve this problem by giving applications a stable endpoint.

Types of Kubernetes Services

1. ClusterIP (Default)

• Accessible only inside the cluster.
• Used for communication between microservices.

2. NodePort

• Exposes the application on a port of every Kubernetes node.
• Useful for testing and simple external access.

3. LoadBalancer

• Creates an external load balancer using your cloud provider.
• Commonly used for production applications.

4. ExternalName

• Maps a Service to an external DNS name using a CNAME record.
• Useful for integrating external services.

How Services Work Under the Hood

When you create a Service:

1. Kubernetes allocates a ClusterIP.
2. Kubernetes creates EndpointSlices, which contain the healthy Pod IPs behind the Service.
3. kube-proxy running on every node watches for Service and EndpointSlice changes.
4. kube-proxy programs networking rules on the node.
5. Traffic sent to the Service IP is automatically redirected to one of the backend Pods.

kube-proxy: The Unsung Hero

Many people think kube-proxy forwards packets itself.

It doesn't.

Its job is to configure the node's networking rules so Linux can route traffic efficiently.

kube-proxy can run in three modes:

iptables Mode

• Most common deployment mode.
• Uses iptables rules for load balancing and NAT.

IPVS Mode

• Uses Linux IP Virtual Server.
• Better scalability and performance for large clusters.

Userspace Mode

• Legacy mode.
• Rarely used today.

Traffic Flow Example

Client Pod
      ↓
Service (ClusterIP)
      ↓
kube-proxy Rules
      ↓
┌─────┬─────┬─────┐
Pod A Pod B Pod C

When a request is sent to a Service:

1. The packet reaches a node.
2. kube-proxy's rules match the Service IP and port.
3. Destination NAT (DNAT) redirects the request to one of the healthy Pods.
4. The Pod sends the response back to the client.

All of this happens transparently.

The client thinks it is communicating with a single stable IP.

Common Service Problems

Pods are not receiving traffic?

Check whether labels match the Service selector.

kubectl describe service <service-name>
kubectl get endpointslices

No backend Pods found?

Verify the Pods are Ready.

kubectl get pods -o wide

Debug kube-proxy Rules

ipvsadm -Ln
iptables -t nat -L KUBE-SERVICES -n

Fun Fact

Some modern networking solutions like Cilium can replace kube-proxy entirely using eBPF, reducing iptables complexity and improving observability.

Summary

Pods are temporary, and their IP addresses can change at any time.

Kubernetes Services provide a stable entry point, while kube-proxy makes the magic happen by programming networking rules on every node.

Understanding this flow helps you:

• Debug Service connectivity issues faster
• Choose the right Service type
• Understand how traffic moves inside Kubernetes
• Build more reliable Kubernetes applications

Next in the Series: CoreDNS Explained – How Kubernetes Turns Service Names into IP Addresses