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.
// packet path lab
Kubernetes Networking / CNI Simulator
Follow packets through Pod IP routing, CNI dataplanes, ClusterIP Services, kube-proxy or eBPF translation, Ingress, NetworkPolicy, and internet egress.
2
Nodes
2
Pod CIDRs
VXLAN
Dataplane
Pod traffic keeps pod IPs inside the cluster packet, while cross-node hops can be wrapped in an outer node-to-node tunnel.
Cluster mode can spread traffic to endpoints on any node, often through an extra hop.
Application opens a socket
Pods get their own IPs. On the same node, traffic can move through veth pairs and local routing without a Service.
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.
cluster.local / pod network 10.244.0.0/16
node-a
PodCIDR 10.244.1.0/24
frontend
10.244.1.12
app=frontend
api
10.244.1.34
app=api
CoreDNS
svc DNS -> ClusterIP
node-b
PodCIDR 10.244.2.0/24
payments
10.244.2.21
app=payments
worker
10.244.2.45
app=worker
kube-proxy
iptables or IPVS
Verdict
Dataplane
Overlay CNI
Complete
not yet
Why it matters
Kubernetes expects Pods and nodes to reach Pod IPs without application-level awareness.
Dataplane details
Pod traffic keeps pod IPs inside the cluster packet, while cross-node hops can be wrapped in an outer node-to-node tunnel.
kube-proxy programs iptables/IPVS rules for Service VIP translation.
Node A encapsulates the pod packet, the underlay carries it to Node B, then Node B decapsulates it.
externalTrafficPolicy=Cluster can route to any endpoint, often at the cost of source IP preservation.
Mental model
CNI configures Pod networking when a Pod sandbox is created.
Services are stable virtual front doors for changing endpoint Pods.
EndpointSlices publish the concrete backend addresses behind Services.
NetworkPolicy is enforced by the networking plugin, not kube-apiserver.
About 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
Bounce Triage Simulator
Read a real SMTP bounce and decide what it is and what to do about it. Twelve genuine failures from Gmail, Outlook, Postfix and Proofpoint: hard bounces, soft bounces, content blocks, rate limits and spam complaints. Learn why the 4xx and 5xx class digit is a hint rather than the answer, which bounces to suppress permanently, which to retry, and what each mistake costs you in lost subscribers or lost sending reputation.
// simulator
DNS Resolution Simulator
Learn how DNS works with an interactive step-by-step simulator. Visualize the DNS hierarchy, understand caching at different levels, and see the difference between recursive and iterative queries.
// simulator
SMTP Flow Simulator
Visualize how SMTP email delivery works from app submission through EHLO, STARTTLS, AUTH, MAIL FROM, RCPT TO, DATA, SPF, DKIM, DMARC, recipient MX relay, temporary failures and retries, auth failures, and inbox placement. Sponsored by SMTPfast.