Lesson 69: Services & Networking — Exposing the Log Processing Platform

What We’re Building Today

By the end of this session, you will have shipped:

• A LoadBalancer Service fronting a Python FastAPI log-ingestion tier, reachable from outside the cluster on a stable external IP

• A ClusterIP Service mesh linking ingestion, query, and WebSocket-notification microservices internally, with Endpoints objects you can inspect and reason about directly

• A React analytics dashboard, served through its own Service, consuming both REST and WebSocket traffic through the same networking layer

• A working mental model of how kube-proxy, Endpoints/EndpointSlices, and cloud load balancer provisioning fit together — the piece most engineers can operate but can’t actually explain in an interview

Why This Matters

Every outage retro I’ve run at scale eventually touches Services. Not Deployments, not autoscaling — Services. The abstraction is deceptively simple: a stable virtual IP mapped to a dynamic set of Pods. But that simplicity hides the actual failure surface — selector drift, stale Endpoints during rollouts, load balancer provisioning latency, and the difference between what kubectl get svc tells you and what kube-proxy has actually programmed into iptables or IPVS on each node. Netflix and Spotify don’t run thousands of Services because they enjoy YAML; they run them because Services are the only construct that decouples “who am I talking to” from “where is it currently scheduled.” Get this layer wrong and every other pattern you build on top — HPA, mesh routing, canarying — inherits the fragility.

Kubernetes Architecture Deep Dive