networking • Advanced

Kubernetes Services & kube-proxy Packet Routing (iptables vs IPVS)

Since Pod IPs are ephemeral and change upon restart, a Service provides a stable virtual ClusterIP and DNS name, load-balancing traffic across matching Pod endpoints via kube-proxy iptables/IPVS rules.

Intuitive Mental Model

The Reception Desk & Call Center: Pods are individual call operators whose desks change every morning. The Service is the single toll-free telephone number (ClusterIP) that automatically distributes incoming calls to available operators (Endpoints).

Dockerfile / YAML Manifest / CLIProduction Standard

apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP # Internal virtual IP
  selector:
    app: api # Matches Pod labels
  ports:
  - protocol: TCP
    port: 80 # Service Port
    targetPort: 8080 # Container Port

# CoreDNS creates cluster internal DNS record:
# api-service.default.svc.cluster.local -> 10.96.0.42

Key Architectural Takeaways

•ClusterIP: Default virtual IP reachable only from within the Kubernetes cluster.
•NodePort: Exposes the Service on a static high port (30000-32767) on EVERY cluster node IP.
•LoadBalancer: Provisions a cloud load balancer (AWS NLB/ALB, GCP Cloud LB) routing to NodePorts.
•kube-proxy programs the Linux kernel iptables/IPVS packet filter tables on each node for layer-4 connection routing.

Common Production Mistake

Using large clusters with 5,000+ Services on legacy iptables mode, causing O(N) linear packet inspection latency degradation.