Networking Deep Dive Knowledge

A CNI plugin provides Pod networking. It assigns Pod IPs, configures network interfaces, sets up routes, and enables Pod-to-Pod communication across nodes according to the plugin design.

Calico, Flannel, and Cilium are common examples. Calico is known for routing and policy, Flannel for simple overlay networking, and Cilium for eBPF-based networking and observability.

CNI handles Pod networking, including IP assignment, interfaces, routing, and sometimes policy. kube-proxy handles Service networking by programming iptables or IPVS rules, unless the cluster uses a replacement dataplane.

The Pod CIDR is the IP range assigned for Pods, often per node. It must match CNI configuration and routing assumptions. If Pod CIDRs conflict or routes are missing, Pod-to-Pod traffic breaks.

The Service CIDR is the virtual IP range used for Kubernetes ClusterIP Services. Service IPs are not normal Pod IPs; they are virtual addresses handled by kube-proxy, IPVS, eBPF, or another Service dataplane.

iptables mode uses Linux iptables NAT rules to route Service traffic to backend endpoints. It is widely used and reliable, but large clusters can accumulate many rules.

IPVS mode uses Linux IP Virtual Server for high-performance Service load balancing with connection tracking. It can scale better than large iptables rule sets, but still depends on correct endpoint and node networking state.

eBPF is a Linux kernel technology for safe, programmable packet processing. Kubernetes CNIs such as Cilium use it for fast networking, policy enforcement, observability, and sometimes kube-proxy replacement.

The node routing table decides where Pod traffic goes. Depending on the CNI, routes may point Pod CIDRs to other nodes, overlay interfaces, tunnels, or local bridges. Wrong routes cause cross-node connectivity failures.

Hairpin NAT allows a Pod to access a Service IP that resolves back to the same Pod or same node. Without correct hairpin behavior, direct Pod IP access may work while Service access from the backend Pod fails.

They provide DNS-based service discovery for Pods and Services. CoreDNS usually answers names like kubernetes.default.svc.cluster.local and forwards external DNS queries upstream.

Use kubectl exec -it <pod> -- nslookup kubernetes.default, or run a temporary debug Pod with DNS tools. If resolution fails, check resolv.conf, kube-dns Service, CoreDNS Pods, NetworkPolicy, and CNI connectivity.

Ingress provides basic HTTP and HTTPS routing to Services through an Ingress controller. Gateway API is more advanced and extensible, separating Gateway infrastructure from Route objects and supporting stronger delegation and multi-tenant patterns.

An ingress rule defines which sources can send traffic to selected Pods. Sources can include Pod selectors, namespace selectors, IP blocks, and ports. If a Pod is selected for ingress isolation, only allowed ingress traffic is accepted.

An egress rule defines which destinations selected Pods can connect to. Destinations can include Pods, namespaces, IP blocks, and ports. Remember to allow DNS egress if Pods need name resolution.

Traffic for selected Pods is blocked unless another policy explicitly allows it. A true default deny pattern usually includes separate deny-all ingress and deny-all egress policies, followed by narrow allow policies.

EndpointSlices provide a scalable representation of Service endpoints, replacing the older Endpoints API for large Services. They include endpoint addresses, ports, readiness, and topology information.

kube-proxy programs iptables or IPVS rules so traffic arriving at <NodeIP>:<NodePort> is forwarded to backend Pods for the Service. Health, routing, firewall, and externalTrafficPolicy settings can all affect behavior.

With hostNetwork: true, the Pod shares the node network namespace and uses the node IP and ports. With default Pod networking, the Pod gets its own network namespace and Pod IP from the CNI.

Maximum Transmission Unit is the largest packet size that can pass without fragmentation. Overlay networks, tunnels, VPNs, and cloud networks can reduce effective MTU. Mismatched MTUs can cause packet loss, timeouts, and strange partial connectivity.