> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Services Cluster IP
> 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 manifests
Below 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):
```yaml theme={null}
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
type: back-end
spec:
containers:
- name: nginx-container
image: nginx
ports:
- containerPort: 80
```
Service manifest (back-end-service.yaml):
```yaml theme={null}
apiVersion: v1
kind: Service
metadata:
name: back-end
spec:
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:
```bash theme={null}
kubectl apply -f myapp-pod.yaml
kubectl apply -f back-end-service.yaml
kubectl get pods
kubectl get services
kubectl describe service back-end
```
Testing access from another Pod
Other 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:
```bash theme={null}
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.
Links and references
* [Kubernetes Services documentation](https://kubernetes.io/docs/concepts/services-networking/service/)
* [kube-proxy overview](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)
* [DNS for Services and Pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.