А зачем тогда вообще можно деплоить поды без лимитов и тем более реквестов?

это ко мне вопрос? я так никогда не делаю

так наоборот если наплевать то надо лмимты ставить

иначе такой прекрасный под может выжрать все 32 гига оперативы

какой-нибудь kube-ops-view заландовский который течет хуже пхп

конечно если мы хостинг какой и реселлим цпу и память то надо оверкоммит делать но если мы в своем кластере свои ворклоады гоняем - я пока не знаю кейса зачем делать requests != limits

если приложение знает про cgroups, то requests != limits вполне подходит

иначе такой прекрасный под может выжрать все 32 гига оперативы

а то и все 256

если приложение знает про cgroups, то requests != limits вполне подходит

можно поподробнее чем это поможет?

можно поподробнее чем это поможет?

подсказывать приложению heap size, ms / mx в жабе

хорошо, тогда почему не поставить requests=limits=(heap zise + XХмб на бинари и файловый кеш)?

хорошо, тогда почему не поставить requests=limits=(heap zise + XХмб на бинари и файловый кеш)?

в чем будет профит от requests < limits

в чем будет профит от requests < limits

overcommited

У меня нормально все живет при 150% на память и 200% на cpu

а без оверселла не работает?

не уверен, что понял вопрос. Без overcommited много свободных ресурсов

почему?

потому что приложений постоянно разная нагрузка. В среднем они жрут вместе 60-70% ресурсов, а в сумме 150% примерно по лимитам. Пики активности крайне редко совпадают.

а теперь давай представим что у тебя есть автоскейлеры

addon-resizer и hpa

у меня их нет 😁

ну вот представь что есть

тебе всё ещё надо оверселлить?

Мне нужно ушатать прилично времени, чтобы настроить автоскейл. Набить шишки и тп. Пока меня устраивает стабильность оверсейла. Она бесплатна.

Наверное, ответ кроется в более ответственном анализе ресурсов кластера, постоянном мониторинге, а также грамотной настройке HPA.

Затем же почему в линуксе есть sysctl vm.overcommit_memory - потому что не все что просят используют

Мне нужно ушатать прилично времени, чтобы настроить автоскейл. Набить шишки и тп. Пока меня устраивает стабильность оверсейла. Она бесплатна.

в смысле "ушатать"? вот прям щас свои лимиты впиши в аннотации и оператором настрой автоскейлеры

https://github.com/banzaicloud/hpa-operator вот этим

хмм а зачем оператор?

HPA и так работают

и надо их делать по кастомным метрикам

А чем это отличается кроме того, что возникнет бойня за ресурсы, если пики совпадут?

чтобы не самому hpa создавать, а аннотации

бареметал или облако?

https://github.com/banzaicloud/hpa-operator вот этим

я попробую, может зря делаю так.

pod.hpa.autoscaling.banzaicloud.io/custom_metric_name

бареметал или облако?

baremetal

удобнее же и проще

в облаке - за счет cluster autoscaler нод будет меньше-больше в зависимосте от нагрузки

удобнее же и проще

у меня было мнение - autoscale нужен только для облака.

в бареметал наверное только если разные приложения с разными паттернами нагрузки

есть автоскейл кластера (кол-во нод), есть автоскейл подов (реплик), есть авторесайз контейнеров (лимитов)

это разные скейлеры

вот про авторесайз лимитов не знал O_O

гляну

и все полезные

авторесайз лимитов это addon-resizer

я сейчас руками выгоняю ненужные апы, если пригорает. Похоже зря

ресайз лимитов это вертикал автоскейлер?

я юзал в виде addon-resizer

VPA не юзал

но вроде оно должно быть примерно то же

я сейчас руками выгоняю ненужные апы, если пригорает. Похоже зря

для этого в 1.11 кажется добавили приорити же (а до этого были критикал под аннотации)

для этого в 1.11 кажется добавили приорити же (а до этого были критикал под аннотации)

я пока не дошел совсем до auto eviction

я юзал в виде addon-resizer

а в чем профит? кроме того чтобы новому приложению поставить с потолками лимит и потом подобрать ему подходящий

Vertical Pod Autoscaler should not be used with the Horizontal Pod Autoscaler (HPA) on CPU or memory at this moment. However, you can use VPA with HPA on custom and external metrics.

а в чем профит? кроме того чтобы новому приложению поставить с потолками лимит и потом подобрать ему подходящий

оно вниз тоже ресайзит

в итоге VPA потом выкидуешь и ставишь лимиты которые подобрал на постоянку

ну а толку

в итоге VPA потом выкидуешь и ставишь лимиты которые подобрал на постоянку

потом девелоперы надевелопили и опять подключать?

пусть уж лучше само

а как ещё HPA зать?

или ты будешь в проде 1 реплику гонять?

один хрен надо убирать

при чём тут реплики?

а смысл иметь больше 1 реплики (ну вернее 2 для HA) и не иметь HPA?

Плохо скейлящиеся горизонтально базы данных.

На выделенных нодах.

хорошо, вот положич вместое статического лимита впилили VPA такой базе, дальше что? будем такой dense packing делать чтобы потом из-за VPA скейлящего вврехи другие поды с этой ноды перезжали?

и что хорошего нам это принесет?

один хрен надо убирать

какбудточтотоплохое. VPA на стейдже подбирает значения, HPA на проде скейлит как надо

хорошо, вот положич вместое статического лимита впилили VPA такой базе, дальше что? будем такой dense packing делать чтобы потом из-за VPA скейлящего вврехи другие поды с этой ноды перезжали?

VPA не трогает limits, только requests

какбудточтотоплохое. VPA на стейдже подбирает значения, HPA на проде скейлит как надо

ну вот так я и говорил что норм

а со стратегией Initial и вместе с HPA будет работать на проде

VPA не трогает limits, только requests

хмм тогда тем более что будет когда VPA ползет вверх?

хмм тогда тем более что будет когда VPA ползет вверх?

зависит от режима - https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start

> "Auto": VPA assigns resource requests on pod creation as well as updates them on existing pods using the preferred update mechanism. Currently this is equivalent to "Recreate" > "Recreate": VPA assigns resource requests on pod creation as well as updates them on existing pods by evicting them when the requested resources differ significantly from the new recommendation (respecting the Pod Disruption Budget, if defined).

жесть какая-то

т.е. если не initial то вообще под рестартанет на другой ноде?

> This mode should be used rarely, only if you need to ensure that the pods are restarted whenever the resource request changes. Otherwise prefer the "Auto" mode which may take advantage of restart free updates once they are available. NOTE: This feature of VPA is experimental and may cause dowtime for your applications.

или на той же но с новым лимитом?

так или иначе для > Плохо скейлящиеся горизонтально базы данных. очень плохая идея

когда обе стороны ознакомились с документацией в споре появятся новые доводы, интересно!