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.

When you type a prompt, you summarize. When you speak one, you explain. Wispr Flow captures your full reasoning — constraints, edge cases, examples, tone — and turns it into clean, structured text you paste into ChatGPT, Claude, or any AI tool. The difference shows up immediately. More context in, fewer follow-ups out.

89% of messages sent with zero edits. Used by teams at OpenAI, Vercel, and Clay. Try Wispr Flow free — works on Mac, Windows, and iPhone.

Start flowing free

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

A single container running one process is the default mental model for a Kubernetes pod, and for a lot of application code that model holds up fine. But real production workloads rarely stay that simple once they leave a tutorial. A web server needs a log shipper watching its output files. A database migration has to complete before the application is allowed to touch the schema. A service mesh needs a proxy intercepting every request in and out of the container without the application's own code knowing that proxy exists.

Kubernetes does not force each of these concerns into a separate pod with its own IP address and its own lifecycle to manage, it allows more than one container to share a single pod, and the specific way those containers are arranged, at the same time, before, or alongside, determines what problem they actually solve.

A pod is not defined as one container, it is defined as a group of one or more containers that share the same network namespace and, when a volume is mounted into more than one of them, the same filesystem mount points. Sharing the network namespace means every container in the pod sees the same loopback interface, so container A can reach container B over localhost:port the same way two processes on one machine would, without a Service, without DNS, without any network hop at all.

This also means two containers in the same pod cannot both bind the same port, since they are competing for the same network stack rather than isolated ones.

That shared lifecycle changes how basic day-to-day operations work the moment a second container enters the picture, because kubectl now has no way to guess which container a log or shell command is meant for.

This same targeting requirement extends to kubectl top pod --containers, which breaks CPU and memory usage down per container rather than reporting one number for the whole pod, and to kubectl describe pod, whose Containers: section lists each container's own state, restart count, and exit code independently, since one container in a pod can be crash looping while its sibling runs perfectly healthy.

Sharing a pod is only half the picture. The second half is that not every container in a pod runs at the same time or serves the same purpose. Some containers exist purely to do preparation work that has to finish completely, successfully, before the actual application is allowed to start at all, checking that a database is reachable, generating a config file from a template, downloading a dependency the main container expects to already be present on disk.

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