intermediate

Service

Expose stable virtual networking and load balancing for changing pod sets selected by labels.

A Service provides stable virtual networking for a changing set of pods selected by labels. Clients call the Service DNS name instead of pod IPs.

| Type | Typical use | |------|-------------| | ClusterIP | Internal app-to-app traffic (default) | | NodePort | Expose on each node port (dev/legacy) | | LoadBalancer | Cloud LB in front of pods | | Headless | Direct pod DNS for stateful sets |

					apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - port: 80
      targetPort: 3000

Ingress usually routes external HTTP to Services — not directly to pod IPs.

On interviews: service types, selectors, `port` vs `targetPort`, headless services, and relationship to Ingress.

Common pitfalls: wrong selector silently points to zero or wrong pods; exposing every service with LoadBalancer.

The trade-off is simple exposure (LoadBalancer everywhere) versus least-privilege networking.

Checklist:

Match selectors carefully.
Choose service type by exposure need.
Route HTTP through Ingress when appropriate.
Verify endpoints with `kubectl get endpoints`.