Resource requests/limits
Il modo di specificare in Kubernetes il fabbisogno di CPU e memoria di un container. Request = ciò che il pod ha garantito (usato per lo scheduling); limit = il tetto che non può superare. Lo scarto tra i due determina stabilità, costi e il trattamento del pod sotto pressione sulle risorse.
Il funzionamento: lo scheduler colloca un pod su un nodo che ha spazio per le sue request (la somma delle request non può superare la capacità del nodo). I limit sono imposti dal kernel: un container che supera il limite di CPU viene rallentato (throttling), uno che supera il limite di memoria viene terminato per OOM. Impostare request < limit significa fare overcommit (il nodo promette più di quanto ha, se tutti vanno al massimo insieme): flessibile ma rischioso. Questo determina anche la classe QoS: request=limit → Guaranteed (terminato per ultimo), solo request → Burstable, niente → BestEffort (terminato per primo). Valori sbagliati sono una delle cause più comuni di instabilità (limite di memoria troppo basso → ciclo di OOM) e di spreco (request troppo alta → capacità inutilizzata). Fondamentale per qualsiasi gestione di Kubernetes. Imparentato con QoS class e Vertical Pod Autoscaler.