Kubernetes Services Explained: ClusterIP, NodePort & LoadBalancer
Exploring and building innovative tech solutions for the future while documenting the insights and knowledge gained along the way.
When running applications in Kubernetes, Pods are constantly created, destroyed, and replaced. Because of this dynamic nature, Pod IP addresses keep changing.
This creates a problem.
If a frontend application wants to communicate with a backend Pod, how will it know the Pod’s IP if it keeps changing?
This is where Kubernetes Services come in.
Kubernetes Services provide a stable network endpoint that allows clients to communicate with Pods reliably, even when Pods change.
In this article, we will explore:
Why Kubernetes Services exist
ClusterIP
NodePort
LoadBalancer
How kube-proxy works
iptables vs IPVS networking
Why Kubernetes Services Exist
Pods are ephemeral. They can restart or be recreated at any time.
Example:
Pod A → 10.244.1.5
Pod B → 10.244.2.7
Pod C → 10.244.3.9
If Pod A dies and Kubernetes creates a new one, its IP will change.
Applications cannot rely on changing IPs.
To solve this, Kubernetes creates a Service that provides:
A stable IP address
A DNS name
Load balancing between Pods
Example service:
frontend-service → 10.96.32.10
Clients connect to the Service, and Kubernetes automatically forwards traffic to the correct Pods.
Kubernetes Service Architecture
The request flow inside Kubernetes usually looks like this:
Client → Service → kube-proxy → Pod
Steps:
Client sends request to Service IP
Service selects matching Pods
kube-proxy routes traffic
Request reaches one of the backend Pods
This enables reliable communication between services.
ClusterIP (Default Service Type)
ClusterIP is the default Kubernetes Service type.
It exposes a service inside the cluster only.
This means external users cannot access it.
Example:
frontend-service → ClusterIP → Pods
Pods inside the cluster can access the service using DNS:
http://frontend-service
Example YAML:
apiVersion: v1
kind: Service
metadata:
name: frontend-service
spec:
selector:
app: frontend
ports:
- port: 80
targetPort: 8080
type: ClusterIP
Use cases:
Internal microservice communication
Backend APIs
Database services
NodePort
NodePort exposes a service on each node's IP address and port.
This allows external traffic to reach the cluster.
Example:
NodeIP:30007
Request flow:
Client → NodeIP:NodePort → Service → Pod
Example YAML:
apiVersion: v1
kind: Service
metadata:
name: frontend-service
spec:
type: NodePort
selector:
app: frontend
ports:
- port: 80
targetPort: 8080
nodePort: 30007
Default NodePort range:
30000 – 32767
Use cases:
Development environments
Quick testing
Small clusters
However, it is not ideal for production because it requires opening ports on nodes.
LoadBalancer
LoadBalancer exposes services to the internet using a cloud provider’s load balancer.
This is commonly used in cloud environments like:
AWS
Azure
Google Cloud
Example flow:
Internet → Cloud LoadBalancer → Service → Pods
Example YAML:
apiVersion: v1
kind: Service
metadata:
name: frontend-service
spec:
type: LoadBalancer
selector:
app: frontend
ports:
- port: 80
targetPort: 8080
Kubernetes automatically provisions an external IP:
EXTERNAL-IP: 34.120.45.90
Users can then access:
http://34.120.45.90
Use cases:
Public APIs
Web applications
Production services
kube-proxy: The Traffic Manager
Kubernetes Services rely on a component called kube-proxy.
kube-proxy runs on every node in the cluster.
Its job is to:
Watch Kubernetes Services
Create routing rules
Forward traffic to backend Pods
When a Service is created, kube-proxy configures the node's networking to route traffic correctly.
Without kube-proxy, services would not be able to forward requests to Pods.
iptables vs IPVS
kube-proxy supports two networking modes.
iptables Mode
iptables uses Linux firewall rules to route traffic.
Flow:
Client → Service IP → iptables rule → Pod
Advantages:
Simple
Default mode
Limitations:
Slower when many services exist
Large rule tables
IPVS Mode
IPVS (IP Virtual Server) is a high-performance load balancer built into the Linux kernel.
Flow:
Client → Service IP → IPVS load balancer → Pod
Advantages:
Better performance
Efficient load balancing
Scales to large clusters
Because of these benefits, many production clusters use IPVS mode.
Example Service Communication Flow
A typical service request in Kubernetes looks like this:
Client
│
▼
Service (ClusterIP)
│
▼
kube-proxy
│
▼
Pod 1 / Pod 2 / Pod 3
The service automatically distributes traffic between Pods.
This provides built-in load balancing.
When to Use Each Service Type
| Service Type | Access | Use Case |
|---|---|---|
| ClusterIP | Internal only | Microservice communication |
| NodePort | External via Node IP | Testing / development |
| LoadBalancer | Public internet | Production applications |
Kubernetes Services in DevOps Interviews – Answers
1. What is a Kubernetes Service?
A Kubernetes Service is an abstraction that provides a stable network endpoint to access a group of Pods.
Pods in Kubernetes are ephemeral (they can die, restart, or be recreated with new IP addresses). A Service solves this problem by providing:
A stable IP address
A DNS name
Load balancing across pods
Example
You have 3 backend pods:
pod-1 → 10.244.1.5
pod-2 → 10.244.2.8
pod-3 → 10.244.3.2
A service sits in front of them:
backend-service → routes traffic → pod-1 / pod-2 / pod-3
Clients communicate with the Service, not directly with pods.
2. Difference between ClusterIP, NodePort, and LoadBalancer
1. ClusterIP (Default)
ClusterIP exposes the service only inside the Kubernetes cluster.
Accessible by other pods
Not accessible from outside the cluster
Used for internal communication
Example:
Frontend Pod → Backend Service (ClusterIP) → Backend Pods
Service IP example:
10.96.15.23
2. NodePort
NodePort exposes the service on a port of every node in the cluster.
External users can access it using:
<NodeIP>:<NodePort>
Example:
192.168.1.10:30007
Flow:
Client → NodeIP:NodePort → Service → Pods
NodePort range:
30000 – 32767
3. LoadBalancer
LoadBalancer exposes the service using a cloud provider load balancer (AWS, Azure, GCP).
Example in AWS:
AWS ELB → Kubernetes Service → Pods
Flow:
Client → Cloud Load Balancer → Service → Pods
It automatically creates:
External IP
Load balancer
NodePort internally
Quick Comparison Table
| Type | Access | Use Case |
|---|---|---|
| ClusterIP | Internal only | Microservice communication |
| NodePort | External via node IP | Testing / small setups |
| LoadBalancer | External via cloud LB | Production apps |
3. What does kube-proxy do?
kube-proxy is a network component that runs on every node.
Its job is to implement Kubernetes Service networking.
When a Service is created:
kube-proxy detects the service
It configures network rules
Traffic is forwarded to the correct pods
Example flow:
Client → Service IP → kube-proxy → Pod
kube-proxy handles:
Service routing
Load balancing
Network rule management
4. What is iptables vs IPVS?
These are two methods kube-proxy can use to route traffic.
iptables Mode
iptables uses Linux firewall rules to forward traffic.
Example rule:
ServiceIP → Pod1
ServiceIP → Pod2
ServiceIP → Pod3
Pros:
Simple
Default mode
Cons:
Slower when many services exist
Rules grow large
IPVS Mode
IPVS (IP Virtual Server) is a high-performance load balancer built into Linux.
Instead of many firewall rules, it uses efficient hash tables.
Pros:
Faster
Scales better
Better load balancing algorithms
Cons:
- Slightly more complex setup
Summary
| Feature | iptables | IPVS |
|---|---|---|
| Performance | Medium | High |
| Scalability | Lower | Better |
| Implementation | Firewall rules | Kernel load balancer |
Most large clusters use IPVS.
5. How does Kubernetes Load Balancing Work?
Kubernetes load balancing works at two levels.
1. Service Level Load Balancing
A Service distributes traffic across pods.
Example:
Service
↓
Pod1
Pod2
Pod3
Traffic is balanced using:
iptables
IPVS
2. External Load Balancing
If using LoadBalancer service type:
Internet
↓
Cloud Load Balancer
↓
Kubernetes Service
↓
Pods
Example on AWS:
User → AWS ELB → Node → Pod
Final Thoughts
Kubernetes Services are the backbone of networking inside a cluster. They provide stable endpoints, service discovery, and built-in load balancing for Pods.
By using Services, Kubernetes ensures that applications can communicate reliably even when Pods change or scale dynamically.
Mastering Services will help you understand:
Kubernetes networking
Microservices communication
Cloud-native architectures
