What are your comments on the following links below: - https://github.com/kubernetes/kubernetes/issues/51135 https://github.com/kubernetes/kubernetes/issues/51

What are your comments on the following links below: - https://github.com/kubernetes/kubernetes/issues/51135 https://github.com/kubernetes/kubernetes/issues/51135 - https://github.com/libero/reviewer/issues/1023 https://github.com/libero/reviewer/issues/1023 - https://medium.com/@betz.mark/understanding-resource-limits-in-kubernetes-cpu-time-9eff74d3161b https://medium.com/@betz.mark/understanding-resource-limits-... - https://medium.com/omio-engineering/cpu-limits-and-aggressive-throttling-in-kubernetes-c5b20bd8a718 https://medium.com/omio-engineering/cpu-limits-and-aggressiv... This doesn't seem as dangerous as is being suggested -- and in a world with the kernel bug and some separation of workloads it seems very viable. Obviously, in a world without the kernel bug it makes much less sense to not set limits, but as far as scheduling goes, well-set requests (+/- a VPA[0]), with a HPA[1] should be enough to handle sudden increases in scale, and for truly large increases that are a complete surprise (otherwise you could have planned for it) elastic infrastructure via a cluster autoscaler[2]. [0]: https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler https://github.com/kubernetes/autoscaler/tree/master/vertica... [1]: https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale https://kubernetes.io/docs/tasks/run-application/horizontal-... [2]: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler https://github.com/kubernetes/autoscaler/tree/master/cluster...