Introduction

Kubernetes supports several types of Services. The default type is ClusterIP.

A ClusterIP Service has a stable IP address and port that is only accessible from inside the cluster. It’s programmed into the network fabric and guaranteed to be stable for the life of the Service. Programmed into the network fabric is a fancy way of saying the network just knows about it, and you don’t need to bother with the details (stuff like low-level IPTABLES and IPVS rules).

Anyway, the ClusterIP gets registered against the name of the Service on the cluster’s internal DNS service. All Pods in the cluster are pre programmed to know about the cluster’s DNS service, meaning all Pods are able to resolve Service names.

Example of ClusterIP

Let’s look at a simple example.

Creating a new Service called “magic-sandbox” will trigger the following. Kubernetes will register the name “magic-sandbox”, along with the ClusterIP and port, with the cluster’s DNS service. The name, ClusterIP, and port are guaranteed to be long-lived and stable, and all Pods in the cluster send service discovery requests to the internal DNS and will, therefore, be able to resolve “magic-sandbox” to the ClusterIP. IPTABLES or IPVS rules are distributed across the cluster that ensure traffic sent to the ClusterIP gets routed to Pods on the backend.

Net result: as long as a Pod (application microservice) knows the name of a Service, it can resolve that to its ClusterIP address and connect to the desired Pods.

This only works for Pods and other objects on the cluster, as it requires access to the cluster’s DNS service. It does not work outside of the cluster.