Interview: Kubernetes Networking & Services

• Every Pod gets its own IP address - Pods can reach each other without NAT.
• Agents on a node (kubelet/CNI) can reach all Pods on that node.
• Agents on a node can reach all Pods on all nodes without NAT (flat pod network).

These assumptions simplify service discovery and health checks. The CNI plugin is responsible for implementing the pod network across nodes.

Pod IPs are ephemeral - when a Pod restarts, it gets a new IP. A Service provides a stable virtual IP (ClusterIP) and DNS name that load-balances to a dynamic set of Pod endpoints. kube-proxy (or eBPF dataplane) programs rules on each node to forward Service traffic to healthy backend Pods. Without Services, clients would break every time Pods are rescheduled.

• ClusterIP (default) - reachable only inside the cluster. Use for internal microservice-to-microservice traffic.
• NodePort - exposes the Service on a static port (30000–32767) on every node's IP. Useful for dev/bare-metal; usually not ideal alone in production.
• LoadBalancer - provisions an external cloud load balancer pointing to NodePort backends. Standard way to expose apps on AWS/GCP/Azure. On bare metal, MetalLB provides similar behavior.

A Headless Service does not allocate a virtual IP; DNS returns individual Pod A records instead of a single Service IP. Use it when clients need direct Pod-to-Pod discovery: StatefulSet stable identity (pod-0.service.ns.svc.cluster.local), custom client-side load balancing, or service meshes that manage their own routing. Common for databases and Kafka brokers behind StatefulSets.

A LoadBalancer Service exposes one Service on one external IP (expensive per Service in cloud). Ingress is an L7 HTTP/HTTPS routing layer: one entry point (often one load balancer) routes by host/path to multiple backend Services (/api → api-svc, /web → web-svc). Ingress controllers (nginx, Traefik, AWS ALB) implement the Ingress spec. Use Ingress for HTTP routing and TLS termination; use LoadBalancer for non-HTTP protocols (gRPC over dedicated LB, TCP databases).

CoreDNS (default) runs as a cluster add-on. It resolves <service>.<namespace>.svc.cluster.local to the Service ClusterIP (or Pod IPs for Headless Services). Pods use /etc/resolv.conf with search paths so curl my-svc in the same namespace works. Cross-namespace: my-svc.other-ns.svc.cluster.local. DNS is critical for service discovery - hardcoding Pod IPs is an anti-pattern.

NetworkPolicies are firewall rules for Pods. By default, all Pod-to-Pod traffic is allowed in most clusters. A NetworkPolicy selects Pods via labels and defines ingress/egress rules (allowed source/destination IPs, namespaces, ports). They require a CNI that enforces policies (Calico, Cilium, Weave). Use them for zero-trust segmentation: only the frontend namespace can reach the API; only the API can reach the database.

Kubernetes defines how networking should behave but does not implement it. The Container Network Interface (CNI) is a standard for pluggable network setup: allocate Pod IPs, configure interfaces on nodes, and set up cross-node routing (VXLAN, BGP, etc.). Popular CNIs: Calico (policy + BGP), Cilium (eBPF, observability), Flannel (simple overlay). The choice affects performance, policy support, and operational complexity.

kube-proxy watches Services and EndpointSlices, then programs node-level rules. In iptables mode, it creates chains that DNAT Service IP traffic to backend Pod IPs with probabilistic load spread. IPVS mode uses kernel IPVS for better performance at scale. kube-proxy modes are being supplemented by eBPF (Cilium kube-proxy replacement) for lower latency and richer observability. Traffic hairpinning (Pod calling its own Service) requires special handling on some CNIs.

A service mesh adds a dedicated infrastructure layer for service-to-service communication - typically sidecar proxies (Envoy in Istio/Linkerd) or eBPF node-level proxies (Cilium). It provides mutual TLS, fine-grained traffic policies, retries/timeouts, circuit breaking, and distributed tracing without changing app code. Worth it at scale with many microservices needing security compliance and observability; overkill for small clusters where Ingress + NetworkPolicies suffice.

• Terminate TLS at Ingress with cert-manager (Let's Encrypt or internal CA).
• Use LoadBalancer or Ingress with restricted security groups / firewall rules.
• Apply NetworkPolicies so only the ingress controller can reach backend Pods.
• Avoid exposing databases via LoadBalancer - keep them ClusterIP with policy-restricted access.
• Consider a service mesh for mTLS between internal services even when external TLS is handled at Ingress.

North-south traffic enters or leaves the cluster (users → Ingress → Service → Pod). East-west traffic flows between services inside the cluster (api-svc → db-svc). Ingress and LoadBalancers handle north-south; Services, DNS, and NetworkPolicies govern east-west. Service meshes primarily add policy, encryption, and observability to east-west traffic. Production hardening requires attention to both paths.