Resource requests/limits
Hoe in Kubernetes de CPU- en geheugenbehoefte van een container wordt opgegeven. Request = wat de pod gegarandeerd krijgt (voor scheduling); limit = het plafond dat niet overschreden mag worden. Het verschil ertussen bepaalt stabiliteit, kosten en hoe de pod onder druk wordt behandeld.
Werking: de scheduler plaatst een pod op een node met ruimte voor de requests (de som van de requests mag de capaciteit van de node niet overschrijden). Limits worden door de kernel afgedwongen: overschrijdt een container zijn CPU-limit, dan wordt hij gethrottled; overschrijdt hij zijn geheugenlimit, dan wordt hij OOM-killed. Request < limit betekent overcommitment (de node belooft meer dan hij heeft als iedereen tegelijk piekt) — flexibel maar riskant. Dit bepaalt ook de QoS-klasse: requests=limits → Guaranteed (als laatste gekilld), alleen requests → Burstable, niets → BestEffort (als eerste gekilld). Verkeerde waarden zijn een van de meest voorkomende oorzaken van instabiliteit (te lage geheugenlimit → OOM-lus) en verspilling (te hoge request → ongebruikte capaciteit). Fundamenteel voor alle Kubernetes-beheer. Verwant aan QoS-klasse en vertical pod autoscaler.