Why Services?
Could Kubernetes have been built with only Pods and Deployments? What do load balancers and DNS have to do with it?
Why do we need Services in Kubernetes? Let’s start with some history.
Static servers vs dynamic containers
Once upon a time, applications were deployed directly on servers, and those servers had personal names.
Those days are long gone.
These days, applications have many instances, all identical to one another. You don’t scale up your app by running it on a bigger server. Rather, you scale out your app by making more copies of it.
On Kubernetes, those copies of your application are Pods.
But when a user browses to your website, how do they end up speaking to the right pod? Some pods are starting up, some are in the middle of stopping, and some belong to other applications altogether.
Enter Services: services map incoming network requests to the actual pods that can service those requests.
Why not Deployments?
Doesn’t Kubernetes already have a resource that represents a bunch of pods in the same application? Why can’t users connect directly to a Deployment instead of connecting to a Service which points at pods inside a Deployment?
A Deployment can expose more than one service. For example, an NGINX Deployment can expose both HTTP and HTTPs Services.
Not all Pods are part of Deployments. StatefulSets and even standalone Pods can expose Services too. We need an abstraction for identifying which Pods can handle a network request, regardless of the pod’s lineage.
Some Services don’t point at Pods. This is out of scope here, but there are advanced use cases involving “Headless Services”.
Why not load balancers?
Before Kubernetes, we had old-fashioned “load balancers” that gave a single point of contact for many servers running the same application. Couldn’t that work on Kubernetes?
In fact, it does work like that! Load balancers can be used to implement Services, but we still require a logical way to identify which pods we’re load balancing.
Why not DNS?
Can’t DNS be used to map a logical address (google.com) to a dynamic set of machines (the machine at “10.1.0.2”) running the actual application?
Well, yes. But again, who makes sure that the DNS address (google.com) routes to the right place when Pods spin up and down? How do you logically identify which pods it should route to.
Again, Services are the answer.
DNS is the address, the Service is the deliveryman.
We’ll discuss this in more depth next week. Subscribe to get notified!