The Problem Services Solve
Pods are ephemeral -- they get new IP addresses every time they are recreated. Applications cannot reliably talk to individual Pod IPs. A Kubernetes Service provides a stable virtual IP and DNS name that load-balances traffic across a dynamic set of Pods selected by labels, so consumers never need to track Pod churn.
Cricket analogy: Like fans following a franchise's name and jersey number rather than tracking which specific player wears it season to season, a Kubernetes Service gives a stable virtual IP and DNS name that abstracts away which Pods currently back it.
ClusterIP: Internal-Only Access
ClusterIP is the default Service type. It exposes the Service on an internal, cluster-only virtual IP that is reachable from any Pod in the cluster, typically via DNS at <service-name>.<namespace>.svc.cluster.local. It is the right choice for backend services that should never be reachable from outside the cluster.
Cricket analogy: Like an internal team-only training ground that outside spectators can never enter, but any player on the squad can use it, ClusterIP exposes a Service only inside the cluster, reachable via internal DNS, never externally.
apiVersion: v1
kind: Service
metadata:
name: backend
spec:
type: ClusterIP
selector:
app: backend
ports:
- name: http
port: 80
targetPort: 8080
protocol: TCPNodePort: Exposing a Static Port on Every Node
A NodePort Service allocates a port in the 30000-32767 range on every node and forwards traffic from that port to the Service, which then load-balances to matching Pods. It is mainly used for development, on-prem clusters without a cloud load balancer, or as the underlying mechanism for Ingress controllers.
Cricket analogy: Like a stadium reserving a fixed gate number that any fan can use to eventually reach their seat, even though the exact usher on duty changes, a NodePort opens a fixed port on every node that forwards to the Service.
apiVersion: v1
kind: Service
metadata:
name: web-nodeport
spec:
type: NodePort
selector:
app: web
ports:
- port: 80
targetPort: 8080
nodePort: 30080LoadBalancer: Cloud-Provisioned External Access
On a supported cloud provider, a LoadBalancer Service provisions an external load balancer (for example an AWS NLB or GCP Load Balancer) that routes to the Service, which in turn routes to NodePort and then to Pods. It builds on top of NodePort and ClusterIP rather than replacing them.
Cricket analogy: Like a stadium hiring a dedicated external ticketing agency that routes fans through the regular gate system rather than replacing it, a LoadBalancer Service provisions an external load balancer that routes through NodePort and ClusterIP.
apiVersion: v1
kind: Service
metadata:
name: web-lb
spec:
type: LoadBalancer
selector:
app: web
ports:
- port: 80
targetPort: 8080Setting clusterIP: None creates a headless Service. Instead of a single virtual IP, DNS returns the individual Pod IPs directly, which is essential for StatefulSets where clients need to address specific Pod replicas by stable hostname. Under the hood, kube-proxy implements Service load balancing on each node, usually via iptables or IPVS rules that redirect virtual-IP traffic to the healthy backend Pod IPs tracked by the EndpointSlice objects.
Cricket analogy: Like a scorer's directory listing every individual player's personal contact rather than just the team hotline, so a specific player can always be reached directly, a headless Service returns individual Pod IPs instead of one virtual IP.
A Service only routes to Pods whose readiness probe is currently passing. A Pod that is Running but not Ready is silently excluded from the Endpoints/EndpointSlice, which is a common source of confusing 'why is my Pod not getting traffic' bugs.
- ClusterIP (default) is internal-only; NodePort exposes a port on every node; LoadBalancer provisions an external cloud load balancer.
- Services select Pods via label selectors, not by Pod name -- keep labels consistent between Deployments and Services.
- kube-proxy programs iptables/IPVS rules based on EndpointSlices to implement Service load balancing.
- Headless Services (clusterIP: None) return individual Pod IPs, used heavily by StatefulSets.
- Only Ready Pods receive traffic through a Service.
- Ingress operates at Layer 7 (HTTP/HTTPS) and typically routes to ClusterIP Services, not replacing them.
Practice what you learned
1. Which Service type is the default and only reachable from inside the cluster?
2. What underlying mechanism does a LoadBalancer Service build on top of?
3. How does a Service determine which Pods to send traffic to?
4. What is a headless Service used for?
5. Why might a healthy-looking Pod receive no traffic from its Service?
Was this page helpful?
You May Also Like
Ingress Controllers
Learn how Ingress resources and Ingress controllers expose HTTP/HTTPS routing, host- and path-based rules, and TLS termination for cluster Services.
Pods Explained
An explanation of Pods, the smallest deployable unit in Kubernetes, covering their structure, lifecycle, and a minimal manifest example.
Container Networking Basics
Understand Docker's default bridge network, port publishing, and how containers discover and communicate with each other on user-defined networks.
Kubernetes Architecture
A tour of Kubernetes cluster architecture, covering control plane components and worker node components and how they interact.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsCI/CD Tools & Pipelines Study Notes
YAML · 37 topics