Myth 2: ClusterIP Service is Only for Internal Traffic

You’ve just configured a ClusterIP service to expose one of your pods internally in your Kubernetes cluster. It seems like a straightforward setup—after all, ClusterIP services are meant to route traffic between pods within the cluster, right? So, you assume that it’s all about internal communication.

But then, you decide to test it a bit more. You try accessing the service using a curl command from a different pod within the same cluster and… it works perfectly. That’s expected, right? You start thinking that ClusterIP is only for internal use. But curiosity leads you to try something else—accessing the service from outside the cluster.

To your surprise, it works! You use a load balancer or a proxy to access the service, and your request is successfully routed to the ClusterIP service. Wait—how can this be? ClusterIP should only be for internal traffic, right?

Why This Myth Exists?

1. Kubernetes documentation emphasizes ClusterIP as an "internal" service type, leading people to overlook its role in external communication.
2. NodePort and LoadBalancer are explicitly designed for external access, making it seem like ClusterIP plays no role in exposing services.
3. Developers often misunderstand how Kubernetes routes traffic, missing the fact that external service types still forward traffic through ClusterIP.

The Reality

Yes, a pure ClusterIP service is internal, but every Kubernetes service—whether NodePort or LoadBalancer—relies on ClusterIP behind the scenes. Even when traffic comes from outside the cluster, it still flows through ClusterIP before reaching the pods.

Experiment & Validate

Step 1: Create a LoadBalancer Service Apply the following YAML to create a LoadBalancer service:

apiVersion: v1
kind: Service
metadata:
  name: my-loadbalancer-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

Step 2: Verify the Created Service Run the following command to check the details of the service:

kubectl get svc my-loadbalancer-service -o wide

Expected Output:

NAME                      TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)       AGE
my-loadbalancer-service   LoadBalancer   10.96.0.150  <pending>     80:32000/TCP  5s

Notice the CLUSTER-IP field—Kubernetes has automatically assigned a ClusterIP to the LoadBalancer service.

Step 3: Confirm That ClusterIP Exists Even though the service is a LoadBalancer, it still functions like a ClusterIP service inside the cluster. You can verify this by running:

kubectl get endpoints my-loadbalancer-service

Expected Output:

NAME                      ENDPOINTS           AGE
my-loadbalancer-service   192.168.1.100:8080  5s

This proves that traffic is routed through the ClusterIP before reaching the pods.

Key Takeaways

• ClusterIP is not just for internal traffic; it is essential for external services like NodePort and LoadBalancer.
• Every Kubernetes service type ultimately forwards traffic through ClusterIP before reaching the pods.
• Misunderstanding ClusterIP’s role can lead to unnecessary service type changes and wasted troubleshooting efforts.