Low Level Design: Kubernetes Networking Design

By /

Kubernetes networking enables communication between Pods, Services, and external clients across a cluster of machines. The Kubernetes networking model guarantees that every Pod gets a unique IP address and can communicate with every other Pod without NAT. Services provide stable virtual IPs (ClusterIP) and DNS names for groups of Pods. Understanding Kubernetes networking — CNI plugins, kube-proxy, Ingress, and NetworkPolicy — is essential for deploying and debugging applications in production Kubernetes environments and for system design interviews at companies with large-scale Kubernetes deployments.

Pod Networking: CNI Plugins

Each Pod gets a unique IP from the cluster CIDR (e.g., 10.244.0.0/16). CNI (Container Network Interface) plugins implement the networking: Flannel: simple overlay network using VXLAN encapsulation — packets between nodes are wrapped in UDP datagrams. Easy to set up, lower performance. Calico: uses BGP routing (no overlay) for high performance, plus NetworkPolicy enforcement. Best for production. Cilium: uses eBPF for packet processing in the Linux kernel, providing high performance, deep observability (network flow logs), and L7 policy enforcement. The CNI plugin assigns an IP to each Pod from the node CIDR, sets up routes, and ensures Pod-to-Pod connectivity across nodes. Pod IP is ephemeral — it changes when the Pod is rescheduled. Services provide stable addressing.

# Kubernetes networking components

# 1. Service types
kubectl expose deployment nginx --type=ClusterIP --port=80    # internal only
kubectl expose deployment nginx --type=NodePort --port=80     # node-port access
kubectl expose deployment nginx --type=LoadBalancer --port=80 # cloud LB

# 2. DNS resolution within cluster
# Service: svc-name.namespace.svc.cluster.local
# Pod: pod-ip.namespace.pod.cluster.local
# Short names within same namespace: just svc-name

# 3. NetworkPolicy: restrict Pod-to-Pod traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-db
spec:
  podSelector:
    matchLabels:
      app: database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-server  # only api-server pods can reach database
    ports:
    - protocol: TCP
      port: 5432

# 4. Ingress: HTTP routing from external to internal services
# Routes /api/* to api-service:8080, /* to frontend-service:80
# TLS termination at Ingress controller (nginx, Traefik, etc.)

Services and kube-proxy

A Service provides a stable ClusterIP and DNS name for a set of Pods. kube-proxy runs on every node and programs iptables (or IPVS) rules to implement service load balancing: when a request arrives at the ClusterIP:port, iptables rewrites the destination IP to one of the backing Pod IPs (round-robin by default). ClusterIP: only accessible within the cluster. NodePort: exposes the service on every node at a fixed port (30000-32767). LoadBalancer: creates a cloud provider load balancer pointing to all nodes at the NodePort. EndpointSlice: tracks the list of healthy Pod IPs for each Service; kube-proxy watches EndpointSlice changes and updates iptables rules when Pods are added or removed. kube-proxy in IPVS mode: uses the kernel-level IPVS load balancer instead of iptables, supporting additional load balancing algorithms (least-connections, consistent hashing) and better performance at scale.

Ingress and Ingress Controllers

Ingress is a Kubernetes resource that defines HTTP/HTTPS routing rules from external clients to internal Services. An Ingress Controller (nginx-ingress, Traefik, AWS ALB Ingress Controller) watches Ingress resources and configures an actual load balancer. Rules: route /api/* to api-service:8080, route / to frontend-service:80. TLS termination: specify a Secret containing the TLS certificate; the Ingress controller handles HTTPS and proxies plain HTTP to backends. Virtual hosting: one Ingress controller handles multiple domains (api.example.com → api-service, www.example.com → web-service). Rate limiting, auth, and custom headers: configured via Ingress annotations (specific to the controller). Gateway API (successor to Ingress): more expressive, role-oriented (infrastructure vs. application config), supports TCP and gRPC routing natively.

Key Interview Discussion Points

  • DNS-based service discovery: Pods resolve service names via CoreDNS (the cluster DNS server); CoreDNS caches and forwards queries; adding search domains (namespace.svc.cluster.local) allows short service names to work within a namespace
  • Headless services: a Service with clusterIP: None returns DNS A records for each Pod IP (not a single VIP); used for StatefulSets where clients need to connect to specific pods by name (pod-0.service.namespace.svc.cluster.local)
  • NetworkPolicy enforcement: NetworkPolicy is only enforced if the CNI plugin supports it (Calico, Cilium, Weave); Flannel does not enforce NetworkPolicy; by default all Pod-to-Pod traffic is allowed — apply NetworkPolicy for zero-trust networking
  • eBPF networking (Cilium): replacing iptables with eBPF programs in the kernel reduces networking overhead, enables per-connection load balancing without conntrack table, and provides L7 visibility (HTTP method, path, gRPC method) for network policies
  • Multi-cluster networking: service mesh (Istio) or Cilium Cluster Mesh enables Pods in different Kubernetes clusters to communicate using a flat IP space or service endpoint federation — used for geographic distribution and cluster isolation
{ “@context”: “https://schema.org”, “@type”: “FAQPage”, “mainEntity”: [ { “@type”: “Question”, “name”: “How does Kubernetes networking work and how do Pods communicate?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “The Kubernetes networking model guarantees: every Pod gets a unique IP address from the cluster CIDR (e.g., 10.244.0.0/16), and every Pod can communicate with every other Pod directly (no NAT required). CNI (Container Network Interface) plugins implement this: Calico uses BGP routing between nodes for high-performance direct routing; Flannel wraps packets in VXLAN UDP encapsulation for simplicity; Cilium uses eBPF programs in the Linux kernel for maximum performance and L7 visibility. Pod-to-Pod communication within a node uses the Linux network namespace and virtual ethernet pairs (veth). Cross-node communication uses the CNI plugin routing. Pod IPs are ephemeral — they change when a Pod is rescheduled. Services provide stable ClusterIPs and DNS names for groups of Pods.” } }, { “@type”: “Question”, “name”: “How does a Kubernetes Service work?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “A Service provides a stable virtual IP (ClusterIP) and DNS name for a group of Pods selected by a label selector. kube-proxy runs on every node and programs iptables (or IPVS) rules: when a packet arrives at the ClusterIP:port, iptables rewrites the destination IP to one of the healthy backing Pod IPs (round-robin by default). CoreDNS (the cluster DNS server) resolves service-name.namespace.svc.cluster.local to the ClusterIP. Service types: ClusterIP (internal only), NodePort (exposes on every node at a fixed port 30000-32767), LoadBalancer (creates a cloud LB pointing to all nodes at the NodePort). When Pods are added or removed, the EndpointSlice controller updates the list of healthy Pod IPs, and kube-proxy watches EndpointSlice changes to update iptables rules automatically.” } }, { “@type”: “Question”, “name”: “What is a NetworkPolicy in Kubernetes and how does it work?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “By default, all Pods in a Kubernetes cluster can communicate with each other (no network restrictions). NetworkPolicy resources define rules restricting ingress (inbound) and egress (outbound) traffic for selected Pods. Example: allow only Pods labeled app=api-server to reach Pods labeled app=database on port 5432; deny all other inbound traffic to database Pods. NetworkPolicy is declarative — you define the desired state and the CNI plugin enforces it. Calico, Cilium, and Weave Net enforce NetworkPolicy. Flannel does NOT enforce NetworkPolicy (you need a separate CNI plugin for enforcement). Without NetworkPolicy, any compromised Pod in the cluster can reach any database or secret store. Apply NetworkPolicy for zero-trust microsegmentation: default-deny all traffic, then allow only explicitly needed communication paths.” } }, { “@type”: “Question”, “name”: “What is a Kubernetes Ingress and how does it expose HTTP services?”, “acceptedAnswer”: { “@type”: “Answer”, “text”: “An Ingress resource defines HTTP/HTTPS routing rules from external traffic to internal Services. It specifies: which hostnames to handle (api.example.com, www.example.com), which URL paths to route to which backend Services (/api to api-service:8080, / to frontend-service:80), and TLS configuration (which Secret holds the certificate). An Ingress Controller (nginx-ingress, Traefik, AWS ALB Ingress Controller, Envoy via Contour) watches Ingress resources and configures an actual load balancer to implement the rules. The Ingress Controller is deployed once and handles routing for all Ingress resources in the cluster. Ingress annotations configure controller-specific features: rate limiting, auth forwarding, CORS headers, canary deployments. Gateway API (the successor to Ingress) provides a richer, more expressive model with role separation between infrastructure operators and application developers.” } } ] }
Scroll to Top