k8s: когда одних метрик недостаточно

K8s, куб, кубер, кубик — не просто инструмент оркестрации (как бы вычурно это ни звучало), а полноценная экосистема (спасибо, кэп, а то мы не догадывались 😒)

Если серьезно, то знать кубы для современного инженера так же важно, как раньше было важно понимать системы виртуализации для сисадмина/инженера виртуализации, устройство БД для DBA, настройку сети для сетевого инженера и так далее. Абстракций становится все больше, и мы все дальше от железа.

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

➡️ Сейчас длительность полноценного честного онбординга в большую инфраструктуру может занимать от полугода, когда ты начинаешь более-менее понимать как все устроено. И все равно за разные части системы будут отвечать разные команды, и ты будешь ходить к ним с запросами, требуемыми для решения твоих задач. Такова реальность в бигтехе.

Возвращаясь к кубам: я сам постоянно изучаю, что там есть в самом кубе и вокруг него. Ландшафт инструментов меняется чуть ли не каждый год, неудачные решения, которые были приняты при разработке k8s, заменяются на более удачные (привет, structured auth configuration или создание CSI для выселения плагинов работы с дисками из основной кодовой базы).

👉 В конце концов, k8s — такой же программный продукт, как и ядро linux, как и PostgreSQL, как и Apache Kafka, etc.

Относительно глубокое погружение в Golang позволяет с некоторой степенью уверенности залезать в код k8s, чтобы разбираться как что работает изнутри, а в дальнейших постах мы посмотрим под капот абстракций, которые обычно используются AS IS. Это нормально и абсолютно валидно до тех пор, пока все работает как ожидается. Ну, а когда ломается, тогда остается только молиться, если ни у кого нет понимания, что происходит внутри.

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

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

👉 Как-то один большой проект со многими тысячами RPS прилег отдохнуть, и никто не понимал, почему: по метрикам не было явных аномалий. Долго добры молодцы искали причину (десятки минут в больших инцидентах кажутся часами), но смогли найти лишь после прикладывания подорожника.

Вкратце суть: есть N-ое кол-во подов, отвечающих за терминирование websocket соединений. Самих соединений у каждого уважающего себя проекта может быть одновременно X миллионов. Это нормально, когда ты строишь продукт, где требуется что-то похожее на реалтайм взаимодействие (да, настоящий реалтайм вообще не про это, а про гарантированное время отклика, поэтому ни k8s, ни linux к настойщему realtime отношения не имеют).

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

➡️ В один день (или же вечер) где-то в сети выше на уровне балансировщиков произошел сбой и одномоментно бОльшая часть вебсокет коннектов отвалилась. Абсолютно нормальная ситуация, сеть ненадежна, клиенты (особенно мобильные устройства) могут много раз за день переподключаться, что и происходило постоянно (телефон потерял сеть и подключается заново). Чего же не происходило раньше — так это единовременного отвала N-го кол-ва соединений (сотни тысяч или десятки миллионов, для истории не так важно).

Конечно же клиенты начали переподключаться. Естественно с учетом лучших практик, с exponential backoff в случае ошибки подключения, но это не спасло. Сервис проверки корректности кук Ивана (назовем его СПККИ) не выдержал такого резкого всплеса трафика (приблизительно в 3000 раз от обычной нагрузки) и лег кверху лапками. Эту проблему в итоге поправили, но осадочек остался. Систему подняли, внеся некие хотфиксы, чтобы поток запросов снизился.

Мы с командой Слёрма поздравляем вас с наступающим Новым годом! 🎄🥂

Пусть он будет полон новых свершений и карьерных взлётов.

⚡️В январе ждите от меня полезный материал про лимиты и реквесты.

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

До встречи в 2025!

Как работают 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.