Week 7 - kube-proxy, Services, and the Networking Dataplane¶

7.1 Conceptual Core¶

A Service is a stable virtual IP and port that load-balances across a set of Pods. It is implemented at L4 by kube-proxy-or, in modern eBPF-based clusters, by the CNI directly (Cilium replaces kube-proxy entirely).
Modes:
iptables (default): kube-proxy programs iptables DNAT rules. O(N) match per packet; degrades with many Services.
IPVS: kube-proxy programs the kernel IPVS load balancer. O(1) lookup; better for >1000 services.
eBPF (Cilium): bypasses iptables entirely; programs are attached at the socket layer (bpf_sock_ops) and at the egress point. Lowest overhead.

EndpointSlices replaced Endpoints in 1.21+: split per-Service endpoint lists into multiple objects to scale beyond ~1000 endpoints per Service.
Service types: ClusterIP (default, internal), NodePort (open a port on every node), LoadBalancer (cloud LB integration), ExternalName (DNS CNAME).
Headless Services (clusterIP: None): no virtual IP; DNS returns Pod IPs directly. Used by StatefulSets.
Topology-aware routing: prefer endpoints in the same zone (since 1.27 stable). Saves cross-zone egress costs.
Service IPs are virtual: no NIC has them; they live only in iptables/IPVS/eBPF rules.

Create a Service + Deployment. From a Pod, curl <service>.<ns>.svc.cluster.local. Trace the DNS lookup (CoreDNS) and the iptables/IPVS rules that DNAT.
Switch kube-proxy to IPVS mode (mode: ipvs in kube-proxy config). Verify with ipvsadm -L -n.
Install Cilium with kubeProxyReplacement=true. Observe kube-proxy not running. Verify Service connectivity still works.
Compare per-packet latency under each mode with a small benchmark.

Enable topology-aware routing to keep traffic in zone. Apply NetworkPolicies (next month) that allow only intended traffic.

Wire kubeproxy_sync_proxy_rules_duration_seconds. With many Services and iptables mode, this can take seconds-a known scale ceiling.