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!