Kubernetes Services explained: ClusterIP, NodePort, LoadBalancer and more

Pods are ephemeral. Every time a pod is rescheduled, it gets a new IP address. If your frontend needs to connect to your backend, it cannot rely on a pod IP that changes unpredictably.

A Service solves this by providing a stable network endpoint. It uses a label selector to find the right pods and load-balances traffic across them. When pods are created, updated, or deleted, the Service automatically updates its endpoint list. You configure once and the Service handles the rest.

Service types at a glance

Why Services exist: a practical example

Without a Service, you access a pod by port-forwarding directly to it:

1kubectl create namespace example
2kubectl get nodes
3kubectl port-forward pod/my-pod -n example 8080:8080

Port-forwarding works for local development but is not a production solution. It is tied to a specific pod, breaks when the pod is rescheduled, and requires you to know the pod name. A Service abstracts this entirely.

Check all resources in the namespace:

1kubectl get all -n example

Once a Service is applied, other pods can reach your application at service-name.namespace.svc.cluster.local regardless of which pods are currently running or where they are scheduled.

ClusterIP

ClusterIP is the default Service type. It creates a stable virtual IP that is only reachable from within the cluster. Use it for all internal service-to-service communication.

1apiVersion: v1
2kind: Service
3metadata:
4  name: backend
5spec:
6  type: ClusterIP
7  selector:
8    app: backend
9  ports:
10  - port: 80
11    targetPort: 8080

For the full guide, see Kubernetes ClusterIP service explained.

NodePort

NodePort exposes your Service on a port between 30000 and 32767 on every node in the cluster. External traffic arriving at <NodeIP>:<NodePort> is routed to the correct pods.

1apiVersion: v1
2kind: Service
3metadata:
4  name: frontend
5spec:
6  type: NodePort
7  selector:
8    app: frontend
9  ports:
10  - port: 80
11    targetPort: 3000
12    nodePort: 31520

For the full guide, see Kubernetes NodePort.

LoadBalancer

LoadBalancer requests a cloud-provisioned load balancer with a single external IP. On Civo, the external IP is available within seconds.

1apiVersion: v1
2kind: Service
3metadata:
4  name: frontend
5spec:
6  type: LoadBalancer
7  selector:
8    app: frontend
9  ports:
10  - port: 80
11    targetPort: 3000

For the full guide, see Kubernetes LoadBalancer service.

Headless Service

A Headless Service sets clusterIP: None. Instead of a virtual IP, Kubernetes creates individual DNS A records for each pod backing the Service. This allows you to address specific pods directly by DNS name.

1apiVersion: v1
2kind: Service
3metadata:
4  name: database
5spec:
6  clusterIP: None
7  selector:
8    app: database
9  ports:
10  - port: 5432

With this Service, the pods are addressable as database-0.database.default.svc.cluster.local, database-1.database.default.svc.cluster.local, and so on. This is the mechanism StatefulSets use to give each pod a stable DNS identity. See Kubernetes StatefulSets for a working example.

Which service type should I use?

• Internal communication between services: ClusterIP. This covers the vast majority of service-to-service traffic inside a cluster.
• External access for testing or bare metal: NodePort. No cloud provider required. You manage the node IP and port yourself.
• Production external access on cloud infrastructure: LoadBalancer for TCP/UDP services, or an Ingress controller in front of a ClusterIP Service for HTTP/HTTPS. An Ingress gives you TLS termination, hostname routing, and path routing that a bare LoadBalancer does not provide.
• Direct pod addressing for StatefulSets: Headless Service. Databases, message queues, and any workload where individual pod identity matters.