Size: a a a

2019 February 20

ZO

Zon Orti in gcp_ru
Zlokot
я видел этот минимум и максимум в настройках кластера.
3 и 90
кластер не я создавал. прошлых админов не найти.
информации про ресурсы тоже нету.
чОрный ящик короче.
но надо скейлить.
так что еще раз - есть задача пока мониторить текущее и пытаться увеличивать нагрузку чтобы понять сколько ему надо будет
Почитай про HPA и VPA, посмотри на текущие значения
источник

Z

Zlokot in gcp_ru
ок, спасибо
читаю
источник

ZO

Zon Orti in gcp_ru
На что действительно нужен алерт - это когда кластер не может больше ноды добавлять, тогда уже наверное стоит вмешаться.
источник

Z

Zlokot in gcp_ru
ну ведь за этот автоматический скейлинг до указанного максимума в настройках кластера - прийдется платить больше, так?
источник

Z

Zlokot in gcp_ru
вот сейчас у меня три ноды и я плачу к примеру 100 баксов.
счас настрою кол-во подов х2 и что?
поды увеличатся, для них вырастет нужное кол-во нод и чек приедет уже на 300 баксов
источник

ZO

Zon Orti in gcp_ru
Ну - больше нод, больше стоимость, меньше нод - меньше стоимость
источник

Z

Zlokot in gcp_ru
что плохого в том, что я об этом как-бы заранее узнаю, а не в момент чарджа
источник

Z

Zlokot in gcp_ru
у меня и стоит задача - мониторить лоад, чтобы спрогнозировать будущий прайс
источник

Z

Zlokot in gcp_ru
2-3 дня потестирую, пойму на сколько оно вырастает и дам ответ - при скейлинге увеличится оплата в 3 раза.
все.
источник

Z

Zlokot in gcp_ru
ну план примерно такой
источник

ZO

Zon Orti in gcp_ru
Zlokot
2-3 дня потестирую, пойму на сколько оно вырастает и дам ответ - при скейлинге увеличится оплата в 3 раза.
все.
Просто на метрики смотри, почта тут излишек
источник

Z

Zlokot in gcp_ru
ну блин все равно не понимаю - чем алерты то помешают?
источник

A

Andor in gcp_ru
алерты подразумевают что на них надо как-то реагировать человеку
источник

Z

Zlokot in gcp_ru
так для того и делаю
источник
2019 February 21

Z

Zlokot in gcp_ru
смотрю на метрики для ресурса Kubernetes Container:

Memory limit:
Metric: kubernetes.io/container/memory/limit_bytes
Description: Memory limit of the container in bytes.

и

Memory limit utilization:
Metric: kubernetes.io/container/memory/limit_utilization
Description: The fraction of the memory limit that is currently in use on the instance. This value cannot exceed 1 as usage cannot exceed the limit.

и другая пара метрик:

Memory request:
Metric: kubernetes.io/container/memory/request_bytes
Description: Memory request of the container in bytes.

и

Memory request utilization:
Metric: kubernetes.io/container/memory/request_utilization
Description: The fraction of the requested memory that is currently in use on the instance. This value can be greater than 1 as usage can exceed the request.


можете человеческим языком объяснить в чем разница?

потому что например выбрав метрику Memory request, я могу в фильтре выбрать нужный мне контейнер, но для метрики Memory request utilization этого контейнера нет в списке. все другие есть, а нужного мне нету.

тоже и для memоry limit.
источник

AK

Andrey Kartashov in gcp_ru
лимит/запрос и утилизация в процентах от лимита/запроса, что непонятно?
источник

AK

Andrey Kartashov in gcp_ru
лимит и запрос берутся из описания контейнера в поде. Утилизация должна кем-то собираться, может быть недоступна на какой-то период времени
источник

Z

Zlokot in gcp_ru
То есть лимит и запрос - это по сути константа?
источник

Z

Zlokot in gcp_ru
И если нужно мониторить изменения, то надо смотреть на утилизацию
источник

ZO

Zon Orti in gcp_ru
Zlokot
То есть лимит и запрос - это по сути константа?
VPA меняет их, а HPA меняет колличество подов
источник