Привет! Прежде чем начнем говорить о кубах, предлагаю познакомиться поближе. Меня зовут Виталий Лихачев, и я SRE в большом голландском тревелтехе.

➡️ Мой путь в айти начался до того, как это стало модно. Концепция DevOps только зарождалась, а сеньоры ещё не получали 300к в наносекунду. Я начал с дисков с Ubuntu, которые можно было бесплатно заказать обычной почтой (признавайтесь, кто помнит?)

Интернет был медленным и дорогим, о безлимитах ещё не слышали. Играть в GTA и CS мне надоело, а разобраться, как работает компьютер, хотелось. Чуть позже была куплена книга «Запускаем linux, 4-е издание», и пошло-поехало.

➡️ Уже в вузе, на кафедре вычислительной техники, я устроился в ночную техподдержку местного небольшого интернет-провайдера. Потом была роль системного администратора в одной госорганизации: поддержка Windows и Linux серверов, управление почтовыми системами, файловыми хранилищами, виртуализацией и прочими инфраструктурными сервисами.

Еще 10 лет назад я активно продвигал внедрение чего-то нового. Не кривя душой, могу сказать, что в первую очередь для наработки опыта, а уже потом для решения конкретных технических задач, стоящих в конторе (когда вместо «зарплата» сказал «получка» 👨🏼‍🦳)

Я инициировал переход с устаревшей АТС от Samsung, на FreeSWITCH, а позже — на Asterisk из-за его более широкой модульной экосистемы. Параллельно заменили почтовый сервер, внедрили Zabbix для мониторинга, и это стало первым опытом системной модернизации инфраструктуры.

➡️ Постепенно я углублялся в разработку: изучал Python и Django, позже освоил PHP с Laravel и Symfony. Системное администрирование отошло на второй план, но навыки работы с инфраструктурой остались: настройка мониторинга, развертывание баз данных, сбор логов — всё это я делал руками, в эпоху, когда Terraform еще не был повсеместным стандартом, а концепция DevOps только начинала набирать популярность.

Параллельно изучал фронтенд. Работал с React и Vue.js, создавал сложные SPA с динамичными интерфейсами. Одним из самых интересных проектов было приложение с картой на основе Leaflet, интеграцией нескольких провайдеров карт (Google Maps, OpenStreetMap и другие). Здесь я разобрался в производительности фронтенда, оптимизации рендеринга сотен тысяч элементов на карте и нюансах работы с WebSocket.

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

Например, для реализации одной функции потребовалось несколько месяцев не из-за сложности кода, а из-за необходимости понять распределение ответственности между десятками разных сервисов и 5-10 командами. Так что теперь я могу аргументированно пояснять пацанам за микросервисы vs монолит 😎

Накопленный опыт в разработке крупных систем на Go, а также переход с PHP и Python, вдохновили меня создать собственный курс, где я не только объясняю множество нюансов работы с go, но и рассказываю про разработку больших систем, включая тестирование и оптимизацию, но канал конечно не об этом.

➡️ Сегодня я SRE в крупнейшем travel-tech с корнями в Нидерландах. Мой бэкграунд — администрирование, DevOps, программирование на разных языках, работа с сетевыми технологиями (маршрутизация, VLAN, файрволы) и построение Observability — помогает мне видеть общую картину. Умение заглянуть под капот инструментов, независимо от используемых технологий, поиск нетривиальных решений и постоянное непрекращающееся изучение новых инструментов помогают как-то лавировать в условиях современного ИТ. Синдром самозванца при этом никуда не делся 😅

А ещё у меня есть кот. Его зовут Маркус — те, кто были на наших вебах, с ним уже знакомы. Он будет регулярно появляться в канале и пояснять за кубы (поверьте, у него огромный опыт).

Мне интересно узнать больше о моей аудитории. Поделитесь в комментариях своим бэкграундом, и чем вы занимаетесь сейчас? Фото питомцев приветствуются)))

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, прямо скажем. Сербия, Испания, Португалия, Кипр и так далее кажутся больше на слуху, по крайней мере в моем информационном пузыре. Да и проще в получении разрешения на работу.