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.

Thousands of AI papers, model releases, and product launches ship every week. You don't need all of them. You need the ten that matter.

TLDR AI is the free daily newsletter curated by Anthropic and ex-Google engineers. People who build AI for a living read everything, then send you what's actually worth your time: the models, research, and tools that will still matter next month.

No hot takes, no hype cycles, no 60-tweet threads. Clear summaries you can read between meetings.

Join 1.1M+ readers. Subscribe for free.

Subscribe for free

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

Let's start understanding the basics before jump into the context of what a service mesh actually fixes.

Every workload running in a cluster deals with two directions of network traffic, and the terminology matters because most networking rules, whether a NetworkPolicy or a service mesh policy, are scoped to one direction or the other.

A Target, shown as a group of containers, receives Ingress traffic, which is incoming traffic arriving from outside, and sends Egress traffic, which is outgoing traffic leaving toward external systems represented by the cloud. A rule permitting ingress does nothing to control what that same workload is allowed to send out, and the reverse holds just as strongly.

This distinction becomes important once a cluster has dozens of services all initiating requests to each other. Controlling only what comes in in leaves egress wide open, and a service mesh, much like a NetworkPolicy, treats these as two separate problems to solve.

A real production incident makes the difference between these two approaches concrete. A payments team notices intermittent 5xx errors between two internal services, with no clear pattern, and the on call engineer has nothing beyond basic connection logs from kube-proxy to diagnose it with. This is the ceiling of what Kubernetes' native networking layer gives you.

On the Kubernetes Native side, Pods on separate Nodes communicate through kube-proxy, which handles routing rules at the OS level, and a CNI plugin, which handles the actual packet delivery between Pods. Neither layer inspects the content of that traffic or tracks per request behavior; they only move packets. On the Service Mesh side, every Pod gets its own Proxy sidecar, and these proxies talk directly to each other over the CNI layer, while all of them register with a Control Plane that pushes configuration and policy down to every proxy in the mesh.

The proxies are what change everything here. Since every request between Service A and Service B now physically passes through two proxies, one on each side, the mesh has visibility into every single call: which service made it, how long it took, whether it succeeded, and whether it should have been allowed to happen at all. kube-proxy and the CNI plugin never had that context, because they operate at the packet level, not the request level.

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