# Understanding Kubernetes Networking Deep dive into how pods communicate, services work, and ingress routing. **Model:** claude-opus-4 **Created:** 7/30/2026 --- ## Conversation ### **Human** I'm struggling to understand Kubernetes networking. How do pods actually talk to each other? And what's the difference between a Service and an Ingress? --- ### **Assistant** Kubernetes networking is confusing because there are THREE different networking layers: LAYER 1: Pod-to-Pod communication. Every pod gets its own IP. Pods can talk to each other directly. No NAT involved. LAYER 2: Service abstraction. Services provide a stable IP for dynamic pods. Load balances across backend pods. Implements kube-proxy via iptables or IPVS. LAYER 3: Ingress (HTTP routing). HTTP and HTTPS routing into cluster. Host-based and path-based routing. Terminates TLS. Visualizing the flow: User goes to Internet, goes to Ingress, goes to Service, goes to Pod. The Ingress handles HTTP routing (80/443), the Service provides stable internal IP (cluster IP), the Pod is where the application actually runs. Want me to explain any specific layer in depth? --- ### **Human** Yes! I'm confused about how kube-proxy actually makes Services work. What's happening under the hood? --- ### **Assistant** EXCELLENT question! This is where the magic happens. kube-proxy runs on every node and watches the API server. When you create a Service, kube-proxy does this on every node: 1. Create a cluster IP (e.g., 10.96.100.50) 2. Set up iptables rules that randomly select a backend pod when traffic hits the cluster IP 3. Use DNAT to rewrite destination to pod IP 4. Pod receives and responds 5. Response goes back through NAT In IPVS mode (more efficient): Uses IPVS (IP Virtual Server) instead of iptables. Kernel-level load balancing. O(1) lookup vs O(n) for many backends. The beauty: No proxy overhead, all in kernel space! Want me to explain how this actually handles failover and scaling? --- --- *Downloaded from BranchLM - GitHub for AI Sessions*