Services Cluster IP

In this lesson we’ll cover the Kubernetes Service of type ClusterIP and why it’s essential for stable in-cluster communication. A full-stack application typically runs multiple sets of pods for different parts of the system: front-end web servers, back-end servers, an in-memory cache like Redis, and a persistent database such as MySQL. Each pod receives an IP, but pod IPs are ephemeral — pods can be terminated and recreated at any time. Relying on individual pod IPs for long-term communication is fragile. Consider a front-end pod at 10.244.0.3 that needs to call the back-end. Which back-end pod should it target? Who decides? Kubernetes Services solve this by grouping a set of pods and exposing a stable interface (a ClusterIP and DNS name) that other pods use to reach that group reliably.

A "ClusterIP" architecture diagram showing three tiers (front-end, back-end, redis) with multiple Kubernetes pods (each labeled "Pod" and given IPs like 10.244.0.x). Colored service bars and dotted arrows illustrate traffic routing between the pods/services.

A Service for the backend groups all backend pods and exposes a single, stable address. Requests to the Service are load-balanced across the matching pods (the Service endpoints) by kube-proxy (the load balancing algorithm depends on kube-proxy’s mode). Create Services for Redis, databases, and other components; other pods access those components using the Service name or its ClusterIP. This enables microservices to scale, move, or be replaced without breaking internal communication: each Service gets a stable cluster-internal IP (the ClusterIP) and a DNS name. That is the ClusterIP Service type.

ClusterIP is the default Service type and is only reachable from within the cluster. You can omit type: ClusterIP in the Service manifest because Kubernetes will use it by default.

ClusterIP Service manifest (example)

A minimal Service manifest contains apiVersion, kind, metadata, and spec. Under spec you declare the ports mapping and a selector that matches pod labels. Example Service manifest (service.yaml):

apiVersion: v1
kind: Service
metadata:
  name: back-end
spec:
  type: ClusterIP          # optional; ClusterIP is the default
  ports:
    - port: 80             # port exposed by the Service inside the cluster
      targetPort: 80       # port on the pod/container
  selector:
    app: myapp
    type: back-end

Make sure the pods you want the Service to route to have matching labels. Example Pod manifest (pod.yaml):

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: back-end
spec:
  containers:
    - name: nginx-container
      image: nginx
      ports:
        - containerPort: 80

Apply and verify

Create the pod and service, then confirm their status:

kubectl apply -f pod.yaml
kubectl apply -f service.yaml

kubectl get services
kubectl describe service back-end

From any pod in the same namespace you can reach the back-end Service using the short name back-end. If you need the fully qualified domain name, use back-end.<namespace>.svc.cluster.local (for the default namespace this becomes back-end.default.svc.cluster.local).

Service manifest fields (at a glance)

Field	Purpose	Example
`spec.type`	Service type defining exposure (ClusterIP, NodePort, LoadBalancer)	`ClusterIP`
`spec.ports.port`	Port the Service exposes inside the cluster	`80`
`spec.ports.targetPort`	Port on the pod/container that receives traffic	`80`
`spec.selector`	Label selector to choose pods that back the Service	`app: myapp`, `type: back-end`

How traffic gets to pods

The Service defines a stable ClusterIP and DNS name.
kube-proxy configures networking rules on nodes so traffic sent to the Service is redirected to one of the endpoints (matching pods).
kube-proxy handles load distribution; the specific algorithm depends on kube-proxy’s mode (iptables, ipvs, or userspace).

Key takeaways

Services provide a stable network endpoint for a group of pods selected by labels.
ClusterIP is the default Service type and is accessible only from within the cluster.
Use the Service DNS name or ClusterIP to reach a set of pods instead of individual pod IPs.
kube-proxy is responsible for forwarding and load-balancing Service traffic to pod endpoints.

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Services Cluster IP

ClusterIP Service manifest (example)

Apply and verify

Service manifest fields (at a glance)

How traffic gets to pods

Key takeaways

Links and references

Watch Video

​ClusterIP Service manifest (example)

​Apply and verify

​Service manifest fields (at a glance)

​How traffic gets to pods

​Key takeaways

​Links and references

Watch Video

ClusterIP Service manifest (example)

Apply and verify

Service manifest fields (at a glance)

How traffic gets to pods

Key takeaways

Links and references