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?
2. What does a Service with clusterIP: None return from DNS?
3. A Service shows no endpoints although pods are Running. First check?
Flashcards
Question
Service types
Click to reveal answer
Answer
ClusterIP (internal), NodePort (node-level port), LoadBalancer (cloud LB), ExternalName (DNS CNAME).
Question
port vs targetPort vs nodePort
Click to reveal answer
Answer
port = Service port, targetPort = container port, nodePort = external node port (30000–32767).
Question
Who maintains endpoints
Click to reveal answer
Answer
The endpoints controller updates EndpointSlices from ready pods matching the selector.
Question
sessionAffinity: ClientIP
Click to reveal answer
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.