Networking in Kubernetes

In Docker, microservices find each other by name. But what if pods are on different machines? What if you need load balancing? What if you need to restrict who can talk to whom? Kubernetes networking solves these problems at production scale.

• **Spotify** runs thousands of pods. Without a flat network and service discovery it would be an IP address chaos
• **Netflix** uses Cilium for security policies and observability - they see all traffic between microservices
• **Ingress controller** saves money: one LB instead of hundreds. With 100 services, that's significant

Предварительные знания

• Networking in Docker

Цели урока

• Understand the flat pod network: every pod has a cluster-unique IP, no NAT between pods
• Distinguish ClusterIP, NodePort, LoadBalancer, ExternalName and when to use each Service type
• Explain kube-proxy modes (iptables vs IPVS) and why IPVS scales better with thousands of services
• Trace a packet path: client → Ingress → Service → Endpoint → pod (via CNI: Calico/Cilium/Flannel)
• Apply NetworkPolicy to isolate namespaces and understand why they are a no-op without a policy-capable CNI

Pod Networking Model

**Pod Networking** is the foundation of K8s networking. Rules: 1) Every pod gets a unique IP. 2) All pods can communicate with each other without NAT. 3) Agents on the node (kubelet) can communicate with pods on that node. Flat network - everyone is in the same L3 network.

**CNI (Container Network Interface)** is the standard for pod networking plugins. Calico, Flannel, Cilium, Weave are different implementations of the same standard. The choice of CNI determines how pods get IPs and how they are routed between nodes.

ClusterIP Service

**ClusterIP** is a virtual IP for a group of pods. Pod IPs change on restart. Service IP is stable. kube-proxy on each node programs iptables/IPVS to route to live pods. Load balancing is built in.

**Endpoints** is the list of IP:port of live pods under a Service. kube-proxy watches endpoints and updates iptables on changes. Pod dies → endpoint removed → traffic stops going to the dead pod.

NodePort and LoadBalancer

**NodePort** opens a port on every node (30000-32767). Traffic to NodeIP:NodePort → Service → Pods. **LoadBalancer** creates a cloud LB (AWS ELB, GCP GLB) that routes to NodePorts. This is the path for external traffic to enter the cluster.

**externalTrafficPolicy: Local** - traffic goes only to pods on the same node where it arrived. Preserves client IP (no SNAT). But if there are no pods on the node - health check fails and the LB stops sending traffic there.

Ingress Controller

**Ingress** is an L7 reverse proxy for HTTP(S) traffic. One LoadBalancer → many services. Routing by host/path: api.example.com → api-svc, example.com/blog → blog-svc. TLS termination, rate limiting, auth - all handled here.

**Ingress Controller** is a pod running nginx/traefik/envoy that reads Ingress resources and configures the reverse proxy. It's not part of K8s core - you need to install it separately (nginx-ingress, traefik, istio-ingress).

CNI Plugins

**CNI (Container Network Interface)** plugins handle pod networking. Calico, Flannel, Cilium, Weave are different implementations of the same standard. The choice of CNI affects: performance, security features (NetworkPolicy), overlay vs direct routing.

**NetworkPolicy** is a firewall for pods. Without a policy - all-allow. With a policy - default deny, explicit allow. Requires a CNI with support (Calico, Cilium). Flannel doesn't support it - you need an additional controller.

Key Takeaways

• **Pod Network:** flat network, every pod has a unique IP, all pods see each other without NAT
• **Service (ClusterIP):** stable virtual IP, load balancing to pods, DNS discovery
• **NodePort/LoadBalancer:** external access. NodePort - port on all nodes. LoadBalancer - cloud LB
• **Ingress:** L7 routing (host/path), TLS termination, one LB for many services
• **CNI Plugins:** implement pod networking (Calico, Flannel, Cilium). NetworkPolicy requires CNI support

Related Topics

K8s networking is built on fundamental concepts:

• Docker Networking — Pod networking uses the same primitives: namespaces, veth, bridges
• Service Mesh — Istio/Linkerd add L7 features on top of K8s networking
• Load Balancing — kube-proxy implements L4 load balancing, Ingress handles L7

Вопросы для размышления

• When would you choose Calico over Flannel? When would you choose Cilium?
• Why is the default NetworkPolicy allow-all? Isn't that dangerous?
• How do you debug a 'connection refused' error between two pods in different namespaces?

Связанные уроки

• dist-12-consistency