Compute, Kubernetes and the kernel

The chapter that separates people who deploy to Kubernetes from people who operate it. Most of the questions here have a counter-intuitive right answer: removing CPU limits can improve latency, a pod can be healthy and slow for five different reasons, and the JVM will get itself OOMKilled if you size the heap to the container limit.

Underneath is the kernel. Knowing what a container actually is (namespaces plus cgroups plus a union filesystem, not a lightweight VM) and being able to name eBPF as an observability tool are two of the cheapest staff-level signals available.

What this chapter covers

• [done] CPU limits and CFS throttling
• [todo] Lambda cold start anatomy and the levers that shorten it
• [todo] The serverless vs containers cost crossover, with the math
• [todo] Namespaces and cgroups v2, hands-on
• [todo] Container security primitives: seccomp, capabilities, read-only root
• [todo] runc vs gVisor vs Firecracker vs Kata
• [todo] The reconciliation loop as the Kubernetes mental model
• [todo] Requests, limits, QoS classes and eviction order
• [todo] HPA, VPA, Cluster Autoscaler, Karpenter, KEDA
• [todo] kube-proxy modes and why iptables degrades at scale
• [todo] NetworkPolicy and service mesh authorization
• [done] A pod is healthy but slow
• [todo] The ndots:5 DNS latency classic
• [todo] Memory: page cache, major vs minor faults, huge pages, NUMA, the OOM killer
• [todo] I/O models: blocking, epoll, io_uring, and zero-copy
• [done] Where fsync fits in durability
• [todo] TCP: TIME_WAIT, accept queues, Nagle, BBR, conntrack exhaustion
• [done] eBPF for intermittent latency
• [todo] USE and RED, and the tooling for each
• [todo] JVM in a container: heap sizing, GC choice, async-profiler
• [done] Serverless or containers: walk the math

Source: §19, §40.1.