ClusterIP Service: Internal-Only Networking
A ClusterIP service is like an unlisted phone number for your pods, providing a stable internal IP for communication *within* the cluster. Use it for backend-to-backend traffic. The footgun is assuming it's reachable from the outside—it's not.
WHY IT EXISTS: Pods in Kubernetes are ephemeral; they can be created and destroyed at any time, getting a new IP address on each restart. Applications, like a frontend needing to talk to a backend, require a stable endpoint that doesn't change. ClusterIP solves this for internal traffic.
THE MENTAL MODEL: Think of a ClusterIP service as an unlisted, internal phone number for a group of pods. It gives you a single, stable IP address that only works for calls made from inside the cluster. This IP address acts as a reliable entry point that automatically forwards requests to whichever backend pods are currently healthy and available.
HOW IT WORKS: When you create a ClusterIP service, Kubernetes assigns it a virtual IP address from a private range reserved for the cluster. The service uses a 'selector' to identify the set of pods it should send traffic to, based on their labels. A component on each node called kube-proxy watches for traffic destined for this virtual IP. It then intercepts the traffic and routes it to the actual IP of one of the healthy target pods, automatically providing simple load balancing.
WHEN TO USE IT: This is the default and most common service type. Use it for any communication between applications running inside the same Kubernetes cluster. Common scenarios include a web frontend calling a backend API, a service querying a database, or any microservice-to-microservice communication.
WHEN NOT TO USE IT: Do not use ClusterIP when you need to expose your application to traffic from outside the cluster. Its IP address is not reachable from the public internet by design. For external access, you must use a different service type like NodePort or LoadBalancer, or an Ingress object.
ONE CANONICAL EXAMPLE: A 'webapp' Deployment needs to connect to a 'database' Deployment. You create a ClusterIP service named 'db-service' that targets the database pods. The webapp's configuration uses the DNS name 'db-service' to connect. Kubernetes DNS resolves this name to the service's stable ClusterIP, ensuring the connection works reliably even if the database pods are restarted or scaled.
Read the original → kubernetes.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.