We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningIntermediate · Kubernetes & Containers
A stable network endpoint that load-balances traffic across a set of pods. Pods come and go, but the Service's IP and DNS name stay constant.
In short
A Kubernetes Service is a stable network endpoint that load-balances traffic across a set of Pods selected by labels. Pods are created and destroyed constantly with changing IPs, but the Service keeps one fixed virtual IP and DNS name so other workloads can reach the group reliably.
In short
A Kubernetes Service is a stable network endpoint that load-balances traffic across a set of Pods selected by labels. Pods are created and destroyed constantly with changing IPs, but the Service keeps one fixed virtual IP and DNS name so other workloads can reach the group reliably.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers Kubernetes Service across a run of lessons, not one page. These 4 alone are about 78 minutes of step-by-step reading, every one with a quiz.
Routing external HTTP traffic to the right Kubernetes service, the cluster's front door.
How services find each other in a dynamic environment where instances spin up and die constantly.
Firewall rules for Kubernetes pods, controlling which pods can communicate with each other.
Managing stateful applications in Kubernetes, stable network identities, ordered deployment, and persistent storage per pod.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Ingress Controllerspay once,
yours for life
In Kubernetes the smallest deployable unit is a Pod, and Pods are disposable. When a Deployment scales up, rolls out a new version, or reschedules a Pod onto another node, the Pod gets a brand new IP address. If your frontend hard-coded a backend Pod IP, it would break within minutes. A Service solves that by giving the group a name and address that never change for the life of the Service.
A Service is defined by a label selector, for example app=payments. Any Pod carrying that label automatically becomes a target. You do not list IPs by hand. The Service watches the cluster and keeps its target list current as Pods come and go.
Each Service gets a stable ClusterIP (a virtual IP that only exists inside the cluster) and a DNS name like payments.default.svc.cluster.local. Code talks to that name, and Kubernetes spreads the requests across whatever healthy Pods currently match the selector.
Behind every Service is an Endpoints object (or the newer EndpointSlice) that holds the live list of Pod IPs and ports matching the selector. The control plane updates this list automatically whenever Pods become ready or fail their readiness probe, so traffic only goes to Pods that can actually serve it.
On each node a component called kube-proxy programs the data plane to route the virtual ClusterIP to those real Pod IPs. Classic kube-proxy writes iptables or IPVS rules; newer setups use eBPF via a CNI like Cilium. The result is the same: a packet sent to the ClusterIP gets rewritten to one of the backing Pods, picked roughly at random or round-robin.
There are several Service types. ClusterIP is the default and is reachable only inside the cluster. NodePort opens a fixed port on every node so outside traffic can reach the Service. LoadBalancer asks the cloud provider for an external load balancer (an AWS NLB, a GCP forwarding rule) that forwards to the NodePort. A headless Service (clusterIP: None) skips load balancing and returns the Pod IPs directly through DNS, which stateful systems use to address individual Pods.
Use a Service any time one set of Pods needs to talk to another, or anything needs a stable address into a workload. It is the standard way to do internal east-west routing and basic L4 load balancing inside a cluster, and it costs nothing extra.
The main limitation is that a plain Service operates at L4 (TCP and UDP). It does not understand HTTP, so it cannot route by hostname or path, terminate TLS, or do retries based on status codes. For external HTTP traffic you usually put an Ingress or a Gateway API resource in front, and that Ingress controller still routes to a Service.
Load balancing is also per-connection at the kube-proxy layer, not request-aware. For long-lived gRPC or HTTP/2 connections, all requests can pin to one Pod because the connection never reopens. Teams that need request-level balancing, mTLS, or fine traffic shaping reach for a service mesh such as Istio or Linkerd, which still builds on top of Services. Creating a LoadBalancer Service per app also gets expensive in cloud bills, which is another reason a single shared Ingress is common.
Imagine an online store running a Deployment of three checkout Pods. You create a ClusterIP Service named checkout with selector app=checkout on port 80 targeting the Pods on port 8080. The cart service now just calls http://checkout/charge and never thinks about IPs.
During a Black Friday spike the autoscaler grows checkout from 3 Pods to 30. The Endpoints list expands automatically and kube-proxy starts spreading load across all 30, with no config change anywhere else. When the rollout of a new build replaces those Pods one by one, readiness probes hold each new Pod out of the Endpoints list until it can serve, so requests never hit a Pod that is still booting.
If checkout instead exposed a public API, you would front it with an Ingress that terminates TLS and routes store.example.com/checkout to the same Service, keeping the internal contract identical.
Kubernetes
Service is a core built-in object; every multi-Pod workload on Kubernetes uses one for stable addressing and L4 load balancing.
Amazon EKS
A LoadBalancer Service provisions an AWS Network or Application Load Balancer via the AWS Load Balancer Controller to expose workloads.
Cloudflare
Runs internal platforms on Kubernetes where Services provide cluster-internal routing in front of its edge and control-plane workloads.
Spotify
Uses Kubernetes Services for service-to-service discovery across thousands of microservices instead of hard-coding Pod addresses.
A Deployment manages the lifecycle of Pods: how many run, which image, and how rollouts happen. A Service is the network layer that gives those Pods one stable IP and DNS name and load-balances traffic to them. You almost always pair them: the Deployment creates Pods with a label, and the Service selects that label.
ClusterIP gives an internal-only virtual IP reachable just inside the cluster and is the default. NodePort opens the same port on every node so traffic from outside the cluster can reach the Service. LoadBalancer asks the cloud provider for an external load balancer that forwards into the Service, which is how you expose apps to the public internet on a managed cluster.
Through a label selector. The Service matches Pods that carry the labels it specifies, and Kubernetes keeps an Endpoints or EndpointSlice list of their current IPs. Pods that fail a readiness probe are removed from that list, so traffic only reaches Pods that are ready to serve.
Standard Service load balancing happens per connection at L4, and gRPC uses one long-lived HTTP/2 connection. Once that connection lands on a Pod it stays there, so every request rides the same Pod. Fix it with a headless Service plus client-side balancing, or a service mesh that balances per request.
For internal cluster traffic, a Service alone is enough. For external HTTP routing by hostname or path, TLS termination, or sharing one external entry point across many apps, you add an Ingress or Gateway API resource, and it routes to your Services. The two work together rather than replacing each other.
Kubernetes Pod
The smallest deployable unit in Kubernetes: one or more containers sharing network and storage. Pods are ephemeral; if one dies, K8s creates a replacement.
Load Balancer
Distributes incoming traffic across multiple servers so no single server gets overwhelmed. Like a traffic cop directing cars to different lanes.
Service Discovery
The mechanism by which microservices find and communicate with each other. Services register themselves and others can look them up by name.
Docker
A platform for packaging applications into lightweight, portable containers. 'Works on my machine' becomes 'works everywhere.'
Kubernetes
An orchestration platform that automates deploying, scaling, and managing containerized applications. K8s is the operating system for your cloud.
Container
A lightweight, isolated environment that packages an application with its dependencies. Shares the host OS kernel, unlike VMs. Starts in milliseconds.
This page explains the idea. The course covers it step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
See the System Design Masterclass coursecourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Kubernetes Service in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
