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.

Top engineers at Anthropic and OpenAI say AI now writes 100% of their code.

If you're not using AI, you're spending 40 hours doing what they do in 4.

These 100+ Claude Code hacks fix that and help you ship 10x faster.

Sign up for The Code and get:

Powered by: Jobsurface.com

Browse 679 Worldwide Jobs Here →

If you’re not a subscriber, here’s what you missed last week.

When to Use Event Driven vs Containerized Architectures in AWS

Which Is Better: EKS Pod Security Groups or Node Security Groups?

To receive all the full articles and support TechOps Examples, consider subscribing:

One-time 25% OFF on all annual plans of memberships. Closes Soon.

Git Concepts Simulator - Practice Git in an interactive browser terminal with a visual repository model.

Learn the working directory, staging area, local commits, branch pointers, remotes, fast-forward merges, fetch, and rebase.

Running multiple tenants on the same Kubernetes cluster cuts infrastructure costs and simplifies operations. But it introduces a problem most teams underestimate: every container on every node shares the same Linux kernel. That single fact is the root of most container security challenges in multi tenant environments.

A container is not a virtual machine. It is a process on the host, isolated using Linux namespaces and cgroups. Namespaces give each container its own view of the filesystem, network, and process tree. Cgroups limit resource consumption. Both are enforced by the same kernel every other container on the node is using.

If a workload finds a kernel vulnerability and exploits it, the isolation namespaces provide collapses entirely. The attacker is in the host kernel and can reach every other container on the node. Seccomp profiles, AppArmor, SELinux, and Linux capability restrictions reduce the exposed syscall surface but do not eliminate it. For clusters running workloads from different customers or trust levels on the same node, this is a hard problem that software isolation alone cannot fully solve.

Kata Containers addresses this by wrapping each container inside a lightweight virtual machine. Every workload gets its own dedicated kernel running inside a hardware-virtualized VM. From Kubernetes' perspective it is still a pod. Underneath, the isolation boundary is hardware virtualization rather than kernel namespaces.

In the traditional model, Process A and Process B both execute against the same kernel. Every security filter sits inside that shared kernel. If the kernel is compromised, all of those filters fall with it. In the Kata model, Process A has Kernel A and Process B has Kernel B. An exploit inside one VM compromises only that VM's kernel. The hardware virtualization layer absorbs the escape attempt before it can reach the host or any neighbouring workload.

From Kubernetes, a Kata pod is just a pod annotated with runtimeClassName: kata-containers. Scheduling, networking, and storage all work identically. The runtime layer is what changes.

When a pod is created, the Kata Runtime boots a lightweight VM using a hypervisor, QEMU by default, with Firecracker available for lower overhead. The VM starts fast because it runs a stripped down kernel and a minimal rootfs. Inside the VM, a Kata Agent handles container lifecycle operations, receiving instructions from the host via the Proxy over vsock. The workload talks to its guest kernel and has no visibility into the host or any other VM on the node.

Kata makes the most sense when the cost of a container escape is high. Multi-tenant SaaS platforms running customer code and CI/CD pipelines executing untrusted build scripts are the clearest use cases. For internal clusters where all workloads share the same trust level, the added overhead of a guest VM per pod may not be justified.

A practical approach is mixed runtime classes in the same cluster. Standard pods use the default runtime. Sensitive or untrusted workloads use runtimeClassName: kata-containers. Kubernetes handles both transparently on the same nodes, so you pay the isolation overhead only where you actually need it.

THE CODE - Learn how to code faster with AI in 5 mins a day. Loved by 200k+ devs, engineers at Meta, Google, OpenAI, and more.

Sign up to get The Ultimate Claude Code Guide + 200 Free Engineering resources.

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

Looking to promote your company, product, service, or event to 48,000+ DevOps and Cloud Professionals? Let's work together.