A burstable Pod has resource limits higher than its requests, or has only partial resource specifications. Kubernetes guarantees the requested resources but may let the Pod temporarily use unused capacity from the node or other Pods. This makes bursting useful for variable workloads, while making performance dependent on where the Pod runs. section 5.1.2 section 5.2.2
Use the class with these operational consequences in mind:
- Set requests high enough for the workload to run reliably; treat additional capacity as temporary rather than guaranteed. section 5.1.2
- Test under both spare capacity and node contention, because a Pod can perform differently after rescheduling. section 5.1.2 section 5.2.2
- Expect protection from eviction unless usage exceeds requests for a noncompressible resource such as memory. section 5.1.2
Web application on changing nodes
A web application waiting on a database may use spare CPU cycles when its node is empty and handle bursts faster. After moving to a crowded node, it receives only its requested CPU, so performance can decline. Choose equal limits and requests when constant performance matters more than opportunistic capacity. section 5.2.2
