A ClusterIP Service gives an application a virtual IP address reachable from Pods inside the Kubernetes cluster. Use it when one internal component needs to call another without exposing that component publicly. section 7.1
Kubernetes tracks the Pods selected by the Service and routes requests to one of them. This provides internal load balancing while hiding changing Pod IP addresses from calling applications. section 7.1.1
Choose ClusterIP when:
- A frontend needs to call an internal backend, avatar generator, or database deployment. section 7.1.2
- Access should remain inside the cluster; the Service has no external IP. section 7.1.2
- External access is required through another design, such as NodePort or LoadBalancer, rather than direct ClusterIP access. section 7.1
Expose an internal Robohash service
Define a Service with type ClusterIP, select the Robohash Pods, and map port 80 to the container’s port 80. Other Pods can then request the assigned cluster IP, such as http://10.63.254.218/example. To test it locally, run kubectl port-forward service/robohash-internal 8080:80 and visit http://localhost:8080/example. section 7.1.2
Figure 7.1 IP routing for an internal service named Robohash. The Frontend-1 Pod makes an internal request to the service. The iptables’ routing glue on the node has a list of Pods for the Service, which is supplied by the Kubernetes control plane, and selects the Pod named Robohash-2 at random. The request is then routed to that Pod via its node.
Trace how a request from a frontend Pod reaches one selected backend Pod through node networking and the Kubernetes control plane’s Service endpoint list. section 7.1.1
