Наверное не в тему , но, есть у кого опыт обращения в ТП гугла? успешный опыт?

нет единого "саппорта гугла"

ясно...я просто кинул запрос, но сутки прошло и тишина. даже на почту не пришло отписки типа: чувак твое обращение номер такой-то

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

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

по почте день-два и вообще немного не в том чате пишешь, куб тут не в тему

а есть линк. где можно спросить?

Наверное не в тему , но, есть у кого опыт обращения в ТП гугла? успешный опыт?

У гугла самый "лучший" саппорт в мире

У гугла самый "лучший" саппорт в мире

Бареметал не автоскейлится, сколько на него прайвет-клауд не ставь

Виртуалки это хорошо. Скажем если железка жирная, лучше ее нарезать на виртуалки и добавить как несколько нод, чтобы подов на каждом кублете и докере меньше было

У тебя докер прогибается от количества контейнеров?

если привязываться к конкретным цифрам, то скорее "лучше 100 контейнеров чем 200" - и тогда уже речь идет о том чтобы ставить побольше менее жирных воркеров

Зато когда у тебя одна система на все контейнеры, будет дикая конкуренция за syscalls, ядро отожрет приличную часть CPU и все контейнеры начнут нехило тормозить

>конкуренция за syscalls Что?

Ну когда в ядре глобальные локи берутся. Если ядер много, то локов больше можно взять. За последний десяток лет много локов распилили на более мелкие, но намерить общее ускорение от работы на нескольких ядрах мне кажется можно если постараться

Ну когда в ядре глобальные локи берутся. Если ядер много, то локов больше можно взять. За последний десяток лет много локов распилили на более мелкие, но намерить общее ускорение от работы на нескольких ядрах мне кажется можно если постараться

>конкуренция за syscalls Что?

С множеством виртуалок гипервизор ещё ресурсы жрать будет, да и глобал-локи в хост-ядре никто не отменял

У корабля вес тоже увеличивается от перегородок, но ведь ставят же чтобы от одной дырки все судно ко дну не пошло :)

https://sysdig.com/blog/container-isolation-gone-wrong/

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

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

Это да. Но что лучше, 12 дешёвых железных нод или 3 ноды железных с 12 виртуалками?

Конечно 12 железных нод :) но кто их даст. Дают монстров

Конечно 12 железных нод :) но кто их даст. Дают монстров

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

А чем ты qemu менеджишь?

меряли уже кучу раз, что докер что KVM могут ~200 виртуалок\контейнеров создать

Я не менеджу. Все VMware делает и проблем не видел :)

Мы клиентам как раз диктуем дешёвые железные (или VM'ки небольшие в облаках). И получается, вроде, лучше.

по факту сейчас можно делать и больше, но есть особенности

Господа, подскажите, есть какое-то рациональное объяснение ограничению по умолчанию в 110 подов на ноду?

Какие? при max-pods > 254 упрусь в нехватку адресов для подов, вероятно?

Какие? при max-pods > 254 упрусь в нехватку адресов для подов, вероятно?

Какие? при max-pods > 254 упрусь в нехватку адресов для подов, вероятно?

Чисто логически толстый сервер дешевле кучки тонких (если тонкие - со своими корпусами и т.д., а не блейды). Откуда выгода?

недавняя статья

Девопсы ахнули! Докер ЗАГНУЛСЯ, когда на машине ОБРАЗОВАЛОСЬ 4000...

Потому что есть ещё операционные затраты. И размещать куб сразу, чем городить VM абстракцию во многих наших кейсах получается проще.

если у тебя /24 на хост, то да, но есть и другие особенности у фланта на хабре была статья про баги и особенности кубеней

Это та, где в багах был OOM killer?

Так уменьшение таких затрат основная фишка аутсорса же, нет? 1 раз скрипты написали - многим клиентам продали, выгодно. Тот же rhevm разворачивается ансиблом полностью

и avito в докладе говорили, что kubelet нестабильно себя ведет на 110+. Им пришлось резать железные сервера на виртуалки.

Однозначно. Тем и занимаемся. :3

Ну вот и получается: клиент берет жирные 2-4 башковые серверы, вы туда ансиблом выкатываете виртуалки, в них каким-то, какой у вас там наверняка уже наработан, инструментом куб. Для клиента 1 ядро выходит дешевле, чем по вашей текущей схеме "много мелких железных серверов"

Ну вот и получается: клиент берет жирные 2-4 башковые серверы, вы туда ансиблом выкатываете виртуалки, в них каким-то, какой у вас там наверняка уже наработан, инструментом куб. Для клиента 1 ядро выходит дешевле, чем по вашей текущей схеме "много мелких железных серверов"

Scale out! Деньги смешные получаются, отказоустойчивость у 12 маленько-средних серверов при должно настроенных приложениях гораздо выше.

"Должно настроенные приложения" это хорошо, но обычно бизнесу фичи подавай, а на качество кода и должную настройку не находится времени

Надеюсь не опенстек ради 12 виртуалок

ЫНТЫРПРАЙЗ

К счастью, stateless, который и пишут клиенты, без проблем ложится без каких-либо глубоких особенностей. А за stateful базы и прочее, — это уже не клиент, экспертизы больше.