Как работают requests/limits изнутри
#полезный_материал

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

Подготовил для вас материал, в котором разобрал, как не перегрузить ноды так сильно, что kubelet начнет выселять поды для сохранения ресурсов.

Вы узнаете, что такое node-pressure eviction, и как он может повлиять на стабильность работы вашего проекта под нагрузкой.

👉 Посмотреть можно ТУТ.

А после прочтения предлагаю ответить на вопрос:

Можно ли задать значение limits больше, чем самая большая нода в кластере, и запустится ли такой под?

Ответы пишите в комментариях 👇

👉 2024 — индустрия на пике сокращений, вливания в IT снизились, а отсев кандидатов стал еще жестче. Кажется, что отправка более 200 откликов в разные компании на позиции senior software engineer, k8s инженер (да, это отдельная должность/позиция, где ты будешь заниматься только k8s и всем вокруг него), DevOps и SRE не приводила ни к какой конверсии от слова совсем.

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

Усугубляло процесс личное ограничение на желание работать и жить именно в Нидерландах по совокупности разных причин, которые были заранее изучены и согласованы с семьей. Не самая хайповая страна для релокации в 2024, прямо скажем. Сербия, Испания, Португалия, Кипр и так далее кажутся больше на слуху, по крайней мере в моем информационном пузыре. Да и проще в получении разрешения на работу.

Итоговая конверсия в первую беседу с рекрутером вышла приблизительно 5 из 200. До первого технического собеседования дошел с 3-мя компаниями, среди которых был, к примеру, amazon. Привет Безосу!

➡️ Подготовкой к собесам в современные бигтехи, как бы это неправильно ни звучало, нужно заниматься несколько месяцев, включая не только литкод, но и system design и поведенческие интервью, особенно учитывая, что литкод встречается в работе примерно никогда ;) На самом деле кейсы применимости знания сложных алгоритмов есть в индустрии, но это уже очень специфические позиции. Например, разработчики СУБД.

Процесс собеседований прошел на удивление неплохо. А про оффер, переезд и онбординг расскажу уже завтра. Пока в комментариях можете делиться своими мыслями и вопросами))

Мой 2024: часть 2

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

Процесс собеседований прошел на удивление неплохо, учитывая выделение достаточно большого времени на подготовку и вот он, желанный оффер. Да и еще и с поддержкой в релокации, включая все требуемые документы. Набор достаточно обычный: собеседование с рекрутером, литкод, system design, behavioral interview и финальная встреча с рекрутером. Затем 3 месяца подготовки к переезду с семьей и котом из Еревана в Амстердам, получение визы и так далее.

➡️ Отдельная история с перевозкой кота, с необходимостью подготовить все требуемые документы для животных, но это ни в какое сравнение не идет с историей, которой со мной поделился рекрутер компании. Они помогали перевозить в Нидерланды… Лошадь! Так что кот - это мелочи :)

И вот, наконец, Амстердам. На удивление солнечный. Все лето было довольно немного дождей, но Северное море даже в жару все равно холодное, а полчища медуз так и норовят ужалить тебя :)

Процесс онбординга, знакомство с продуктами компании и используемыми инструментами и вся изначальная суета длились порядка 2-х месяцев, после чего я начал брать довольно сложные проекты для реализации, требующие изучение нового тулинга, взаимодействия с множеством команд с разных концов Земли, написания design docs и претворения всех технических фантазий в жизнь.

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

Выверенный подход к имплементации какого-то проекта через техническое описание решения позволяет сильно сократить потенциальные ошибки при итоговой раскатке решения в production и выровнять ожидания для всех заинтересованных в этом решении лиц.

А как прошел ваш 2024?

👉 Под этим постом можете задать ваши вопросы о проблемах поиска работы в Нидерландах, о жизни, о школах и медицине. На самые трепещущие вопросы обязательно отвечу, пока память о переезде еще достаточно свежа.

Привет, как ваше настроение? Готовы к двухдневной рабочей неделе?))

Тем, кто дежурил в праздники, соболезную, тем, кто отдыхал — держитесь, скоро вы втянетесь.

Врываюсь в канал, чтобы позвать вас на вебинар, который мы вместе с Кириллом Борисовым проведем 16 января (соскучились?))

Тема вебинара 👉 Observability и k8s: полный контроль над инфраструктурой и сервисами

Поговорим о том, какие проблемы решает Observability:
▶️Выявление аномалий в работе кластера
▶️Мониторинг сетевой активности и предотвращение сбоев
▶️Обеспечение соответствия политик безопасности
▶️Снижение времени простоя за счет быстрого устранения инцидентов
▶️Упрощение эксплуатации сложных систем с минимальными затратами

А ещё:
✅ Рассмотрим внутренние инструменты k8s, связанные с безопасностью и отладкой работы кластера
✅ Посмотрим на инструменты, полезные для понимания работы больших систем без необходимости внедрения большого кол-ва изменений в сервисы, написанные на разных языках и фреймворках.

Когда: 16 января в 19:00 мск
Регистрация — через бота ⬅️

Всех жду!

Что такое Design Patterns?

Если говорить нормальным языком, то это — проверенные временем костыли для типичных проблем разработки.

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

Составил краткий гайд по самым популярным 👇

1️⃣ Sidecar Pattern
Добавляем контейнер в Pod, чтобы расширить функциональность без переделки основного приложения. Например, можно расширять логи, мониторить запросы или проксировать их, добавляя полезную (или не очень) нагрузку.

Его можно условно разделить на 2 подвида:

1.1 Adapter Pattern – натягиваем старые приложения на новые реалии. Например, парсер логов, который делает их читаемыми (ну или хотя бы похожими на читаемые). Вскоре познакомимся с ним поближе.

1.2 Ambassador Pattern – добавляем посредника для общения сервисов. По сути на нем построен service mesh, работу которого мы еще разберем в одном из будущих постов.

2️⃣ Init Container Pattern
Контейнеры для подготовки основного приложения перед запуском. Подходит для выполнения миграций БД, прогрева кеша или просто оттягивания неизбежного падения сервиса. Тут важно понимать, что если у вас N реплик приложения, то N init контейнеров и запустится, поэтому те же миграции БД должны поддерживать атомарные операции с взятием блокировок, например, для избежания race conditions.

3️⃣ Operator Pattern
Автоматизируем управление сложными штуками в Kubernetes: базы, кеши, stateful-приложения – пусть лучше за этим следит робот, а не вы.

4️⃣ Controller Pattern
Те же операторы, но встроенные в Kubernetes. Меньше кода писать самому – меньше боли в поддержке (но это не точно).

5️⃣ Leader Election Pattern
Организуем выбор лидера среди нескольких экземпляров сервиса. Полезно, если ваша база данных хочет знать, кто тут главный. Применимо, конечно, не только для баз данных.

6️⃣ Self-Healing Pattern
Kubernetes сам перезапускает упавшие или зависшие сервисы. Использует Liveness и Readiness Probe, чтобы не ждать, пока кто-то из команды заметит, что всё давно сломалось.

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

Привет! Надеюсь, все окончательно стряхнули с себя остатки новогодних праздников и готовы к плодотворной работе 🔥

В предыдущем посте мы рассмотрели, какие бывают паттерны в k8s. Сегодня хочу немного подробнее поговорить про сайдкары, и как они применяются на практике.
#полезный_материал

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

Смотреть 👇👇👇

Продолжаем говорить про паттерны в кубах.
#полезный_материал

Ловите вторую часть видео: кейсы сбора и модификации логов с приложений, которые пишут логи в файл.

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

Подробнее про сайдкары и хранение секретов мы говорим в 8 теме Kubernetes Мега. В конце курса отдельно говорим и про другие паттерны — operatror и service mesh. Предлагаю разобраться вместе 🤗

Старт потока 27 января. Занять место — по ссылке 👈

Всем привет!

Вебинар по observability уже совсем скоро — завтра в 19:00. Ведущих будет трое: я, кот и Кирилл Борисов.

Ставьте лайки и огонечки, если хотите, чтобы Маркус тоже был на вебе❤️🔥

Занять место — через бота ⬅️

Маркус выглянул из укрытия, чтобы напомнить:

👉 Вебинар по Observability сегодня в 19:00

Поговорим о том, какие проблемы решает Observability:
▶️Выявление аномалий в работе кластера
▶️Мониторинг сетевой активности и предотвращение сбоев
▶️Обеспечение соответствия политик безопасности
▶️Снижение времени простоя за счет быстрого устранения инцидентов
▶️Упрощение эксплуатации сложных систем с минимальными затратами

А ещё:
✅ Рассмотрим внутренние инструменты k8s, связанные с безопасностью и отладкой работы кластера
✅ Посмотрим на инструменты, полезные для понимания работы больших систем без необходимости внедрения большого количества изменений в сервисы, написанные на разных языках и фреймворках.

Ссылки на трансляцию будут в боте. Подключайтесь!

🔥 Мы начинаем 🔥

Ссылки уже в боте. Всех жду!

Привет! На связи Маркус.

Я тут питон решил изучать. По мне видно, насколько он мне заходит, но я не сдаюсь!

А пока я продираюсь сквозь синтаксис, ловите документацию, про которую мой человек говорил вчера на вебинаре:

👉 Kubernetes auditing

👉 How to use Kubernetes events for effective alerting and monitoring

👉 OpenTelemetry

Впереди выходные, отличный повод, чтобы изучить. До понедельника!

Привет!

Мы с вами успели уже довольно много поговорить о кубах — потрогали паттерны, разобрались с сайдкарами, вникли в работу реквестов и лимитов. Думаю, у некоторых из вас в процессе возникли вопросы, которые хотелось бы обсудить.

Предлагаю встретиться в прямом эфире и поговорить о том, что больше всего болит — по темам, которые уже были в канале, или просто в контексте кубов и инфраструктуры.

➡️ Когда: 23 января в 18:30 мск

Вопросы собираем в комментариях к этому посту 👇 (спросить голосом тоже можно будет, так что если планируете прийти и спросить, но писать комментарий лень — ставьте 🔥)

Маркус ждет ваших вопросов!