[{"data":1,"prerenderedAt":332},["ShallowReactive",2],{"blog-en-kubernetes-networking-cni-service-mesh-network-engineer":3,"blog-related-en-kubernetes-networking-cni-service-mesh-network-engineer":281,"blog-en-kubernetes-networking-cni-service-mesh-network-engineer-alt":269},{"id":4,"title":5,"author":6,"body":7,"date":263,"description":264,"extension":265,"image":266,"locale":267,"meta":268,"navigation":269,"path":270,"seo":271,"stem":272,"tags":273,"__hash__":280},"blog\u002Fblog\u002Fen\u002Fkubernetes-networking-cni-service-mesh-network-engineer.md","You Can Calculate Subnets, But Your Pods Won't Connect: The First Wall in Kubernetes Networking","Kubo Team",{"type":8,"value":9,"toc":243},"minimark",[10,15,23,26,37,40,49,53,58,61,66,69,72,76,83,87,90,94,99,102,106,121,124,128,137,140,144,159,166,170,175,178,182,190,193,197,206,209,213,216,219,231,240],[11,12,14],"h2",{"id":13},"_1-you-can-calculate-subnets-so-why-wont-your-pods-connect","1. You Can Calculate Subnets, So Why Won't Your Pods Connect?",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-networking-cni-service-mesh-network-engineer\u002Fsection01.webp",[16,24,25],{},"You can handle subnet mask calculations, VLAN design, and BGP peering without breaking a sweat. And yet, the moment you start touching a Kubernetes cluster, you suddenly can't figure out why two Pods won't talk to each other. This is far from a rare experience.",[16,27,28,29,36],{},"Kubernetes networking is built on an abstraction layer that differs fundamentally from traditional network design. Pods are created and destroyed constantly, IP addresses aren't fixed, and there's little room to manually edit routing tables. As the ",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fservices-networking\u002Fservice\u002F",[34],"nofollow","official Kubernetes documentation"," explains, a Kubernetes Service provides \"a stable network endpoint decoupled from the dynamically changing IP addresses of Pods\"—a mechanism that overturns the very premise of \"fixed IPs plus static routing\" that underlies traditional network design.",[16,38,39],{},"In other words, understanding Kubernetes networking means learning how to translate a network engineer's existing knowledge of \"address design\" into Kubernetes' \"declarative, dynamic\" world. This article walks through the three core components—CNI, Service Mesh, and NetworkPolicy—by contrasting each with its traditional networking counterpart.",[16,41,42,43,48],{},"That said, you don't necessarily have to work through this translation process from scratch on your own every time. With a managed Kubernetes service like ",[30,44,47],{"href":45,"rel":46},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo",", CNI selection and baseline NetworkPolicy configuration already come standardized out of the box. Let's start by laying out the fundamentals of Kubernetes networking.",[11,50,52],{"id":51},"_2-the-three-layers-of-kubernetes-networking-cni-service-and-ingress","2. The Three Layers of Kubernetes Networking — CNI, Service, and Ingress",[16,54,55],{},[19,56],{"alt":21,"src":57},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-networking-cni-service-mesh-network-engineer\u002Fsection02.webp",[16,59,60],{},"Kubernetes networking becomes much easier to grasp as a whole once you break it down into three layers.",[62,63,65],"h3",{"id":64},"cni-container-network-interface-the-foundation-of-pod-to-pod-communication","CNI (Container Network Interface) — The Foundation of Pod-to-Pod Communication",[16,67,68],{},"CNI is the layer responsible for assigning network interfaces to Pods and handling the actual packet forwarding between them. The CNI spec itself is plugin-based, and the choice of CNI plugin at cluster build time significantly changes how Pod-to-Pod communication is implemented—whether through an overlay network or BGP-based routing, for example.",[16,70,71],{},"In traditional networking terms, CNI plays a role similar to \"a combination of switches and routers.\" The key difference is that configuration is fundamentally declarative, driven by Kubernetes manifests, rather than physical port configuration.",[62,73,75],{"id":74},"service-a-stable-endpoint-that-hides-a-group-of-pods","Service — A Stable Endpoint That Hides a Group of Pods",[16,77,78,79,82],{},"Pods scale up and down frequently, and their IP addresses change along with them. The Service resource is what absorbs this instability. According to the ",[30,80,35],{"href":32,"rel":81},[34],", when a Service is created it's assigned a fixed ClusterIP, and a controller continuously scans for Pods matching the selector to keep the corresponding EndpointSlice updated automatically. Clients never need to be aware of individual Pod IPs—the same concept as multiple servers hidden behind a load balancer.",[62,84,86],{"id":85},"ingress-the-point-of-contact-with-the-outside-world","Ingress — The Point of Contact With the Outside World",[16,88,89],{},"Ingress handles routing HTTP\u002FHTTPS traffic from outside the cluster. It's conceptually similar to a traditional reverse proxy or load balancer configuration, but in Kubernetes it too is managed declaratively as a manifest.",[11,91,93],{"id":92},"_3-choosing-a-cni-in-practice-how-cilium-calico-and-flannel-differ-in-design-philosophy","3. Choosing a CNI in Practice — How Cilium, Calico, and Flannel Differ in Design Philosophy",[16,95,96],{},[19,97],{"alt":21,"src":98},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-networking-cni-service-mesh-network-engineer\u002Fsection03.webp",[16,100,101],{},"Choosing a CNI plugin is the area where a network engineer's existing knowledge is most directly applicable—or, alternatively, where the biggest shift in thinking is required. Let's look at three representative plugins.",[62,103,105],{"id":104},"cilium-observability-and-security-powered-by-ebpf","Cilium — Observability and Security Powered by eBPF",[16,107,108,109,114,115,120],{},"Cilium is a CNI plugin built on eBPF, a Linux kernel feature. According to the ",[30,110,113],{"href":111,"rel":112},"https:\u002F\u002Fwww.cncf.io\u002Fannouncements\u002F2023\u002F10\u002F11\u002Fcloud-native-computing-foundation-announces-cilium-graduation\u002F",[34],"official CNCF announcement",", Cilium was accepted as a CNCF Incubating project in October 2021 and was promoted to Graduated status in October 2023. The same announcement reports adoption by more than 100 organizations and participation from over 800 individual contributors, making it one of the most active projects in the CNCF behind Kubernetes itself. The ",[30,116,119],{"href":117,"rel":118},"https:\u002F\u002Fwww.cncf.io\u002Fprojects\u002Fcilium\u002F",[34],"CNCF project page"," likewise positions Cilium as an eBPF-based networking, security, and observability solution.",[16,122,123],{},"For traditional network engineers, Cilium's strength lies in its ability to \"visualize the flow of packets.\" Being able to observe Pod-to-Pod communication in real time, in a way that feels similar to tcpdump or NetFlow, is a significant advantage.",[62,125,127],{"id":126},"calico-the-bgp-native-familiar-choice","Calico — The BGP-Native, \"Familiar\" Choice",[16,129,130,131,136],{},"Calico's defining feature is its ability to use BGP (Border Gateway Protocol)-based routing. According to the ",[30,132,135],{"href":133,"rel":134},"https:\u002F\u002Fdocs.tigera.io\u002Fcalico\u002Flatest\u002Fabout\u002F",[34],"official Calico documentation",", Calico is described as a networking and security solution that supports containers, virtual machines, and bare-metal hosts—extending well beyond Kubernetes to OpenStack and bare-metal environments as well.",[16,138,139],{},"BGP-based routing is one of the rare areas where knowledge built up from data center networking transfers directly, making Calico arguably the most \"familiar\" CNI for network engineers.",[62,141,143],{"id":142},"flannel-focused-on-simple-connectivity","Flannel — Focused on Simple Connectivity",[16,145,146,147,152,153,158],{},"Flannel, as described in its ",[30,148,151],{"href":149,"rel":150},"https:\u002F\u002Fgithub.com\u002Fflannel-io\u002Fflannel",[34],"official repository",", is \"a simple layer 3 network fabric designed for Kubernetes.\" A flanneld agent runs on each node and assigns subnets from a pre-configured address space. Unlike Cilium and Calico, it has no policy engine and focuses purely on providing connectivity. In K3s, Flannel is adopted as the ",[30,154,157],{"href":155,"rel":156},"https:\u002F\u002Fdocs.k3s.io\u002Fnetworking\u002Fbasic-network-options",[34],"default CNI plugin",", with vxlan configured as the default backend.",[16,160,161,165],{},[30,162,164],{"href":45,"rel":163},[34],"Kubo Cloud",", which is also K3s-based, builds on this same lightweight network foundation while bundling NetworkPolicy support and monitoring as standard—reducing the effort needed to separately assemble the policy control and observability layers that tend to be thin with Flannel alone.",[11,167,169],{"id":168},"_4-whats-the-difference-between-networkpolicy-and-service-mesh","4. What's the Difference Between NetworkPolicy and Service Mesh?",[16,171,172],{},[19,173],{"alt":21,"src":174},"https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-networking-cni-service-mesh-network-engineer\u002Fsection04.webp",[16,176,177],{},"One area that trips up many engineers learning Kubernetes networking is the distinction between NetworkPolicy and Service Mesh.",[62,179,181],{"id":180},"networkpolicy-access-control-at-l3l4","NetworkPolicy — Access Control at L3\u002FL4",[16,183,184,185,189],{},"According to the ",[30,186,35],{"href":187,"rel":188},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fservices-networking\u002Fnetwork-policies\u002F",[34],", NetworkPolicy is a resource that achieves \"traffic control at the IP address or port level (OSI layer 3 or 4),\" and supports protocols including TCP, UDP, and SCTP. Importantly, the official documentation explicitly states that \"network policies are implemented by the network plugin\"—meaning that if you're using a CNI plugin that doesn't support NetworkPolicy (Flannel, mentioned earlier, being a prime example), creating a NetworkPolicy resource will have no effect whatsoever.",[16,191,192],{},"This is conceptually close to configuring traditional firewall rules. It's easiest to understand as a mechanism for declaratively defining \"which Pod (source) is allowed to communicate with which Pod (destination) on which port.\"",[62,194,196],{"id":195},"service-mesh-encryption-observability-and-traffic-control-at-l7","Service Mesh — Encryption, Observability, and Traffic Control at L7",[16,198,199,200,205],{},"Service Mesh, on the other hand, operates at L7 (the application layer). In the case of Istio, a representative implementation, the ",[30,201,204],{"href":202,"rel":203},"https:\u002F\u002Fistio.io\u002Flatest\u002Fdocs\u002Fconcepts\u002Fsecurity\u002F",[34],"official documentation"," explains that \"Istio provides mutual TLS (mTLS) as a full-stack transport authentication solution without requiring any changes to application code.\" Envoy proxies on both the client and server sides perform a handshake, mutually verify identity, and then encrypt the traffic that follows.",[16,207,208],{},"Put another way: if NetworkPolicy is the firewall that decides \"whether communication is allowed or not,\" Service Mesh is the layer that \"encrypts the communication itself and makes visible who is talking to whom.\" The two aren't competing technologies—combining them is what achieves defense covering both L3\u002FL4 and L7.",[11,210,212],{"id":211},"_5-conclusion-subnet-thinking-is-a-foundation-but-it-requires-a-shift-in-mindset","5. Conclusion — Subnet Thinking Is a Foundation, But It Requires a Shift in Mindset",[16,214,215],{},"Kubernetes networking is by no means a technology that renders traditional network design knowledge useless. Understanding of BGP transfers directly to operating Calico, and the mindset behind firewall rule design connects directly to designing NetworkPolicies. At the same time, there's no avoiding a shift in premises: Pods are created and destroyed dynamically, IPs aren't fixed, and configuration is fundamentally managed declaratively through manifests.",[16,217,218],{},"Choosing a CNI, and working out the division of labor between NetworkPolicy and Service Mesh—these are design and verification tasks that require real, non-trivial learning investment. Selecting a CNI from scratch on EKS or AKS, confirming NetworkPolicy support, and building out a full monitoring setup all take considerable operational effort.",[16,220,221,224,225,230],{},[30,222,47],{"href":45,"rel":223},[34]," is a managed Kubernetes service built on K3s, with baseline CNI and network policy configuration already standardized, so you don't need to work through the complexity of network design from zero. For a 4 vCPU \u002F 8 GB \u002F 40 GB × 3-node configuration, you can run a full-spec Kubernetes environment starting at ¥48,000 per month according to the ",[30,226,229],{"href":227,"rel":228},"https:\u002F\u002Fwww.hexabase.com\u002Fpricing\u002F",[34],"pricing plan","—a substantial cost advantage compared to AWS EKS at ¥82,700 per month.",[16,232,233,234,239],{},"Of course, Kubo uses the standard Kubernetes API as-is, so any knowledge or experience with Calico, Cilium, or BGP carries over directly. Learning the fundamentals of network design while handing off day-to-day operations to a managed service is a genuinely practical option. If you don't have the bandwidth to work through the details of network design in-house, ",[30,235,238],{"href":236,"rel":237},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"reaching out"," to discuss your current setup is one way forward.",[16,241,242],{},"Kubernetes networking isn't \"a foreign language\" to a traditional network engineer—it's \"a familiar language with a different grammar.\"",{"title":21,"searchDepth":244,"depth":244,"links":245},2,[246,247,253,258,262],{"id":13,"depth":244,"text":14},{"id":51,"depth":244,"text":52,"children":248},[249,251,252],{"id":64,"depth":250,"text":65},3,{"id":74,"depth":250,"text":75},{"id":85,"depth":250,"text":86},{"id":92,"depth":244,"text":93,"children":254},[255,256,257],{"id":104,"depth":250,"text":105},{"id":126,"depth":250,"text":127},{"id":142,"depth":250,"text":143},{"id":168,"depth":244,"text":169,"children":259},[260,261],{"id":180,"depth":250,"text":181},{"id":195,"depth":250,"text":196},{"id":211,"depth":244,"text":212},"2026-07-22","You're great at subnet design, so why does Pod-to-Pod communication in Kubernetes trip you up every time? We break down the fundamentals of Kubernetes networking—CNI, Service Mesh, and NetworkPolicy—by contrasting them with traditional network design.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-networking-cni-service-mesh-network-engineer\u002Feyecatch.webp","en",{},true,"\u002Fblog\u002Fen\u002Fkubernetes-networking-cni-service-mesh-network-engineer",{"title":5,"description":264},"blog\u002Fen\u002Fkubernetes-networking-cni-service-mesh-network-engineer",[274,275,276,277,278,279],"kubernetes","k3s","networking","cni","service-mesh","network-policy","U0jNWxlqzAmbgaQ2Hdv6_UYuFSfEzC9JzSLhCHRqago",[282,290,298,307,315,323],{"path":283,"title":284,"description":285,"date":286,"tags":287},"\u002Fblog\u002Fen\u002Fkubevirt-calico-live-migration-networking","Moving a VM Doesn't Have to Break the Connection: Inside KubeVirt and Calico's Live Migration Magic","Why doesn't live migrating a VM (KubeVirt) between Kubernetes nodes break the connection? We break down Calico's IP persistence and BGP route convergence, and what it means for teams moving off VMware.","2026-08-07",[275,274,288,276,289],"kubevirt","managed-kubernetes",{"path":291,"title":292,"description":293,"date":294,"tags":295},"\u002Fblog\u002Fen\u002Fkubernetes-microservices-chatty-calls-latency","One Order, Five Hidden Service Calls: The Real Cause of Latency in Kubernetes Microservices' \"Chatty Calls\"","A single checkout request was quietly triggering five separate service calls behind the scenes. The culprit isn't bad code — it's the \"chatty call\" architecture that Kubernetes microservices tend to fall into. This article explains the distributed N+1 problem and how to fix it.","2026-08-02",[274,275,296,278,297,289],"microservices","latency",{"path":299,"title":300,"description":301,"date":302,"tags":303},"\u002Fblog\u002Fen\u002Fkubernetes-certificate-management-cert-manager-process-debt","The Cert Renewal Took One Line of Code and Two Months of Meetings: Why Kubernetes Certificate Management Is a Process Problem, Not a Technical One","Kubernetes certificate management is technically a matter of days. What actually takes time is the organizational process of getting sign-off. Here's how cert-manager automates the technical side, and how to design away the operational debt that remains.","2026-08-09",[275,274,304,305,306],"cert-manager","tls","security",{"path":308,"title":309,"description":310,"date":311,"tags":312},"\u002Fblog\u002Fen\u002Fai-agent-sandbox-kata-containers-kubernetes","AI Agent Code Isn't a \"Trusted Product\" Anymore. Kubernetes Sandbox Design Has an Answer","Code generated and executed by AI agents can no longer be treated as a trusted, reviewed product. This article explains the limits of container isolation and why Kata Containers' microVM isolation is becoming essential when designing AI agent sandboxes on Kubernetes.","2026-08-08",[275,274,313,314,306],"kata-containers","ai-agent",{"path":316,"title":317,"description":318,"date":319,"tags":320},"\u002Fblog\u002Fen\u002Fkubernetes-image-signing-sigstore-supply-chain","Anyone Can Rewrite an Image Tag. Why Kubernetes Needs Sigstore-Backed Signing to Prove Provenance","Container image signing explained: tags can be overwritten by anyone, and passing CI tests doesn't guarantee the image running in production is the one you built. Learn how Sigstore and Kyverno work together to reject unsigned images on Kubernetes\u002FK3s, integrated into a GitOps workflow.","2026-08-06",[275,274,321,322,306],"ci-cd","gitops",{"path":324,"title":325,"description":326,"date":327,"tags":328},"\u002Fblog\u002Fen\u002Fkubernetes-high-availability-broadcast-seamless-switching","Broadcasters Send the Same Video Twice and Just Keep Whichever Arrives First — It Turns Out That's Exactly How Kubernetes Achieves High Availability","World Cup broadcasts duplicate every camera feed across two independent paths and simply discard whichever packet arrives second. That seemingly wasteful design shares the same philosophy as Kubernetes high availability and multi-AZ architecture.","2026-08-05",[275,274,329,330,331],"high-availability","multi-az","sre",1786354655756]