Services and Traffic Routing¶

Pods are ephemeral. Their IPs can change as they are recreated.

A Service gives clients a stable destination while Kubernetes updates backend pod endpoints behind the scenes.

How a Service Works¶

A Service typically includes:

• selector: chooses backend pods by label.
• virtual IP (ClusterIP): stable in-cluster address.
• DNS name: stable service discovery name.
• port mapping: client-facing port to container-facing target port.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

Service Types¶

1) ClusterIP (default)¶

Internal-only virtual IP for in-cluster access.

Use when workloads communicate inside the cluster.

2) NodePort¶

Exposes service on each node IP and a static port (default range 30000-32767).

Use for basic external testing or on-prem setups without a cloud load balancer.

spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080

3) LoadBalancer¶

Requests an external load balancer from your infrastructure provider (cloud or compatible on-prem implementation).

spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 8080

4) ExternalName¶

Maps a Service to an external DNS name, without pod backends.

spec:
  type: ExternalName
  externalName: db.example.com

EndpointSlices¶

Kubernetes stores service backend endpoint data in EndpointSlice objects.

This improves scalability compared to the older Endpoints object for large services.

Check backend resolution:

kubectl get svc web
kubectl get endpointslices -l kubernetes.io/service-name=web

Common Pitfalls¶

• Selector mismatch: Service has no endpoints.
• Wrong targetPort: traffic reaches pod IP but wrong container port.
• Readiness probe failures: endpoints removed because pods are not ready.

Summary Table¶

Related Concepts¶

• Networking Overview
• Ingress
• Gateway API
• Pods and Deployments