Народ, а если слейв умрет вместе с процессами, процессы запустятся на других слейвах?

ну в смысле, это автоматизировано?

да

мастер лишь бы жил

а waiting тож имеется, как в месосе?

если мощности не хватает под процесс т.е., он находится в режиме ожидания для запуска

https://github.com/kubernetes/kubernetes/issues/2385

чтобы сделать как прям в мезосе я не знаю

под мы запускаем вообще не указывая что у него по ресурсам

как кубернетес поймёт что мощности не хватает яхз

но если он запустить не сможет то будет ретраить

система выглядит конечно так себе)

зато работает

в отличие от

)

наверняка можно все это

но я пока не сталкивался с ситуациями когда это надо

вообще мощность сервиса некоего посчитать непросто и обычно это отбалды и примерно. зато эта штука умеет скейл

а если нет серверных мощностей то какой смысл в кубернетес

модно стильно молодёжно?

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

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

не разберется, магию отменили ещё до первого пришествия

это обычные докер контейнеры и относиться к нам надо как к обычным докер контейнерам, обмазанным удобными штуками и тулзами

под мы запускаем вообще не указывая что у него по ресурсам

эм, requests / limits?

опциональные попугаи

пф

мало чего общего имеющие с ревльностью

пф

One cpu, in Kubernetes, is equivalent to: 1 AWS vCPU1 GCP Core1 Azure vCore1 Hyperthread on a bare-metal Intel processor with Hyperthreading

и чего

aws оверкоммитит много

ну все

это нельзя сравнивать с интел процессор на бареметал

из-за aws сворачиваем лавочку

зачем?

это маркетинговый булщит

простите, забыл бумажку с надписью sarcasm на работе

вот вам типа лимиты

если разговор шел за указание ресурсов - то вот они

если cpu shares отличается от желаемого, то я не понимаю, в чем еще считать, потому что условные гигагерцы тоже никогда не дадут абсолютного значения

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

да это обычные cgroups

ура

которые так себе работают

что значит "так себе"?

не работают они. это маркетинговый булщит. есть ещё математика оверкоммита в ядре

яснопонятно. пойду своими делами заниматься. aws плохо, запомнил, хорошо.

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

а мог бы жить, ядро там само разберется

вернулся от своих дел. это, напомню, мы начали с того, что лимитов нет.

я думаю, это вполне очевидно при задании лимита, что пробивать его нельзя.

пойду дальше своими делами заниматься все-таки

лимиты есть но они на. бумажке работают. в жизни от них толку нет особо

в openvz все более менее ещё работало

cgroups это попугаи имхо

лимиты есть но они на. бумажке работают. в жизни от них толку нет особо

работают они.

Currently, one unit of CPU means different things on different cloud providers, and on different machine types within the same cloud providers. For example, on AWS, the capacity of a node is reported in ECUs, while in GCE it is reported in logical cores. We plan to revise the definition of the cpu resource to allow for more consistency across providers and platforms.

работают

так и пишут

aws виноват

Currently, one unit of CPU means different things on different cloud providers, and on different machine types within the same cloud providers. For example, on AWS, the capacity of a node is reported in ECUs, while in GCE it is reported in logical cores. We plan to revise the definition of the cpu resource to allow for more consistency across providers and platforms.

А на железе, интересно?

на железе должно быть похоже на правду

мои эксперименты ни к чему хорошему не привели)

надо настраивать оверкоммитит

https://github.com/kubernetes/kubernetes/issues/168

ERROR: S client not available

А кто-нибудь прописывает для каждого контейнера требования к памяти?

Реквесты почти для каждого пишем. Лимиты для всего кроме критичных jvm приложений.

Но с лимитами просто приходит oom killer и всё

Что такое oom killer?

Что такое oom killer?

функция ядра ОС, которая препятствует ситуации, когда программы занимают больше памяти, чем ее физически есть. Обычно ООМ тупо убивает малоиспользуемые процессы

Спасибо за понятное разьяснение

А ещё кто-нибудь кроме Виталия прописывает лимиты?

для горизонтального скейлинга это нужно, насколько я помню

прописывал, когда его тестировал

Круто :)

https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubernetes-part-iv-continuous-deployment-via-traffic-shifting/

кто-нибудь знает как для GKE включить альфа-фичи?

хочется с ScheduledJob поиграться

gcloud alpha container clusters create cluster-name —enable-kubernetes-alpha

забыл уточнить "для существующего кластера"

https://cloud.google.com/container-engine/docs/clusters/operations#create_an_alpha_cluster

никак

а что мешает еще поднять?

ну вот это я читал... жаль но ок

а зачем мне еще поднимать если мне в текущем кластере функционал нужен, да и на компы новые тратиться не хочется

кстати, еще вопрос в сабж: у кого-нибудь есть опыт с хостингом в китае, или развертывании приложений на сервисах доступных из-за китайского фаервола?

а зачем мне еще поднимать если мне в текущем кластере функционал нужен, да и на компы новые тратиться не хочется

ты хочешь конвертнуть в альфу боевой, чтоб через 30 дней его удалили?

оу, а я не знал что удаляют

че за фигня вообще )

и СЛА по альфа кластерам нет

я думал апи просто дополняется новыми фичами

никто не будет за альфа функции подписываться

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

на то они и альфа

ладно, ты меня убедил,)

:)

Зато в админке теперь альфа кластера отдельно отображаются :) ну и вообще - до 1.5 совсем немного потерпеть осталось