A full-stack web application architecture on Kubernetes consists of distinct tiers, each typically encapsulated in sets of pods. These tiers include front-end web servers, back-end application servers, in-memory data stores like Redis, and persistent databases like MySQL. Seamless communication between these layers is critical for application functionality. The front-end requires connectivity to the back-end, and the back-end must interact with both the caching and database layers.

Establishing reliable connectivity between these tiers presents a challenge due to the ephemeral nature of pods. While every pod receives an IP address from the cluster’s CIDR range (e.g., 10.244.0.3), these IPs are dynamic. Pods are mortal; they can be terminated, evicted, or replaced by new replicas during scaling operations or updates. Consequently, relying on individual Pod IPs for inter-service communication creates a fragile architecture where connection strings break upon any lifecycle event. Furthermore, with multiple replicas of a single service (e.g., three backend pods), a client requires a mechanism to select a specific target and balance the load across them.

The Kubernetes Service object solves this by abstracting pod networking. A Service defines a logical set of pods and a policy to access them. It groups pods using labels and selectors, presenting a single stable entry point—a Virtual IP (VIP)—for the group. For instance, a Service named “backend-service” selects all pods labeled app: backend. When a front-end pod sends a request to this Service, the request is load-balanced and forwarded to one of the healthy backend pods. This abstraction enables loose coupling; the backend layer can scale up, down, or crash, and the Service continuously updates its routing table to point to available endpoints, leaving the client configuration untouched.

This specific type of Service is known as ClusterIP. It is the default Service type in Kubernetes. A ClusterIP Service allocates a stable IP address and a DNS name resolvable only from within the cluster. This ensures internal microservices can communicate securely without exposing endpoints to the external internet.

To implement a ClusterIP Service, define a manifest using the standard Kubernetes API structure:

YAML Structure:

1. apiVersion: v1 (The core API group for Services).
2. kind: Service.
3. metadata: Defines the Service name (e.g., backend-service) and namespace. This name forms the basis of the cluster’s internal DNS record.
4. spec: Contains the configuration.

Port Definitions: Under spec.ports, you define the mapping:

• port: The port exposed by the Service itself. Clients connect to this port on the Service IP.
• targetPort: The port on the Pod where the application is listening. This must match the containerPort defined in the Pod template. The Service proxies traffic from port to targetPort.
• (Optional) protocol: Defaults to TCP.

Selectors: Under spec.selector, you map the Service to the Pods. The key-value pairs defined here must match the labels assigned to the Pods (e.g., app: backend, tier: api). The Kubernetes control plane continuously scans for pods matching these labels and updates the Service’s Endpoints object.

DNS Resolution: Once created, the Service becomes discoverable via the cluster’s DNS server (CoreDNS). Other pods can reach the backend using the Service name (backend-service) or its Fully Qualified Domain Name (FQDN): backend-service.default.svc.cluster.local. The DNS resolves to the ClusterIP, and kube-proxy handles the routing rules (typically via iptables or IPVS) to forward traffic to a random backing Pod IP.

Sample Application:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

apiVersion: v1
kind: Service
metadata:
  name: backend-service
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: backend
    tier: api
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 8080

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-deployment
  labels:
    app: backend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: backend
      tier: api
  template:
    metadata:
      labels:
        app: backend
        tier: api
    spec:
      containers:
      - name: backend-container
        image: nginx
        ports:
        - containerPort: 8080

Cluster vs ClusterIP

In Kubernetes, we have a cluster. Is this clusterIP is different from the actual cluster ?

The Kubernetes Cluster This is the infrastructure layer. It comprises a set of worker nodes (machines) and a control plane. The cluster itself does not have a single “Cluster IP.” Instead, each node in the cluster possesses its own physical IP address on the underlying network.

ClusterIP (The Service Type) This is a Virtual IP address assigned to a Service object within the cluster’s internal network. It functions strictly as a logical abstraction used for routing traffic to specific application pods.

The distinction is:

• ClusterIP = An address inside the cluster used by applications.
• The Cluster = The physical or virtual infrastructure hosting the nodes.

“ClusterIP” does not represent the IP address of the Kubernetes cluster itself; it represents the IP address of a specific application Service accessible from within that cluster.