TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

Frost & Sullivan's Frost Radar benchmarks the runtime security market: who leads, who's rising, and why. The latest edition maps the vendors advancing runtime protection across cloud workloads and applications, and recognizes Oligo as a leader in ADR for precise, low-noise detection of what's actually exploitable. See where every vendor lands. Get the radar.

Powered by: Jobsurface.com

Browse 593 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 49,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Every pod in a Kubernetes cluster gets its own IP address the moment it starts, and that IP disappears the moment the pod restarts, crashes, or gets rescheduled to a different node. A deployment running three replicas might replace all three pods multiple times in a single day during normal operation, whether from a rolling update, a node failure, or the scheduler simply moving a pod to balance load. Each replacement pod comes up with a brand new IP address. An application that stores a pod's IP and tries to reuse it later breaks constantly under this churn, and that is the exact problem a Kubernetes Service exists to solve.

A Service gives a group of pods one stable address that never changes, no matter how many times the pods behind it are created and destroyed. Clients send traffic to the Service, and the Service is responsible for finding a healthy pod to hand that traffic to. The pods stay disposable, and the Service stays constant, which decouples anything that consumes an application from the lifecycle of the pods actually running it.

A Service is not a proxy process running somewhere in the cluster waiting for connections. It is a Kubernetes object, a record in etcd describing which pods to route to and on which ports, and the actual traffic forwarding is carried out by components running on every node, covered later in this piece.

A Service is defined in YAML, the same as a pod or a deployment, and applied to the cluster with kubectl apply, or generated quickly from an existing deployment with kubectl expose. Three fields in the spec do almost all of the work.

Kubernetes watches the API server for any Service object like this one, and a background process continuously updates cluster-wide routing to match whatever the spec describes. A Service can define more than one port block under the same object, each with its own name, which matters once an application exposes several ports, such as an HTTP port alongside a metrics port, and needs a single Service to cover both.

A Service does not scan the cluster for matching pods on every request. Kubernetes runs a separate controller that continuously watches for pods matching a Service's selector and writes the resulting list of pod IPs and ports into an object called an EndpointSlice, formerly a single Endpoints object in older clusters. This EndpointSlice is what the actual traffic forwarding machinery reads from, not the Service definition itself.

Readiness probes play a direct role here. A pod that fails its readiness probe is pulled out of the EndpointSlice immediately, even though the pod keeps running and keeps matching the selector by label. This is the same readiness mechanism that governs whether a pod receives traffic during a rolling deployment, and it means a Service only ever forwards to pods that have declared themselves capable of handling requests, not merely pods that exist.

The selector field is what connects a Service to its pods, and it works through labels rather than pod names or IP addresses. Every pod carries a set of key-value labels in its metadata, and a Service matches any pod whose labels satisfy its selector.

This label matching is why renaming a pod or rescheduling it to a different node never breaks routing. As long as a pod keeps the label a Service is looking for, it stays part of the group receiving traffic, and a pod can be added to or removed from that group simply by changing its labels, without touching the Service object at all. Deployments and ReplicaSets rely on this exact same label mechanism to know which pods they own, which is why a Service selector and a Deployment's pod template labels usually need to line up precisely.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)