What is Kubernetes networking model?

Kubernetes imposes fundamental networking requirements: every pod gets its own IP address; pods on the same node can communicate without NAT; pods across nodes can communicate without NAT; agents on a node can communicate with all pods on that node. This is achieved by the CNI (Container Network Interface) plugin. Pod networking: each pod has a virtual network interface (veth pair). One end in the pod's network namespace, other end in the host namespace. Connected to a bridge. CNI plugin manages routing across nodes. CNI plugins: Calico (network policy + routing, BGP or VXLAN, most popular); Cilium (eBPF-based, high performance, rich network policy, service mesh capabilities); Flannel (simple overlay network, VXLAN, limited network policy); Weave; Canal (Flannel + Calico network policy). Service networking (kube-proxy): ClusterIP services get a virtual IP (cluster-internal only). kube-proxy creates iptables (or IPVS) rules that DNAT traffic from ClusterIP → one of the pod endpoints. DNS: CoreDNS (deployed as a Deployment, every pod configured to use it). my-service.my-namespace.svc.cluster.local → ClusterIP. Network Policies: by default, all pods can communicate with all pods. Network Policies restrict traffic using pod selectors, namespace selectors, and port specifications. Both ingress and egress can be controlled. Requires a CNI plugin that supports Network Policy (Calico, Cilium, Weave). Service Mesh (Istio, Linkerd): adds mTLS between services, traffic management, observability — sidecar proxy (Envoy) injected into each pod. Cilium Mesh provides eBPF-based mesh without sidecar overhead.