ClusterIP service type in Kubernetes - Step-by-Step Execution

Process Flow - ClusterIP service type

Create Service YAML

↓

kubectl apply -f service.yaml

↓

Kubernetes API Server receives request

↓

Service object created with ClusterIP

↓

Kube-proxy configures iptables rules

↓

Pods selected by label receive traffic

↓

ClusterIP accessible only inside cluster

This flow shows how a ClusterIP service is created and how it routes traffic inside the Kubernetes cluster.

Execution Sample

Kubernetes

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080

Defines a ClusterIP service named 'my-service' that routes port 80 to pods with label app=my-app on port 8080.

Process Table

Step	Action	Resource State	Result
1	Create service YAML file	No service exists	YAML file ready for apply
2	Run kubectl apply -f service.yaml	Service object created	ClusterIP assigned (e.g. 10.96.0.1)
3	Kube-proxy updates iptables	iptables rules updated	Traffic to ClusterIP routes to pods
4	Pod with label app=my-app receives traffic	Pod ready	Pod serves requests on port 8080
5	Access service from inside cluster	ClusterIP reachable	Traffic routed to pods successfully
6	Access service from outside cluster	ClusterIP not reachable	Connection refused or timeout

💡 ClusterIP service only routes traffic inside the cluster; external access is blocked.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 5	Final
Service Object	None	Created with ClusterIP	Configured in iptables	Active and routable	Active and routable
ClusterIP Address	None	10.96.0.1 (example)	Used in routing rules	Accessible inside cluster	Not accessible outside cluster
Pods with label app=my-app	Running	Running	Ready to receive traffic	Serving traffic	Serving traffic

Key Moments - 3 Insights

Why can't I access the ClusterIP service from outside the cluster?

ClusterIP services are designed to be reachable only inside the cluster network. As shown in execution_table step 6, external access is blocked by design.

How does traffic get routed to the correct pods?

Kube-proxy updates iptables rules (step 3) to route traffic sent to the ClusterIP to pods selected by the service's label selector.

What happens if no pods match the service selector?

The service will have no endpoints to route to, so traffic to the ClusterIP will fail or be dropped, even though the service object exists.

Visual Quiz - 3 Questions

Look at the execution_table, at which step is the ClusterIP assigned to the service?

A Step 4

B Step 2

C Step 3

D Step 5

💡 Hint

Check the 'Resource State' column in step 2 where the service object is created with ClusterIP.

According to variable_tracker, what is the state of the pods after step 3?

A Pods are ready to receive traffic

B Pods are not running

C Pods are deleted

D Pods are unreachable

💡 Hint

Look at the 'Pods with label app=my-app' row under 'After Step 3' column.

If you want the service to be accessible outside the cluster, what must change?

A Keep service type as ClusterIP and add more pods

B Change pod labels

C Change service type from ClusterIP to NodePort or LoadBalancer

D Nothing, ClusterIP allows external access by default

💡 Hint

Refer to the exit_note and step 6 in execution_table about external access.

Concept Snapshot

ClusterIP Service Type in Kubernetes:
- Default service type for internal cluster access
- Assigns a stable internal IP (ClusterIP)
- Routes traffic to pods matching selector
- Not reachable from outside the cluster
- Used for internal communication between pods and services

Full Transcript

This visual execution shows how a Kubernetes ClusterIP service is created and functions. First, a YAML file defines the service with type ClusterIP and a selector for pods. Applying this YAML creates the service object and assigns a ClusterIP address. Kube-proxy then updates iptables rules to route traffic sent to this ClusterIP to the selected pods. Pods matching the label selector receive the traffic on the target port. The service is accessible only inside the cluster network; attempts to access it externally fail. Variables like the service object, ClusterIP address, and pod states change step-by-step as shown. Key points include understanding that ClusterIP is internal-only and routing depends on label selectors. The quiz tests knowledge of when ClusterIP is assigned, pod readiness, and how to enable external access.