Реквесты - это то количество ресурсов, которое под занимает на ноде (воркере). Например, если у тебя нода на 1000 миллиядер CPU, 3 микросервиса, у которых в реквестах стоит по 400 миллиядер CPU - третий микросервис ни при каких условиях не встанет на эту Ноду, Кубернетес (scheduler) поставит третий микросервис на следующую Ноду. Можно представить себе стол, на котором теснятся 2 ноутбука, а ты хочешь положить третий - придется класть на второй стол.
Лимиты. Приложения в подах могут в моменте давать больше нагрузки, чем ты ожидаешь, например Java любит во время старта приложения выжирать всю CPU, которую только может. Если твое приложение стандартно кушает 400mi CPU, но на старте хочет кушать 2000mi, а ты поставишь лимит 400mi, оно будет подниматься минут 10. Поэтому ты можешь сделать реквест 400mi, а лимит 1000mi, чтобы на старте приложение поднялось за 2-3 минуты. Стоит отметить, что если приложение дойдет до лимита памяти - его убьет OOM Killer. Если приложение дойдет до лимита CPU - оно будет Троттлить (это снижение частоты процессора). Однако прикол в том, что Kubernetes вообще никак не мешает приложению выходить за рамки реквестов.
Здесь вытекает предположение: что если у меня Нода на 1000mi CPU, я поставил 2 микросервиса, с реквестом на 400mi CPU, лимитом на 1000mi CPU. Если у меня они оба упадут или упадет Нода, и они переподнимутся и начнут на старте выжирать свой максимум? То есть будут кушать 2000mi CPU, когда на Ноде всего 1000mi. Наверняка Ноде пополнеет и мб она даже снова упадет, поды уедут на другую Ноду, убьют ее и хана кластеру. - Ответ: маловероятно.
В Кубернетесе есть такое понятие как QoS (Quality of Service). Существует три типа QoS:
- Best Effort - такой класс присваивается, когда ты вообще не указываешь реквесты и лимиты;
- Burstable - данный класс будет присвоен, если лимиты и реквесты отличаются;
- Guaranted - когда лимиты и реквесты равны друг-другу.
Важно видеть разницу между этими классами, до нее можно дойти логически. Если у нас реквесты и лимиты равны друг-другу, то Под при любых обстоятельствах получит те ресурсы, которые мы ему предоставил, поэтому и класс Guaranted. Если у нас на ноде стоит под с request=limit=800 mi, и второй под без указания ресурсов, то при ситуации, когда Pod2 кушает 300mi, а Pod1 начал расти к 800, Кубернетес беспощадно будет душить Pod2 по ресурсам. Оно и логично - ведь ресурсы Pod2 не заказывал.
Аналогично происходит и с классом Burstable. По приоритету идут так Guarantesd > Burstable > Best Effort.
