Всем привет!

Вот это активность вчера была 🔥🔥🔥 Вы очень крутые, спасибо, что были с нами. И отдельное спасибо Вячеславу Федосееву за внезапное появление, вместе было ещё веселее!

Как-нибудь обязательно повторим, и в следующий раз я жду от вас еще больше вопросов и включенных микрофонов. Если что-то не успели обсудить, можете смело накидывать вопросы в комментарии к этому посту 👇

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

Уже через 5 дней стартует курс Kubernetes База, на котором мы будем учиться:

🔵работать с K8s
🔵запускать кластер
🔵работать с базовыми абстракциями и подключать дополнительные компоненты
🔵запускать приложение в кластере
🔵настраивать CI/CD пайплайн
🔵рассказывать про Kubernetes, пока течет мой любимый кетчуп (для тех, кто был вчера на лайве)

Старт потока: 16 декабря
Полная программа курса — на сайте. Присоединяйтесь, и погнали учиться 🔥

Всем привет!

В блоге Слёрма на Хабре вышел большой материал от Рустема Галиева (Senior DevOps Engineer в IBM). Внутри — подробный гайд по поиску и эксплуатации уязвимостей в контейнеризированных средах, рассматривая ключевые аспекты контейнерной безопасности:

🔸распространенные уязвимости
🔸ошибки в конфигурации
🔸методы выявления и эксплуатации ошибок

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

👉 Как искать и эксплуатировать уязвимости в контейнеризированных средах. Часть 1
👉 Как искать и эксплуатировать уязвимости в контейнеризированных средах. Часть 2
👉 Как искать и эксплуатировать уязвимости в контейнеризированных средах. Часть 3

Новогодний корпоратив уже завтра, а сегодня — старт потока Kubernetes База!

🔥 Мое уважение тем, кто решил начать учиться здесь и сейчас, без всяких «давай уже после праздников». Вы мощь!

Впереди 6 недель обучения, 63 часа практики и итоговая сертификация — на январских точно не будет скучно))) К тому же, в подарок к потоку идут подготовительные видеокурсы по ансиблу и докеру — их можно пройти за несколько часов и получить базовые знания для работы с кубами.

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

Так что ждём каждого отважного воина, готового начать учиться прямо сейчас.

Подробности — на сайте ⬅️

Ну что, готовы отдыхать и создавать праздничное настроение? 🎄

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

В программе итоги 2024 года, планы на 2025, шутки, мемы и неформальное общение. Будем загадывать желания и, конечно, дарить подарки 🎁

➡️ Ссылка, как всегда, будет в боте ⬅️

Всех жду!

Всем привет!

Последняя неделя до нового года — время горящих дедлайнов и самых ярких факапов. Как насчёт поговорить о последних на лайве?

26 декабря в 19:00 жду вас в прямом эфире прямо здесь на канале. Что будем обсуждать:

👉 как уронить кластер?
👉 как сделать надёжную систему ненадёжной?
👉 как переусложнить систему без пользы для дела?
👉 как потратить кучу денег на инфраструктуру без явной пользы?

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

Лайв про факапы в кубах уже через час ⏱

Поговорим, как уронить кластер и как из надёжной системы сделать ненадёжную.

⭐️ А ещё разыграем среди участников доступ к видеокурсу «Мониторинг и логирование инфраструктуры в Kubernetes»

Готовьте свои вопросы (их можно прислать в комментарии к этому посту) и подключайтесь. Всех жду!

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

Подключаайтесь!

Привет! Прежде чем начнем говорить о кубах, предлагаю познакомиться поближе. Меня зовут Виталий Лихачев, и я 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 и сторонних инструментах, написанных под него, никто не отменял. Идеальный код — ненаписанный код.