Kubernetes Networking / CNI Simulator
Visualize Kubernetes networking and CNI packet paths with an interactive simulator. Learn Pod-to-Pod routing, same-node and cross-node traffic, ClusterIP Services, EndpointSlices, headless Services, LoadBalancer, NodePort, kube-proxy, eBPF service routing, Ingress, NetworkPolicy, and internet egress.
Category: Networking
Topics covered: kubernetes, cni, networking, pods, services, clusterip, endpointslice, headless-service, loadbalancer, nodeport, ingress, networkpolicy, kube-proxy, ebpf, devops, educational, interactive
// simulator
Kubernetes Networking / CNI Simulator
Visualize Kubernetes networking and CNI packet paths with an interactive simulator. Learn Pod-to-Pod routing, same-node and cross-node traffic, ClusterIP Services, EndpointSlices, headless Services, LoadBalancer, NodePort, kube-proxy, eBPF service routing, Ingress, NetworkPolicy, and internet egress.
Application opens a socket
Goal: Pods get their own IPs. On the same node, traffic can move through veth pairs and local routing without a Service. Walk all 8 scenarios to their last hop (0/8 done).
Pod to Pod, Same Node, hop 1 of 4: Application opens a socket, forwarded.
Current hop
Packet
src=10.244.1.12:43152 -> dst=10.244.1.34:8080
Mutation
No NAT. The destination is already a Pod IP.
The frontend Pod sends directly to the backend Pod IP. This is normal Kubernetes networking: Pod IPs are first-class addresses inside the cluster.
Packet flow
4 hopsAbout this Kubernetes networking simulator
What you'll learn
- How Pods communicate by Pod IP on the same node and across nodes
- What a CNI plugin does when a Pod network namespace is created
- Why ClusterIP Services are virtual IPs that map to real endpoint Pods
- How EndpointSlices connect Service selectors to concrete backend addresses
- Where kube-proxy, IPVS, iptables, and eBPF-style service routing fit
- How Ingress, LoadBalancer, and NodePort traffic reaches a backend Pod
- How externalTrafficPolicy changes source IP preservation and routing tradeoffs
- Why NetworkPolicy requires enforcement by a capable networking plugin
Packet paths covered
- Pod networking: same-node and cross-node Pod-to-Pod flows
- Service networking: DNS, ClusterIP, EndpointSlices, endpoint selection, headless Services, and reply tracking
- Edge traffic: external client to LoadBalancer, NodePort, Ingress, Service, and Pod
- Security: default-deny, allow rules, egress controls, and CNI policy enforcement
CNI vs Service routing
CNI plugins make Pod networking work: interfaces, IPAM, routes, overlays or native routing, and often policy. Kubernetes Services are a separate abstraction that map stable virtual IPs and DNS names to changing endpoint Pods.
Browser-safe by design
This simulator does not connect to a real cluster. It models the packet path and dataplane decisions in the browser so you can learn how Kubernetes networking behaves before debugging iptables, eBPF maps, CNI agents, or cloud load balancers in production.
Overview
Kubernetes networking has two layers that are easy to mix up: the CNI plugin that gives every pod an IP address and moves packets between pods, and Services that give a stable virtual address in front of a changing set of pods. This simulator animates packet paths through both. You can follow a pod talking to another pod on the same node, a pod reaching a pod on another node, a request to a ClusterIP Service that gets translated to one backend endpoint, a headless Service that returns pod addresses through DNS from the EndpointSlice, traffic entering through an Ingress, and traffic arriving through a cloud LoadBalancer or a NodePort. You can switch between an overlay CNI, a routed CNI and an eBPF CNI to see how the same packet crosses nodes in each: wrapped in an encapsulation header, routed natively by the network, or handled by eBPF programs in the kernel. The goal is to know which layer to suspect when a connection fails: pod-to-pod problems point to the CNI, while a working pod IP behind a failing Service points to selectors, endpoints or kube-proxy.
Try this
- Play "Pod to Pod, Cross Node" with the overlay CNI, then switch to the routed and eBPF CNIs and compare how the packet crosses nodes.
- Follow the "ClusterIP Service" path and watch where the Service virtual IP is translated to a real endpoint.
- Open "EndpointSlice & Headless DNS" to see how a headless Service skips the virtual IP entirely.
Frequently asked questions
- What does a CNI plugin do in Kubernetes?
- It sets up networking for each pod: creates its network interface, assigns an IP address from the node pod range and makes sure pods can reach each other across nodes, using overlays, native routing or eBPF.
- What is the difference between ClusterIP, NodePort and LoadBalancer?
- ClusterIP gives a virtual IP reachable inside the cluster. NodePort also opens the same port on every node. LoadBalancer builds on that and asks the cloud provider for an external load balancer in front of the nodes.
- What is a headless Service?
- A Service with clusterIP set to None. DNS returns the IPs of the ready pods directly instead of a single virtual IP, which stateful workloads use to address individual pods.
Try next
// simulator
Email Authentication Lab: SPF, DKIM and DMARC
Publish SPF, DKIM and DMARC records, send mail directly and through a forwarder or mailing list, and inspect the receiver’s authentication verdict, alignment and disposition.
// simulator
HTTP/1.1 vs HTTP/2 vs HTTP/3 Lab
Load one page over HTTP/1.1, HTTP/2, and HTTP/3. Compare connection setup, multiplexed streams, TCP head-of-line blocking, and QUIC loss recovery in a request waterfall.
// simulator
CDN Edge Cache Lab
Set HTTP cache headers, send traffic through Frankfurt, Virginia and Singapore CDN edges, deploy, purge and inspect shared-cache hits, misses and 304 revalidation.