Q: Explain the complete request flow to Kubernetes pod from a browser.

The user types https://app.example.com/checkout into the browser. The browser checks local DNS caches, then queries the OS recursive resolver, root nameservers, TLD nameservers, and authoritative DNS (e.g., AWS Route 53) returning the Anycast IP address of the Cloud CDN or Cloud Load Balancer.

# Inspect DNS resolution hops locally
dig +trace app.example.com

• Local Cache Check: Browser DNS cache -> OS resolver cache -> /etc/hosts.
• Recursive Resolution: ISP or corporate resolver queries Root (.), TLD (.com), and authoritative nameservers.
• GeoDNS & Anycast: Route 53 or Cloudflare returns the closest Edge PoP IP via Anycast BGP routing.

The browser initiates a TCP connection to the destination IP on port 443 via SYN -> SYN-ACK -> ACK. It negotiates TLS 1.3 cipher suites and validates the server X.509 certificate.

# Trace TCP connection and TLS handshake details
curl -Iv https://app.example.com/checkout

• TCP Handshake: Client sends SYN; Cloud Load Balancer responds with SYN-ACK; Client sends ACK to establish socket.
• TLS 1.3 Handshake: Client Hello sends Server Name Indication (SNI) and supported cipher suites; server returns certificate and completes 1-RTT cryptographic session establishment.

The traffic reaches the AWS Application Load Balancer (ALB) or Network Load Balancer (NLB). The ALB terminates TLS, inspects HTTP headers, and forwards traffic into the Kubernetes cluster worker nodes.

# AWS Target Group health check query
aws elbv2 describe-target-health --target-group-arn <target-group-arn>

• Instance Mode vs IP Mode: In Instance Mode, ALB routes to worker node NodePort. In IP Mode (via AWS VPC CNI), the ALB routes directly to pod IP addresses via TargetGroupBindings, bypassing NodePort overhead.
• Header Injection: ALB appends X-Forwarded-For, X-Forwarded-Proto, and X-Amzn-Trace-Id headers.

The request arrives at the Ingress Controller pod running inside the cluster. The Ingress Controller matches the HTTP Host header and URI path against configured Kubernetes Ingress rules.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: production
spec:
  rules:
  - host: app.example.com
    http:
      paths:
      - path: /checkout
        pathType: Prefix
        backend:
          service:
            name: checkout-service
            port:
              number: 8080

• L7 Rule Evaluation: Evaluates host app.example.com and path /checkout.
• Upstream Connection Pools: Ingress controller maintains persistent HTTP/2 keepalive connection pools to backend pods to eliminate TCP handshake latency.

When the Ingress controller forwards traffic to the Kubernetes Service ClusterIP, the Linux kernel translates the virtual IP to a physical pod IP using netfilter/iptables, IPVS, or Cilium eBPF.

# Inspect iptables PREROUTING chains programmed by kube-proxy
sudo iptables -t nat -L KUBE-SERVICES -n -v
sudo iptables -t nat -L KUBE-SVC-CHECKOUT -n -v

• Virtual IP Translation: ClusterIP is not a physical network interface; it exists solely as kernel packet filtering rules.
• Random Load Balancing: iptables uses statistic mode (e.g. statistic mode random probability 0.5) to evenly distribute new TCP flows across healthy pod IPs tracked in EndpointSlices.

The packet is encapsulated or routed directly across the worker node network by the Container Network Interface (CNI) plugin (AWS VPC-CNI, Calico, or Cilium).

# Inspect network namespaces and veth interface links on the host
ip netns list
ip link show type veth

• veth Interface Pair: One end of the virtual ethernet pair resides in the host root network namespace, while the peer interface (eth0) lives inside the pod's isolated network namespace.
• CNI Routing: In AWS VPC-CNI, pods have secondary ENI VPC private IPs with native AWS routing. In overlay CNIs (Calico/Flannel), packets are encapsulated in VXLAN/Geneve UDP frames across worker nodes.

The packet arrives at the pod's eth0 interface, traverses the TCP socket buffer, and is accepted by the application server (e.g., Node.js, Go, Spring Boot). The application processes the request and sends HTTP 200 OK back through the conntrack reverse path.

# Test application port inside the pod network namespace
kubectl exec -it <pod-name> -n production -- curl -v http://localhost:8080/healthz

• Socket Processing: Linux kernel wakes up the listening process via epoll/kqueue; the application parses HTTP headers and executes business logic.
• Reverse Conntrack Un-DNAT: The outbound HTTP response packet traverses conntrack reverse translation, restoring the expected source IP so the client receives a seamless HTTP response.

Comprehensive architectural comparison of networking layers involved in the complete request flow to Kubernetes pod: