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

Source: §19, §40.1.