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.

Start trading real-world events. With Kalshi, you can trade on things you already follow: inflation, elections, sports, and more. It’s simple: buy “Yes” or “No” shares on what you think will happen, and earn returns if you’re right.

To get you started, we’re giving you a free $10. Use it to explore the platform, test your instincts, and see how prediction markets work in real time.

Join thousands already trading the news and putting their knowledge to work.

Claim your $10 and start trading now.

Put $10 to Work

_{Trade responsibly.}

Powered by: Jobsurface.com

Browse 634 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

I have debugged more than one incident where a database pod restarted and every row written that day was simply gone. The container had been treating its local filesystem as if it would survive forever, and Kubernetes never made that promise. Storage in Kubernetes is a small stack of objects, each solving a different failure mode, and picking the wrong one is exactly how data disappears silently.

Every container starts with its own writable filesystem layer, and that layer dies with the container. If a process inside crashes and the kubelet restarts it, whatever was written to that filesystem is gone, because the replacement container starts from the image again with nothing carried over. This is fine for stateless work, but the moment an application needs to keep anything, logs, cached files, or database rows, that default becomes a liability.

A Volume in Kubernetes is defined at the Pod level, not the container level, which is the detail that makes it useful. Storage tied to the Pod survives an individual container restarting inside that Pod, and it can also be shared between multiple containers running in the same Pod.

Kubernetes ships with several Volume types, and each one deals about where the data actually lives and how long it needs to last.

The first three are useful for caching, sharing files between sidecars, or injecting configuration, but none of them protect data once the Pod itself is deleted or rescheduled to a different node. For anything that needs to outlive the Pod, Kubernetes requires the PersistentVolumeClaim path, which is a different mechanism entirely and covered further down.

The YAML for a basic Volume is short. A Pod spec names a Volume under spec.volumes, gives it a type, in this case emptyDir, and then each container that needs it references it under volumeMounts with a path.

emptyDir is allocated fresh when the Pod is scheduled and removed permanently when the Pod is deleted. It is a Pod scoped scratch space, not a durable store, which is why it sits in the same category as hostPath in the table above.

A PersistentVolume exists independently of any Pod, and its lifecycle is managed separately from the workloads that use it. Data placed in a PersistentVolume survives not only a container restart but a Pod being deleted and recreated, and in most backing implementations, a node failure as well.

A Pod never talks to a PersistentVolume directly. It goes through a PersistentVolumeClaim, which is the request for storage rather than the storage itself. This separation exists so that application authors describe what they need, capacity and access mode, without needing to know which disk, network share, or cloud volume actually backs it.

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