Explains Kubernetes ClusterIP Services that provide stable internal IP and DNS names to group Pods and enable reliable in-cluster communication and load balancing.
In this article we explain the Kubernetes Service type ClusterIP and how it provides stable, internal connectivity between sets of Pods.A typical full-stack application runs multiple Pod groups for different responsibilities: front-end web servers, back-end application servers, an in-memory cache like Redis, and a persistent database such as MySQL. These components must communicate reliably—e.g., the front-end needs the back-end, and the back-end needs Redis and the database.Pod IPs are ephemeral: Pods can be terminated and recreated at any time. That makes Pod IPs unsuitable for stable, long-lived addressing inside a cluster. If a front-end Pod at 10.244.0.3 needs to contact a back-end, which back-end Pod should it use? Who makes that routing decision?A Kubernetes Service solves this by providing a stable network identity (an IP and DNS name) and by grouping a set of Pods (selected by labels) behind that identity. Requests to a Service are forwarded to one of its backing Pods (the Service’s endpoints). The cluster’s Service proxy (kube-proxy or the chosen implementation) performs the forwarding and basic load balancing from the Service IP to Pod endpoints.
For example, creating a Service for back-end Pods groups those Pods behind a single Service name and ClusterIP. Front-end Pods and other components use that Service name (or ClusterIP) to reach any of the back-end Pods. Similarly, you can create separate Services for Redis or a database so clients always use the Service DNS name instead of individual Pod IPs.This decouples clients from Pod lifecycle: layers can scale or move without breaking internal communication. Each Service receives a cluster IP and a DNS name (the Service name), and other Pods should use that Service name (or ClusterIP) to access the service.
ClusterIP is the default Service type. If you omit type in a Service manifest Kubernetes creates a ClusterIP Service.
Example manifestsBelow are minimal manifests for a Pod and a ClusterIP Service that targets that Pod. Note that the Service selector must match labels on the Pod to associate endpoints with the Service.Pod manifest (myapp-pod.yaml):
apiVersion: v1kind: Servicemetadata: name: back-endspec: type: ClusterIP # optional, ClusterIP is the default ports: - port: 80 # Service port targetPort: 80 # Pod/container port protocol: TCP selector: app: myapp type: back-end
Apply and inspect the resources:
kubectl apply -f myapp-pod.yamlkubectl apply -f back-end-service.yamlkubectl get podskubectl get serviceskubectl describe service back-end
Testing access from another PodOther Pods in the same namespace can access the Service using its DNS name or ClusterIP. A quick way to test connectivity is to run an ephemeral Pod with curl:
kubectl run curl-test --image=curlimages/curl -it --rm --restart=Never -- sh# Inside the ephemeral shell:curl http://back-end:80
ClusterIP Services are reachable only from within the cluster. They are not accessible from outside the cluster unless you expose them with a NodePort, LoadBalancer, or an Ingress.
Key Service fields
Field
Purpose
Example
type
Service type (how it is exposed). Default: ClusterIP.
ClusterIP
ports
Service listening port and the targetPort on Pods.
port: 80, targetPort: 80
selector
Labels that match Pods to form the Service endpoints.
app: myapp, type: back-end
Service DNS
Stable name for discovery inside the namespace.
back-end.default.svc.cluster.local
Summary
Use a Service with a matching selector to group Pods and provide a stable name and ClusterIP.
ClusterIP is the default Service type, intended for internal cluster communication.
kube-proxy (or the cluster’s service proxy) routes and load-balances traffic from the Service IP to Pod endpoints.
To expose a Service outside the cluster, use NodePort, LoadBalancer, or an Ingress.
