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.

You're spending 40 hours a week writing code that AI could do in 10.

While you're grinding through pull requests, 200k+ engineers at OpenAI, Google & Meta are using AI to ship faster. How?

The Code newsletter teaches them exactly which AI tools to use and how to use them. Here's what you get:

Sign up now and get instant access to the Ultimate Claude code guide to ship 5X faster.

Powered by: Jobsurface.com

Browse 706 Worldwide Jobs Here →

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

Pods in Kubernetes are ephemeral. They come and go. When a pod dies and is replaced, it gets a new IP address. If your frontend service was connecting directly to a backend pod's IP, that connection would break every time the backend pod restarted. This is the problem Kubernetes Services solve.

A Service is a stable network abstraction that sits in front of a group of pods and provides a consistent endpoint that never changes, regardless of how often the pods behind it are replaced. The Service uses a label selector to determine which pods belong to it. When a pod with a matching label starts, the Service automatically includes it in its backend pool. When that pod dies, the Service removes it. Your clients never need to know about individual pod IPs.

The label selector is the binding mechanism between a Service and its pods. You define the Service with a selector, and every pod carrying that label becomes a backend endpoint for the Service.

A Service with selector: app:dev routes traffic to only the pods labelled app=dev. A Service with selector: app:prod routes traffic to all pods labelled app=prod, which in this case is two pods. The Service load balances across all matching pods automatically. When you scale your Deployment from two to ten pods, the Service starts routing to all ten without any configuration change. When a pod fails its health check and is replaced, the new pod with the same labels is picked up by the Service automatically.

This decoupling between Service definition and pod identity is what makes Kubernetes networking resilient. The Service is the stable thing. Pods are the ephemeral things. The selector is the contract between them.

The label selector is also how the Service knows when to add or remove endpoints. When a new pod starts with a matching label and passes its readiness probe, the endpoints controller adds it to the Service's endpoint list. When a pod is deleted or fails its readiness probe, it is removed from the endpoint list immediately. Clients hitting the Service never route to an unhealthy pod.

Kubernetes has three main Service types and they are not independent options. They build on each other. Each outer type includes all the capabilities of the inner type.

ClusterIP is the foundation. It gives your Service a virtual IP address that is only reachable from inside the cluster.

NodePort builds on top of ClusterIP by additionally opening a port on every node in the cluster, making the Service reachable from outside.

LoadBalancer builds on top of NodePort by additionally provisioning a cloud load balancer in front of those node ports, giving you a single stable external IP.

With this understanding, let’s look at how applications are exposed using different Kubernetes Service types.

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