I get that, still needed to check to be sure
It seems to have resolved on its own for some reason. Quick question, by default, will every pod be a burstable class?
Only if your limits are different to your requests. If you explicitly set requests == limits, they’ll be Guaranteed QoS.
https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-resource-requests#resource-limits
But that’s weird that it resolved itself, did you do anything differently to the first time?
No, nothing at all. Was waiting for updates here.
@rehan2 so the defaulting happened because the workload in the doc had a nodeSelector and a toleration, which means that it uses workload separation. Autopilot enforces higher minimums (500m CPU) for workload separation (see https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-resource-requests#workload-separation). So it was working as intended. We’ll update the doc to remove that from the manifest, since the example Pod’s requests are <500m CPU.
1 Like
@rehan2 just closing it off here, updated https://cloud.google.com/kubernetes-engine/docs/how-to/pod-bursting-gke#deploy-burstable-workload so that the manifest doesnt use workload separation