Why Kubernetes Services exist
Grasp of Pod IP instability.
Pod IPs are ephemeral and change on reschedule; a Service gives a stable virtual IP and DNS name plus load balancing across healthy Pods via label selectors.
What's really being asked
The foundational reason the Service abstraction exists: Pods are cattle, not pets, and their IPs are unstable.
The full answer
Every Pod gets its own IP, but that IP is tied to that specific Pod instance. When a Pod crashes, is rescheduled to another node, is replaced during a rolling update, or scales up and down, it gets a new IP. Any client that hard-coded the old IP breaks. A Service solves this by providing a stable, long-lived virtual IP (the ClusterIP) and a DNS name that do not change as the backing Pods churn. The Service uses a label selector to dynamically discover the current set of matching, healthy Pods and load-balances incoming connections across them.
The mistakes people make
Asserting Pod IPs are stable; they are not across restarts or rescheduling. Treating Services as only for external exposure, when the most common type, ClusterIP, is for internal traffic. Ignoring load balancing as a benefit.
What usually comes next
How does the Service know which Pods to route to? Through the selector, which the endpoints controller turns into an EndpointSlice of ready Pod IPs. What provides the stable DNS name? CoreDNS resolving the Service name. How is traffic actually routed? kube-proxy programs iptables or IPVS rules.
A concrete example
A frontend talks to a backend Deployment of three Pods. Instead of tracking three ever-changing Pod IPs, the frontend connects to the backend Service by name. When a backend Pod is replaced and gets a new IP, the Service automatically updates its endpoints, and the frontend keeps working with no config change.
Interview question
What core problem with using raw Pod IPs does a Kubernetes Service solve?
- a.Pod IPs cannot carry HTTPS traffic
- b.Pod IPs are too long to remember
- c.Pod IPs are only routable from outside the cluster
- d.Pod IPs are ephemeral and change when Pods are rescheduled, so a Service gives a stable addressCorrect
Why? this is the answer
Pods get new IPs when replaced or rescheduled, so a Service provides a stable virtual IP and DNS plus load balancing. Pod IPs are internally routable and protocol-agnostic; length is irrelevant.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #services
- #networking
- #clusterip
- #load-balancing
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles