Kubeletosaurus Wrecks: When Memory Requests Meet Limits!
summary
Cloned the Kubernetes repo and traced Go code (SyncPod, kubelet.containerRuntime, containerRuntimeManager) plus containerd/CRI to prove that kubelet mostly only sets memory bytes in the container config while the container runtime (containerd, crictl-style adapters) actually enforces limits and runs the sandbox/container. Discovered static pod mirror handling, imagePuller, and runPodSandbox calls. Notable: memory requests were historically only used for scheduling, and kubelet began reserving request memory via cgroups around v1.26.
AI-written summary · about
chapters (11)
- 0:00Kubeletosaurus Wrecks intro
- 1:24Speaker intro
- 2:07Motivation
- 3:12Kubernetes memory limits source
- 5:23Kubelet pod startup
- 9:43Container Runtime Interface and sandboxing
- 14:43Pod sandbox
- 16:30Container startup limits
- 19:16Runtime enforcement
- 19:59Key learnings
- 21:24Q&A
related talks
47mOptimizing Kubernetes Resource Requests/Limits for Cost-Efficiency and Latency
39mStaying in Tune: Optimize Kubernetes for Stability and Utilization
36mKubernetes Confessions: Real Mistakes We’ve All Made (and What They Teach Us)
36mTaming the Beast: Advanced Resource Management With Kubernetes
35mDefusing the Kubernetes API Performance Minefield
24mResource Requests and Limits Under the Hood: The Journey of a Pod Spec
34mLoad Testing Kubernetes: How to Optimize Your Cluster Resource Allocation in Production
34mReading 100+ Kubernetes Post-Mortems - lessons learned