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.

KodeKloud gives you 1,280+ hands-on labs where you provision Kubernetes clusters, write Terraform configs, build CI/CD pipelines, configure Linux systems, containerize apps with Docker, automate with Ansible, and manage Git workflows. 

78+ playgrounds let you experiment freely in sandbox AWS environments, Kubernetes clusters, and CI/CD systems without risk. 

190+ courses across DevOps, Cloud, and AI pair theory with hands-on labs at every step. 

KodeKloud Engineer and 100 Day Challenges provide real-world job scenarios with automated grading that confirms your solutions work.

Stuck? The 55,000+ member Discord community connects you with peers and instructors ready to help. 

Every lab runs in a live environment. You deploy, you troubleshoot, you learn. No videos without context. No simulations. The kind of practice that actually builds confidence because you've done real work, not watched someone else do it.

Start Learning For Free

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

The cluster has Pods, Deployments, and Services, and traffic somehow reaches an application running on one of dozens of nodes, but the exact path a request takes from a browser to a running container is not obvious from reading the YAML alone. A production incident makes this worse. A pod is crash looping, but the alert fires on the Service, not the pod, and figuring out which layer actually failed requires understanding how these pieces connect. This piece walks through that chain, layer by layer, from a single container up to internet facing traffic.

Let’s start with basics.

The smallest deployable unit in Kubernetes is not a container. It is a Pod, and a single Pod can run more than one container that share the same network namespace and, optionally, storage volumes.

A single Pod holding these three containers running side by side. All three share the Pod's IP address and can reach each other over localhost, since Kubernetes places them in the same network namespace at the OS level.

A real use case for this is a main application container paired with a logging sidecar that reads log files from a shared volume and ships them to a central aggregation system. Both containers start and stop together as part of the same Pod, which matters because if the main container crashes, the entire Pod, sidecar included, gets recreated rather than just one piece of it.

A single Pod running in isolation is fragile. If the node it runs on fails, or the Pod itself crashes, nothing brings it back automatically unless something is watching it. A Deployment solves this by declaring a desired number of identical Pod replicas and continuously reconciling the running state to match that number.

One Deployment object manages three identical Pods, each running the same three containers. If any of these Pods disappears, whether from a node failure, a manual deletion, or a crash, the Deployment's controller notices the mismatch between desired and actual replica count and creates a replacement Pod to restore it.

This is what makes a rolling update possible without downtime. When a new container image is pushed, the Deployment gradually replaces old Pods with new ones, a few at a time, rather than tearing down every Pod simultaneously.

Pods are not stable network endpoints. Every time a Pod restarts or gets rescheduled to a different node, it receives a new internal IP address. An application that tries to talk directly to a Pod's IP will eventually find that address gone. A Service solves this by giving a stable virtual IP address in front of a group of Pods, selected by matching labels rather than by tracking specific Pod identities.

A client sends a request to the Service's IP address rather than to any individual Pod. The Service, sitting in front of the Deployment, load balances that request across the three backing Pods. If one Pod disappears and a replacement comes up with a new IP, the Service updates its internal endpoint list automatically, and the client never notices the change.

This default Service type is called ClusterIP, and it is only reachable from inside the cluster. A frontend calling a backend API within the same cluster typically uses this, since neither side needs external exposure.

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