3 ms·

The argument against this is consistency. Without a limit set, you are only guarenteed up to your request's worth of cpu, but you will often be allowed to have

The argument against this is consistency. Without a limit set, you are only guarenteed up to your request's worth of cpu, but you will often be allowed to have more. This can create a false sense of security, as your application is working fine (even though it occasionally exceeds its request). Until one day, when a neighbor happens to get thirsty, and your application suddenly breaks. Limits front-load the brokenness so that it happens immediately instead of randomly.

stingraycharles 4y ago
It’s a trade-off that needs to be considered on a case-by-case basis. This is one of those cases where “one rule fits all” doesn’t work.
zufallsheld 4y ago
> Until one day, when a neighbor happens to get thirsty, and your application suddenly breaks. Limits front-load the brokenness so that it happens immediately instead of randomly. Can you expand on this? Why should the application break? It still has its guaranteed cpu requests. If it breaks with the defined requests, shouldn't it always break?
- kobalsky 4y ago
  Not op, but it would break because your CPU request wasn't high enough from the start and the problem was hidden because you had CPU to spare in the node. Once you don't have CPU to spare, the app breaks. EDIT: the vertical pod autoscaler helps with this as it will adjust requirements on pods to make sure they don't over/under allocate.
  - dilyevsky 4y ago
    Solution - monitor your apps for when usage is consistently over request
- sascha_sl 4y ago
  I've had this happen in the real world. In this case it was a GraphQL implementation that gradually grew in size, complexity and scope. The team maintaining it never adjusted the initial resource requirements within about 2 years because it has never been a problem - until a different (much larger by total CPU allocated) service started consuming all the bursting it could get and the GraphQL service just stopped processing requests. Before any autoscaling could kick in, it went into CrashLoopBackoff with failing liveness. You can and should catch such cases early with monitoring, but our platform team was extremely tiny, especially for how many developers it served.

stingraycharles 4y ago

It’s a trade-off that needs to be considered on a case-by-case basis. This is one of those cases where “one rule fits all” doesn’t work.

zufallsheld 4y ago

> Until one day, when a neighbor happens to get thirsty, and your application suddenly breaks. Limits front-load the brokenness so that it happens immediately instead of randomly. Can you expand on this? Why should the application break? It still has its guaranteed cpu requests. If it breaks with the defined requests, shouldn't it always break?

kobalsky 4y ago
Not op, but it would break because your CPU request wasn't high enough from the start and the problem was hidden because you had CPU to spare in the node. Once you don't have CPU to spare, the app breaks. EDIT: the vertical pod autoscaler helps with this as it will adjust requirements on pods to make sure they don't over/under allocate.
- dilyevsky 4y ago
  Solution - monitor your apps for when usage is consistently over request
sascha_sl 4y ago
I've had this happen in the real world. In this case it was a GraphQL implementation that gradually grew in size, complexity and scope. The team maintaining it never adjusted the initial resource requirements within about 2 years because it has never been a problem - until a different (much larger by total CPU allocated) service started consuming all the bursting it could get and the GraphQL service just stopped processing requests. Before any autoscaling could kick in, it went into CrashLoopBackoff with failing liveness. You can and should catch such cases early with monitoring, but our platform team was extremely tiny, especially for how many developers it served.