Skip to content
beginner Phase 4 · Networking

Services Deep Dive

Master Kubernetes Services: ClusterIP, NodePort, LoadBalancer, and ExternalName types.

1h 15m
0 problems
Topic Progress 0%

Service Types

Service Types

A Service gives one stable virtual IP over changing pod IPs. Four types cover the spectrum:

  • ClusterIP (default) — internal VIP reachable only inside the cluster.
  • NodePort — exposes the Service on a port on every node (default range 30000–32767), built on top of ClusterIP.
  • LoadBalancer — asks the cloud for an external load balancer; provisions a NodePort plus cloud plumbing.
  • ExternalName — a DNS CNAME to an external hostname, with no proxying at all.
spec:
  type: NodePort
  selector: { app: web }
  ports:
  - { port: 80, targetPort: 8080, nodePort: 30080 }

port is what cluster clients dial; targetPort is where the container listens.

Selectors, Endpoints, and kube-proxy

Selectors, Endpoints, and kube-proxy

When a Service has selector, the endpoints controller maintains an Endpoints (now EndpointSlice) object listing matching pod IPs and ports. kube-proxy watches it and programs rules on every node:

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

No selector means no automatic endpoints — you manage a manually named Endpoints object, which is how headless-style integrations with external databases work. Session affinity (sessionAffinity: ClientIP) pins a client to one backend via a hash, useful for legacy apps that cannot share state.

A Service without ready endpoints gets NotReadyAddresses — traffic correctly refuses them until readiness passes.

Pitfalls and Interview Angles

Pitfalls and Interview Angles

Pitfall 1 — port confusion. ClusterIP ports, nodePorts, and targetPort are three different numbers; connecting to the wrong one fails while everything looks healthy. Always state which port you are testing.

Pitfall 2 — selector mismatch. A typo in spec.selector yields an empty Endpoints list and connection timeouts with zero pod events. kubectl get endpoints is the first command, not kubectl get pods.

Interview-ready: explain the packet path — client → Service VIP → kube-proxy rule → pod IP:targetPort — distinguish ExternalName (pure DNS) from the rest, and describe headless Services (clusterIP: None) which return pod IPs directly for stateful discovery.

Quiz

1. Which Service type provisions a cloud load balancer?

Question 1 options

2. What does a Service with clusterIP: None return from DNS?

Question 2 options

3. A Service shows no endpoints although pods are Running. First check?

Question 3 options

Flashcards

Question

Service types

Answer

ClusterIP (internal), NodePort (node-level port), LoadBalancer (cloud LB), ExternalName (DNS CNAME).

Question

port vs targetPort vs nodePort

Answer

port = Service port, targetPort = container port, nodePort = external node port (30000–32767).

Question

Who maintains endpoints

Answer

The endpoints controller updates EndpointSlices from ready pods matching the selector.

Question

sessionAffinity: ClientIP

Answer

Hashes client IPs to pin a client to one backend — a workaround, not real load balancing.

Revision Notes

Key Takeaways

  • 1. Services decouple a stable VIP from ephemeral pod IPs
  • 2. Endpoints/Slices are the bridge between Services and pods
  • 3. Debug order: get endpoints first, then kube-proxy rules

Interview Tips

  • • Describe the full packet path from Service VIP to pod
  • • Explain when headless beats a normal Service (stateful discovery, DNS-based balancing)

Cheat Sheet

Types: ClusterIP/NodePort/LoadBalancer/ExternalName. selector → EndpointSlice → kube-proxy rules. Empty endpoints = selector or readiness problem. Headless = pod DNS.

Continue Learning