Kubernetes ClusterIP Services - Internal Service Discovery & Communication Guide

Comprehensive guide to Kubernetes ClusterIP Services covering internal service discovery, kubectl commands, YAML configuration, port mapping, and microservices communication patterns

What is ClusterIP?

ClusterIP is the default Kubernetes Service type that provides internal communication between application components within the cluster. It exposes the service on a cluster-internal IP address, making it only accessible from within the cluster.

ClusterIP Service
port: 80
→
Pod
targetPort: 8080
Pod
targetPort: 8080
Pod
targetPort: 8080

Cluster Internal

Only accessible from within the Kubernetes cluster, not from outside

Load Balanced

Automatically distributes traffic using round-robin algorithm

Secure & Isolated

Provides secure internal networking between microservices

Default Service Type: When you create a Service without specifying a type, Kubernetes automatically creates it as a ClusterIP service.

kubectl Commands for ClusterIP

Expose a Pod

kubectl expose po [podName] --port=80 \
  --target-port=8080 --name=frontend

Create a service to expose a pod

Expose a Deployment

kubectl expose deploy [deployName] \
  --port=80 --target-port=8080

Create a service to expose a deployment

Apply from YAML

kubectl apply -f [definition.yaml]

Deploy the service from configuration file

List Services

kubectl get svc
kubectl get svc -o wide

Get the services list with basic or extended info

Service Details

kubectl describe svc [serviceName]

Describe the service configuration and endpoints

Delete Service

kubectl delete -f [definition.yaml]
kubectl delete svc [serviceName]

Delete the service using YAML file or service name

ClusterIP Configuration

Service Definition

apiVersion: v1
kind: Service
metadata:
  name: svc-example
spec:
  type: ClusterIP  # Optional - this is default
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: app-example
    env: prod

Key Configuration Elements

  • port: The port the service listens on (80)
  • targetPort: The port the pods are listening on (8080)
  • selector: Labels to identify target pods
  • type: ClusterIP (default, can be omitted)

Port Configuration Explained

Service Port

The port that the service exposes internally within the cluster. Other services communicate with this service using this port.

port: 80

Target Port

The port on the pod containers that the service forwards traffic to. This is where your application is actually listening.

targetPort: 8080

Node Port

Not used in ClusterIP services. Only relevant for NodePort service type for external access.

# Not applicable for ClusterIP

Advanced Configuration

apiVersion: v1
kind: Service
metadata:
  name: advanced-service
  namespace: production
  labels:
    app: web-application
    tier: backend
spec:
  type: ClusterIP
  selector:
    app: web-api
    version: "2.1"
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 8080
  - name: metrics
    protocol: TCP
    port: 9090
    targetPort: 9090
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 10800

Session Affinity

Configurable to stick client connections to the same pod. Useful for stateful applications.

Multiple Ports

Services can expose multiple ports for different protocols or endpoints.

When to Use ClusterIP

Ideal Use Cases

  • Microservices Communication

    Internal communication between backend services in a microservices architecture

  • Database Access

    Providing stable access to database pods from application pods

  • Internal APIs

    Exposing internal APIs that shouldn't be accessible from outside the cluster

  • Cache Services

    Redis, Memcached, or other caching services used internally

  • Message Queues

    RabbitMQ, Kafka, or other message brokers for internal communication

Architecture Example

Frontend Service (LoadBalancer)
↓
Backend API (ClusterIP)
↓
Database (ClusterIP)
Cache (ClusterIP)

Load Balancing

ClusterIP services automatically load balance traffic using round-robin algorithm across all matching pods.

# Traffic distributed: Pod1 → Pod2 → Pod3 → Pod1...

Benefits

  • Secure internal communication
  • Automatic service discovery
  • Load balancing out of the box
  • Stable network identity
  • No external exposure

Limitations

  • Not accessible from outside cluster
  • Requires Ingress or LoadBalancer for external access
  • Limited to cluster network scope

Best Practices for ClusterIP

Naming & Organization

  • Use descriptive names that reflect the service purpose
  • Include environment in labels, not service names
  • Use consistent port numbering across environments
  • Organize services using namespaces
  • Document service dependencies and endpoints

Configuration & Security

  • Use Network Policies to restrict service access
  • Configure appropriate session affinity if needed
  • Use named ports for better readability
  • Monitor service endpoints and health
  • Implement proper readiness and liveness probes

Example: Complete Microservice Setup

# Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
      version: v1
  template:
    metadata:
      labels:
        app: user-service
        version: v1
    spec:
      containers:
      - name: user-api
        image: user-service:v1.2.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080

---

# Service
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - port: 80
    targetPort: 8080