Cgroup2 и java абсолютно совместимы с jdk15 (не хочу вас расстаривать но даже 8 версия java отлично работает с cgroup2). Смотрите - https://bugs.openjdk.org/browse/JDK-8230305
Из статьи следует что вы несколько лет не переходили на cgroup2 только из-за мнимой неподдежки cgroup2 в какой-то версии jdk или были ещё какие-то везкие причины не делать этого?
Автор/ы классная статья, было здорово посмотреть на решения для организации on-premise кубиков на bare-metal (это правда сильно!)
Остался один вопрос и одно наблюдение.
GitOps-контроллер отвечает за поставку конфигурации непосредственно в управляющий кластер. Он используется и в дочерних кубах — доставка CNI, наших агентов мониторинга и т. д
Вот здесь заинтересовал механизм initial доставки CNI. На первый взгляд, кажется что это chicken-egg проблема, но мб все не так. Из предположений было, что пока k8s в полуфабрикатом состоянии без CNI, где-то наружу торчит его k8s api и уже условный рядом стоящий argocd занимается установкой CNI.
Наверняка по тексту выше вы заметили, что где-то идут референсы на конфиги Flatcar, а где-то — на Ubuntu.
Шок-контент для меня. Впервые вижу использование flatcar в наших краях - всегда в голове была установка что он удобен в связки с kopsом (а отсюда идёт aws), но сейчас посмотрел на него под другим углом.
FlatCar provides pre-built Amazon Machine Images (AMIs) for EC2, making it easy to launch instances.
It is optimized for cloud environments, including AWS, and supports cloud-init/Ignition for instance configuration
Есть такое в данный момент... Поделюсь своим опытом на сегодняшний день: - через карьерный сайт мне ответил Uber - по постам на Blinde стало понятно, что сейчас хайрит Amazon Dublin => cо мной связались после отклика на карьерном сайте (остальные локации вроде Нидерландов, Великобритании в игноре) - периодически прошу на Blinde зарефералить меня (работает далеко не в 100% случаев, скорее в 10% - желающие зарефералить или пропадают, или уходят в игнор)
Добрый день, в доковидные и ковидные времена мне с вполне обычным опытом рекрутеры(мета, амазон, убер) активно писали в linkedin. Во время текущих кризисов бигтеха активность рекрутеров в линкеде сошла на нет, однако, по своему опыту и моих коллег (не из бигтеха) все ещё работают отклики через карьерные сайты компаний, которые нанимают и рефералы в них же (можно получать просьбами в blinde). В данный момент (09.02.2024) на отклики через карьерные сайты хорошо отвечает Uber и Meta(чуть охотнее и быстрее если будет реферал) - резюме может быть абсолютно стандартным (главное одностраничным), на практике условное наличие так называемого русского "бигтеха" или других говорящих названий вообще необязательно. К сожалению, игнорирование резюме, на сегодняшний день не редкость, к примеру мои недавние отклики через рефералов в Гугл и Тикток так и остались незамеченными
В ЛС предпочитаю обсуждать именно процесс реферала (как минимум человеку нужно знать в какую компанию я могу зареферить, чтобы посмотреть открытые позиции + если человеку интересно - мне нужна его почта). По Вашей ситуации: на мой взгляд, можно начать откликаться и пытаться проходить скрининги (если какой-то скрининг будет пройден - то взять перерыв ~1месяц для усиленной подготовки). Почему я считаю что можно начинать сейчас: - если откликаться не через реферала, то на связь компании выходят не очень быстро (убер - исключение). После initial контакта с рекрутером не обязательно ставить скрининг через 2 дня, можно взять недельку на подготовку - в случае не удачных собесов cooldown начнется раньше )) (все равно прям активный хайринг сейчас на паузе, подъем ожидается в следующем году)
Для бигтехов бонус, причитающийся рекомендующему, несоизмерим (в разы меньше, а в некоторых случаях в десятки раз меньше) signin бонусу реферала. Обычно в referral форме, возможно указать, что человек, сам попросил себя порекомендовать и указать что лично с ним не знаком => на blind достаточно людей предпочитающих полностью утилизировать свой лимит на рефералов, чтобы, не прилагая особых усилий со своей стороны, получить приятную прибавку
Да, приходится постоянно сталкиваться с такой проблемой (и не всегда строчка c бигтехом в резюме помогает). В случаях полного игнорирования моего резюме все же пытаюсь найти реферал, если не получается - то дописываю/переписываю резюме в соответствии с описанием вакансии. По поводу реферала - не стоит бояться его просить, так как в большинстве бигтехов, порекомендовавший Вас получит вознаграждение после того как Вы отработаете полгода/год (в каких-то компаниях самому рекомендующему не обязательно продолжать работать до конца этого срока). Однако, прося реферал, стоит упомянуть, что к литкоду/cистем дизайну вы готовы, так как, зачастую кол-во рефералов ограничено (~50-100). Если все сложится, Вас порекомендуют сами или же вышлют реферал-ссылку, пройдя по которой, будет возможность выбрать интересные позиции (обычно есть ограничение в 3 штуки)
Сложно не согласиться, но, на мой взгляд, массовые увольнения не самая большая проблема, с которой можно столкнуться в бигтехе. Если говорить только об увольнениях, то за последних 2 года сокращения происходили далеко не только в бигтехах. Скажу честно, что предпочел бы быть сокращенным именно бигтехом (а не какой-то другой компанией) по нескольким причинам: - не нужно возвращать signon бонус/расходы на релокацию, если не успел отработать прописанный в контракте срок - как правило, по EU законодательству, в отличие от US, уволить одним днем невозможно. В случае массовых увольнений возможен процесс консультаций, во время которых обсуждается размер "отступных" и предоставляется возможность подыскать себе место в другом проекте/подразделении компании - в случае визовых вопросов, можно договориться на увеличенный garden leave - в дни массовых увольнений происходит активизация всевозможных рекрутеров, предлагающих различные возможности - и т.д
спасибо за интересную к прочтению статью, особенно за описание некоторых особенностей/багов JVM в контейнерной среде. Правильно ли я понимаю, что одна из целей выставления "правильного" cpu request - ускорение старта JVM(ведь после старта сpu утилизировалась в меньшей мере)? Если это так, то почему в системе время старта JVM based пода настолько критично, ведь скорее всего он реплицирован и обновляется gradually (или же нет)? Или же имеет место ситуация, когда все поды сервисы перезагружаются одновременно?
Добрый день. Краткий ответ - да, затраты окупились.
Здесь не указаны все детали продукта, поэтому соглашусь, что понятно "а стоит ли оно того?". В рамках данного продукта это был большой профит. Эта была не единственная инсталляция и при запуске новых мы уже могли полагаться на архитектуру с HDD, что значительно сокращало начальную стоимость. По поводу просадки в производительности не соглашусь, т.к. она для конечного пользователя не пострадала на видимом уровне за счет уменьшения изначального размера partition с которым работал запрос на чтение. Фактически, overuse iops'ов не давал никакого преимущества и был спокойно упразднен в пользу HDD
Пожалуй, главный посыл этой заметки был о важности выбора правильной структуры хранения данных и как это помогает снизить затраты на инфраструктуру. А вот уж момент, когда делать/не делать этот выбор, зависит от многих факторов
Добрый день. Спасибо. Пока нет, но хотелось бы. По производительности резолвинг выглядит для меня в пределах нормы, хотя и требует еще улучшений в рамках кэша (кстати поэтому и не хотелось выключать systemd-resolved на машинах для всех запросов). Все это чудо разворачивается на AWS, а у него есть явные лимиты по кол-ву запросов внутри VPC (https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-limits). Ну и кол-во трафика никто не отменял. А так, в дальнейшем, мне было бы очень интересно сравнить результаты systemd-resolved + "Go" resolver, ходящий на127.0.0.53 и "Cgo" resolver.Мне кажется, преимущества go рутин здесь может сыграть
Спасибо, интересная идея! Надо бы протестировать. Через kube-api идея сразу отвалилась, т.к. он и так достаточно нагружен (crossplane и еще всякое). Еще не уверен, насколько сильно rsync ударит по iops, т.к. мы все таки это не в in-memory храним, а перегнать надо в сумме около 1 Гб мелких файлов. Если доберусь - обязательно отпишусь о результатах.
Без упоминания про необходимость платить за мастеров, lb для них и т.д. в "своём" k8s это как-то странно.
Да, согласен, упустил этот момент, спасибо. Добавил упоминание.
Плохой пример и регионов всё больше и больше
Я лишь описал с каким примером столкнулся на практике. Дело было в 2019-2020 и в ОАЭ балом правил Azure. Сейчас появляется все больше и больше регионов, это не может не радовать. Однако мой главный посыл был не только про AWS, а про любые облака в целом.
То что он становится мощнее и круче - не значит проще. Согласен, что до сих пор появляются какие-то решения, которые упрощают жизнь. Однако вместе с ними появляется куча нововведений за которыми нужно следить и знать как они работают. Для этого порой changelog'a недостаточно и нужно лезть в сорцы. А там ты натыкаешься на такое... ну например на то, что я описал касательно protokube.service
Cgroup2 и java абсолютно совместимы с jdk15 (не хочу вас расстаривать но даже 8 версия java отлично работает с cgroup2). Смотрите - https://bugs.openjdk.org/browse/JDK-8230305
Из статьи следует что вы несколько лет не переходили на cgroup2 только из-за мнимой неподдежки cgroup2 в какой-то версии jdk или были ещё какие-то везкие причины не делать этого?
Спасибо, теперь все по полочкам в голове разложилось 😀
Наверное, в сотворение k8s on premise проблема курицы и яйца весьма часто в разных неожиданных местах встречается и приходится искать решения 😀
Upd 2. А не хотите отправить эту статью на технотекст в раздел администрирование? Если выиграете - буду претендовать на бесплатное пиво/кофе 😁😁😁
Немного некрокомментинга (пришел из последний статьи про on-premise кубики на bare-metal).
Подозреваю, что у команды накопилась большая экспертиза по использованию flatcar. Чуть-чуть вопросов:
Полет нормальный?
Вы по-прежнему довольны его документацией?
Были ли какие-то проблемы при обновлении версии с мажорки на мажорку?
P.s. пойду что ли таблетками закинусь, а то увидел flatcar и пошли вьетнамские флешбэки (даже в одну мою статью попала - история номер 2)
Автор/ы классная статья, было здорово посмотреть на решения для организации on-premise кубиков на bare-metal (это правда сильно!)
Остался один вопрос и одно наблюдение.
Вот здесь заинтересовал механизм initial доставки CNI. На первый взгляд, кажется что это chicken-egg проблема, но мб все не так. Из предположений было, что пока k8s в полуфабрикатом состоянии без CNI, где-то наружу торчит его k8s api и уже условный рядом стоящий argocd занимается установкой CNI.
Шок-контент для меня. Впервые вижу использование flatcar в наших краях - всегда в голове была установка что он удобен в связки с kopsом (а отсюда идёт aws), но сейчас посмотрел на него под другим углом.
Upd. Вижу вашу статью про выбор ОС
Есть такое в данный момент...
Поделюсь своим опытом на сегодняшний день:
- через карьерный сайт мне ответил Uber
- по постам на Blinde стало понятно, что сейчас хайрит Amazon Dublin => cо мной связались после отклика на карьерном сайте (остальные локации вроде Нидерландов, Великобритании в игноре)
- периодически прошу на Blinde зарефералить меня (работает далеко не в 100% случаев, скорее в 10% - желающие зарефералить или пропадают, или уходят в игнор)
Добрый день, в доковидные и ковидные времена мне с вполне обычным опытом рекрутеры(мета, амазон, убер) активно писали в linkedin. Во время текущих кризисов бигтеха активность рекрутеров в линкеде сошла на нет, однако, по своему опыту и моих коллег (не из бигтеха) все ещё работают отклики через карьерные сайты компаний, которые нанимают и рефералы в них же (можно получать просьбами в blinde). В данный момент (09.02.2024) на отклики через карьерные сайты хорошо отвечает Uber и Meta(чуть охотнее и быстрее если будет реферал) - резюме может быть абсолютно стандартным (главное одностраничным), на практике условное наличие так называемого русского "бигтеха" или других говорящих названий вообще необязательно. К сожалению, игнорирование резюме, на сегодняшний день не редкость, к примеру мои недавние отклики через рефералов в Гугл и Тикток так и остались незамеченными
В ЛС предпочитаю обсуждать именно процесс реферала (как минимум человеку нужно знать в какую компанию я могу зареферить, чтобы посмотреть открытые позиции + если человеку интересно - мне нужна его почта).
По Вашей ситуации: на мой взгляд, можно начать откликаться и пытаться проходить скрининги (если какой-то скрининг будет пройден - то взять перерыв ~1месяц для усиленной подготовки). Почему я считаю что можно начинать сейчас:
- если откликаться не через реферала, то на связь компании выходят не очень быстро (убер - исключение). После initial контакта с рекрутером не обязательно ставить скрининг через 2 дня, можно взять недельку на подготовку
- в случае не удачных собесов cooldown начнется раньше )) (все равно прям активный хайринг сейчас на паузе, подъем ожидается в следующем году)
Для бигтехов бонус, причитающийся рекомендующему, несоизмерим (в разы меньше, а в некоторых случаях в десятки раз меньше) signin бонусу реферала.
Обычно в referral форме, возможно указать, что человек, сам попросил себя порекомендовать и указать что лично с ним не знаком => на blind достаточно людей предпочитающих полностью утилизировать свой лимит на рефералов, чтобы, не прилагая особых усилий со своей стороны, получить приятную прибавку
На мой взгляд, вполне (дальше в ЛС).
Да, приходится постоянно сталкиваться с такой проблемой (и не всегда строчка c бигтехом в резюме помогает). В случаях полного игнорирования моего резюме все же пытаюсь найти реферал, если не получается - то дописываю/переписываю резюме в соответствии с описанием вакансии.
По поводу реферала - не стоит бояться его просить, так как в большинстве бигтехов, порекомендовавший Вас получит вознаграждение после того как Вы отработаете полгода/год (в каких-то компаниях самому рекомендующему не обязательно продолжать работать до конца этого срока). Однако, прося реферал, стоит упомянуть, что к литкоду/cистем дизайну вы готовы, так как, зачастую кол-во рефералов ограничено (~50-100). Если все сложится, Вас порекомендуют сами или же вышлют реферал-ссылку, пройдя по которой, будет возможность выбрать интересные позиции (обычно есть ограничение в 3 штуки)
Сложно не согласиться, но, на мой взгляд, массовые увольнения не самая большая проблема, с которой можно столкнуться в бигтехе.
Если говорить только об увольнениях, то за последних 2 года сокращения происходили далеко не только в бигтехах. Скажу честно, что предпочел бы быть сокращенным именно бигтехом (а не какой-то другой компанией) по нескольким причинам:
- не нужно возвращать signon бонус/расходы на релокацию, если не успел отработать прописанный в контракте срок
- как правило, по EU законодательству, в отличие от US, уволить одним днем невозможно. В случае массовых увольнений возможен процесс консультаций, во время которых обсуждается размер "отступных" и предоставляется возможность подыскать себе место в другом проекте/подразделении компании
- в случае визовых вопросов, можно договориться на увеличенный garden leave
- в дни массовых увольнений происходит активизация всевозможных рекрутеров, предлагающих различные возможности
- и т.д
спасибо за интересную к прочтению статью, особенно за описание некоторых особенностей/багов JVM в контейнерной среде.
Правильно ли я понимаю, что одна из целей выставления "правильного" cpu request - ускорение старта JVM(ведь после старта сpu утилизировалась в меньшей мере)? Если это так, то почему в системе время старта JVM based пода настолько критично, ведь скорее всего он реплицирован и обновляется gradually (или же нет)? Или же имеет место ситуация, когда все поды сервисы перезагружаются одновременно?
Добрый день. Краткий ответ - да, затраты окупились.
Здесь не указаны все детали продукта, поэтому соглашусь, что понятно "а стоит ли оно того?". В рамках данного продукта это был большой профит. Эта была не единственная инсталляция и при запуске новых мы уже могли полагаться на архитектуру с HDD, что значительно сокращало начальную стоимость. По поводу просадки в производительности не соглашусь, т.к. она для конечного пользователя не пострадала на видимом уровне за счет уменьшения изначального размера partition с которым работал запрос на чтение. Фактически, overuse iops'ов не давал никакого преимущества и был спокойно упразднен в пользу HDD
Пожалуй, главный посыл этой заметки был о важности выбора правильной структуры хранения данных и как это помогает снизить затраты на инфраструктуру. А вот уж момент, когда делать/не делать этот выбор, зависит от многих факторов
На мой взгляд, вполне хорошая и реализуемая "претензия". "Войти в FAANG" так же реально, как и в другие компании с таким же процессом.
Базовая рекомендация абсолютно всех подборок - https://habr.com/ru/companies/piter/articles/309106/
"Золотой сборник" с разбором наиболее популярных систем - System Design Interview An Insider’s Guide by Alex Xu. Если основная цель подготовка к СД, можно рассмотреть этот материал как отправную точку.
https://github.com/weeeBox/mobile-system-design. Уклон на мобильные платформы, однако, очень много ценных мыслей для любого направления.
Добрый день. Спасибо. Пока нет, но хотелось бы. По производительности резолвинг выглядит для меня в пределах нормы, хотя и требует еще улучшений в рамках кэша (кстати поэтому и не хотелось выключать systemd-resolved на машинах для всех запросов). Все это чудо разворачивается на AWS, а у него есть явные лимиты по кол-ву запросов внутри VPC (https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-limits). Ну и кол-во трафика никто не отменял. А так, в дальнейшем, мне было бы очень интересно сравнить результаты systemd-resolved + "Go" resolver, ходящий на127.0.0.53 и "Cgo" resolver.Мне кажется, преимущества go рутин здесь может сыграть
Спасибо, интересная идея! Надо бы протестировать. Через kube-api идея сразу отвалилась, т.к. он и так достаточно нагружен (crossplane и еще всякое). Еще не уверен, насколько сильно rsync ударит по iops, т.к. мы все таки это не в in-memory храним, а перегнать надо в сумме около 1 Гб мелких файлов. Если доберусь - обязательно отпишусь о результатах.
Да, согласен, упустил этот момент, спасибо. Добавил упоминание.
Я лишь описал с каким примером столкнулся на практике. Дело было в 2019-2020 и в ОАЭ балом правил Azure. Сейчас появляется все больше и больше регионов, это не может не радовать. Однако мой главный посыл был не только про AWS, а про любые облака в целом.
Добрый день.
К тому, что managed k8s чаще выходит дешевле, чем использование своего, в статье после этих расчетов я об этом как раз и рассуждаю.
Если нужно развернуть свой SaaS в регионе без AWS. ОАЭ например.
Spot instances можно как раз отнести к специфике использования облака, потому что не все облака это предоставляют
То что он становится мощнее и круче - не значит проще. Согласен, что до сих пор появляются какие-то решения, которые упрощают жизнь. Однако вместе с ними появляется куча нововведений за которыми нужно следить и знать как они работают. Для этого порой changelog'a недостаточно и нужно лезть в сорцы. А там ты натыкаешься на такое... ну например на то, что я описал касательно protokube.service