Я думаю, что вы не поняли Запросы против ограничений , я бы порекомендовал вам взглянуть на документы , прежде чем вы примете это решение.
В кратком объяснении
Запрос означает, сколько ресурсов будет фактически выделено для контейнера, это гарантия того, что вы можете использовать его, когда вам нужно, не означает, что он остается зарезервированнымисключительно в контейнер.С учетом вышесказанного, если вы запрашиваете 200 МБ ОЗУ, но используете только 100 МБ, остальные 100 МБ будут «заимствованы» другими контейнерами, когда они будут использовать всю запрошенную память, и будут «возвращены», когда ваш контейнер будет нуждаться в этом.
Limit - это простые термины, определяющие, сколько контейнер может потреблять, запрашивать + заимствовать у других контейнеров, прежде чем он отключится из-за чрезмерного потребления ресурсов.
- Если контейнер превышает свою память limit , вероятно будет прерван.
- Если контейнерпревышает его память запрос , вероятно , что его Pod будет удален всякий раз, когда узлу не хватает памяти .
Проще говоря, предел является абсолютным значением, он должен быть равен или превышать запрос , и эффективная практика заключается в том, чтобы не превышать пределы, превышающие запрос для всех контейнеров,только в тех случаях, когда это может понадобиться определенным рабочим нагрузкам, это связано с тем, что большинство контейнеров может потреблять больше ресурсов (т. е. памяти), чем они запрашивали, внезапно POD начнут вытесняться с узла непредсказуемым образом, что ухудшает егоесли для каждого из них установлен фиксированный лимит.
В документации докера также есть хороший пост об ограничениях ресурсов.
Правило планирования то же самое для процессора и памяти, K8s назначит POD узлу, только если у узла достаточно ЦП и памяти, выделяемой для размещения всех ресурсов , запрошенных контейнерами в модуле.
Выполнение правило немного отличается:
Память - это ограниченный ресурс в узле, а емкость - абсолютный предел, контейнеры не могут потреблять больше, чем узел имеет емкость.
ЦПс другой стороны, измеряется как время ЦП, когда вы резервируете емкость ЦП, вы указываете, сколько ЦП может использовать контейнер, если контейнеру требуется больше времени, чем запрошено, его можно регулировать и переходить в очередь выполнения додругие контейнеры использовали отведенное им время или закончили свою работу.В целом, это очень похоже на память, но очень маловероятно, что контейнер будет уничтожен из-за чрезмерной загрузки ЦП.Контейнер сможет использовать больше ЦП, если другие контейнеры не используют выделенное им полное ЦП.Основная проблема заключается в том, что когда контейнер использует больше ЦП, чем было выделено, регулирование приведет к снижению производительности приложения и в определенный момент может перестать работать должным образом.Если вы не предоставите ограничения, контейнеры начнут влиять на другие ресурсы в узле.
Относительно используемых значений нет правильного значения или правильной формулы, каждое приложение требует своего подхода, измеряя только несколькоЕсли вы можете найти правильное значение, совет, который я вам даю, - определить минимальное и максимальное значения и отрегулировать их где-то посередине, а затем продолжать следить за тем, как они себя ведут, если вы чувствуете, что тратите \ не хватает ресурсов, которые можете уменьшить \увеличить до оптимального значения.Если сервис является чем-то важным, начните с более высоких значений и затем уменьшайте их.
Для проверки готовности вы не должны использовать его в качестве параметров для указания этих значений, вы можете отложить готовность, используя параметр initialDelaySeconds в зонде, чтобы дать дополнительное время для запуска контейнеров POD.
PS: я процитировал термины «Заимствовать» и «Возврат», потому что контейнер фактически не заимствован у другого контейнера, в общем, у узла есть пул памяти, и он дает вам часть памяти для контейнера, когда онинужно, чтобы технически память не была заимствована из контейнера, а из пула.