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.
Hop timeline
cluster.local / pod network 10.244.0.0/16
Packet path: Application opens a socket
Active route
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
Internet
public API
LoadBalancer
198.51.100.40:443
NodePort
node IP:30443
Ingress
host/path routing
Service
10.96.12.40:443
EndpointSlice
10.244.2.21, 10.244.2.45
NetworkPolicy
verdict: forward
externalTrafficPolicy
Cluster: spread across nodes
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.
Current verdict
Dataplane
Overlay CNI
Service handling
kube-proxy programs iptables/IPVS rules for Service VIP translation.
Cross-node handling
Node A encapsulates the pod packet, the underlay carries it to Node B, then Node B decapsulates it.
External traffic policy
Cluster can route to any endpoint, often at the cost of source IP preservation.
Scenario complete
not yet
The Kubernetes network model expects Pods and nodes to reach Pod IPs without application-level awareness.
Overlay CNI
Pod traffic keeps pod IPs inside the cluster packet, while cross-node hops can be wrapped in an outer node-to-node tunnel.
CNI is called when a Pod sandbox is created or deleted.
CNI assigns Pod networking; Services are Kubernetes abstractions over endpoint Pods.
EndpointSlices publish the concrete backend addresses behind Services.
Pod-to-Pod traffic inside the cluster should not need NAT.
LoadBalancer Services commonly enter through NodePort before endpoint selection.
NetworkPolicy is enforced by the networking plugin, not by 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.
Try next
// 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, retries, bounces, and inbox placement. Sponsored by SMTPfast.
// simulator
TCP vs UDP Simulator
Interactive visualization showing the differences between TCP's reliable connection-oriented protocol and UDP's fast connectionless approach. See the 3-way handshake, packet loss, and retransmissions in action.