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.

Claude is a superpower if you know how to use it correctly.

Discover how THE CODE's Playbook to AI can elevate both your productivity and creativity to get more things done.

Learn to automate tasks, enhance decision-making, and foster innovation with the power of AI.

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

Kubernetes networking starts with two primary models. In a flat network, all Pods and Services exist in a single, flat network where every Pod can reach every other Pod (across nodes) without NAT.

Hub and spoke model is a network topology where all traffic from “spoke” networks (clusters, VPCs, or namespaces) routes through a central “hub.”

Kubernetes by default follows the Flat Network Model. Pods are directly routable across nodes.

Before going further into pod networking, two terms come up constantly and are worth pinning down precisely. Ingress refers to traffic coming into something, and egress refers to traffic leaving it.

These two words apply at nearly every layer inside Kubernetes, not just at the edge of the cluster. A pod has ingress rules governing what can reach it and egress rules governing what it is allowed to reach. A NetworkPolicy object, for instance, is really just a set of ingress and egress rules scoped to a group of pods. Keeping these two directions straight matters because a rule written for one direction has no effect on traffic moving the other way.

Kubernetes networking is easiest to understand as three separate conversations stacked on top of each other, each with different rules.

Containers inside the same pod share a single network namespace, which means they share one IP address and can reach each other over localhost, the same way two processes running on one machine would. This is why a sidecar container, like a logging agent sitting next to an application container, never needs a special networking setup to read from the application, it just connects to a local port.

Pod to pod communication is where the flat network model does its work. Two pods, even on completely different nodes, talk to each other using their assigned pod IPs directly, with the CNI plugin responsible for making sure traffic sent to a pod IP on one node actually arrives at the right pod on another node.

Internet to Kubernetes communication is the layer everything else in this piece builds toward, since getting external traffic safely and correctly into the cluster requires more machinery than the first two layers do.

Kubernetes offers three main ways to expose a group of pods as a network destination, and they are not three unrelated options, they build directly on top of one another.

This nesting relationship matters because a LoadBalancer service is not a replacement for NodePort's behavior, it depends on it. Understanding where NodePort's own limitations sit is what explains why a cloud load balancer alone still is not the end of the story for handling real production traffic.

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