«У нас тридцать два кластера». Руководитель команды platform engineering произнес это как на исповеди. Тридцать два. В компании с девятью продуктовыми командами. По шесть окружений на каждую. Никто не планировал такого — оно просто росло по одному кластеру за раз, каждый раз, когда команде требовалось что-то чуть иное, а самым простым ответом было «подними новый».

Я слышала ту или иную версию этой фразы почти в каждой компании, достигшей определенного размера. Цифра меняется — иногда двенадцать, иногда шестьдесят, — но динамика всегда одна. Kubernetes легко позволяет создавать кластеры, никто намеренно не решал, когда их использовать совместно, а когда нет, и в какой-то момент кто-то смотрит на счет за облако и ротацию дежурств — и понимает, что управление десятками кластеров медленно пожирает платформенную команду заживо.

Multitenancy — ответ на эту проблему. Kubernetes не был спроектирован для multitenancy из коробки, и, чтобы построить его правильно, требуются реальные инженерные инвестиции, но именно так зрелые команды platform engineering решают эту задачу в 2026 году — со все более удобным инструментарием и все лучше понятыми паттернами.

Команда VK Cloud перевела статью, охватывающую все, что автор узнал о Kubernetes multitenancy в нескольких продакшен-окружениях: какие модели существуют, где каждая из них дает сбой, как выстроить слои изоляции, которые действительно защищают тенантов друг от друга, какие инструменты стоят вашего времени и как выглядит хорошо управляемый общий кластер на практике.

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

Практичные Python-привычки: явное состояние и мемоизация, асинхронность для продакшн, ошибки и raise, типизация и валидация, ленивая загрузка и кеширование

Лень — двигатель прогресса. Именно по этой причине Ansible — лучший друг любого админа, которые не хочет руками применять настройки к 1000 серверов. Я использую его на регулярной основе, но при этом именно тема инвентарных файлов каждый раз умудряется меня удивить. Поэтому в этой статье решил собрать всю общую информацию, начиная с inventory.ini и заканчивая плагинами для динамических инвентарей.

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

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

Для того, чтобы коллегам было комфортнее на техническом интервью, а так же для желающих понять работу Kafka без Zookeper предлагаю статью. Понимаю, что мы все не любим длинные тексты, поэтому вложил максимум деталей в схемы и краткие формулировки.

Привет, я Сергей Истомин, DevOps-инженер в KTS. А ниже моя история про построение мультитенантного скоупа кластеров VictoriaMetrics с разными периодами хранения метрик.

Статья будет о том, как собрать систему одновременно и простую, и сложную. Простую потому, что каждый поток данных в ней лаконичный и линейный, и сложную потому, что совокупности этих потоков комбинируются и интегрируются в общие компоненты. Система будет построена на редакции Community Edition.

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

Если вы используете nofailover: true (а многие так и делают), Patroni не синхронизирует слоты логической репликации — и при переходе на реплику часть данных может исчезнуть навсегда. Рассказываем, почему и как фиксить.

Многие уверены, что если сервис поднят в кластере — значит, он защищён от любых потрясений инфраструктуры, и, если что-то случится, Kubernetes "сам всё поднимет". Но на деле есть нюанс. Реальная устойчивость и грамотный disaster recovery появляются только на стыке платформы, клиентской логики и конфигурации сервисов. А обнаружить узкие места возможно только во время инцидентов или плановых аварийных учений. Так мы и поступили: выключили 30% нод в production кластере и посмотрели, что будет.

В статье разберём — почему именно 30%, какие сбои и узкие места всплыли в ходе учений, а также какие сделали выводы и мы, как команда Kubernetes, и прикладные команды.

Привет всем! Хочу поделиться небольшим личным проектом, который родился из чистой бытовой необходимости. Я давно хотел иметь возможность удаленно поглядывать на свою дачу, особенно когда уезжаю на несколько недель. Готовые решения в духе "умных камер" меня не совсем устраивают: то подписки дорогие, то Privacy Policy сомнительная, то функционал избыточный. В итоге я решил, что проще и надежнее будет написать свою собственную утилиту.

Есть один миф про ClickHouse - он плохо джойнит. Подавляющее большинство не знает, с чем это утверждение связано, и просто верят на слово. А дальше срабатывает эффект сарафанного радио. В итоге в IT-сообществе есть твердое убеждение, что ClickHouse плохо джойнит. Но для меня апогеем стала статья от школы обучения программированию, в которой написано, что ClickHouse вообще не умеет джойнить:

Kubernetes полюбился разработчикам своим удобством: описал развертывание, в любой момент изменил параметры — и все работает. Но вот раскатка самих кластеров долгое время оставалась лоскутным одеялом: Terraform, Ansible, десятки плейбуков и пайплайнов. Потерял стейт — и начинается квест. 

Cluster API (CAPI) закрыл этот разрыв и за последние годы стал едва ли не стандартом для управления Kubernetes-кластерами. Он превратил развертывание и сопровождение инфраструктуры в такой же декларативный процесс, как деплой приложения.

В нашей платформе «Штурвал» мы уже давно используем Cluster API в продакшене. И довольно быстро стало понятно: это не просто удобный способ развернуть Kubernetes, а смена парадигмы эксплуатации. Но вместе с предсказуемостью приходят новые сложности — от обновлений управляющей плоскости до нетривиальных сценариев отказа. В этой статье разберемся, чем хорош Cluster API, а в чем его подводные камни, о которых обычно узнают уже в ходе эксплуатации.

Пробуем написать своё приложение для удалённого рабочего стола.

Начал замечать, что на Хабре часто появляются статьи в духе «Я написал замену AnyDesk, бесплатный, но платный. И тут мне пришла мысль: а что, если попробовать самому? Хотя я не программист».

Небольшой рассказ - туториал о том, как на MikroTik реализовать удобное управление большим количеством VPN профайлов.

ClickHouse быстрый. Настолько быстрый, что первые полгода можно жить без оптимизаций вообще — агрегации по миллиарду строк отрабатывают за секунды. Потом данных становится больше, запросов тоже, дашборд начинает подтормаживать, и вы задумываетесь: «а можно ли считать агрегаты заранее?»

Можно. В ClickHouse для этого есть два механизма: materialized views и проекции (projections). Оба пересчитывают данные на этапе вставки. Оба ускоряют чтение. Но работают по-разному.

Всем привет, с вами ваш писатель-программист и сегодня мы поговорим о такой штуке как "Архивация".

Представьте, что у вас есть таблица, в которой каждый день появляется 100 000 новых записей. Через год в ней будет 36 миллионов записей. MySQL начнет "тормозить" на сложных аналитических запросах, а удалять старые данные нельзя — они нужны для отчетности.

Решение есть! ClickHouse!

Расскажу, как собрал бота для AI-суммаризации Telegram-каналов: архитектура, выбор LLM-провайдера, оптимизация скорости и неочевидные проблемы при деплое на российский VPS.

Привет! Я Ангелина Архипова, тимлид QA в Авито. За семь лет в тестировании я прошла путь от ручного специалиста до руководителя команды и увидела, как меняется взгляд на качество через призму разных этапов развития. В этой статье я рассказываю про этапы развития QA-инженера.

⛔ Почему цена на рынке падает одной свечой

В 2026 году «купил и держал» это ставка на то, что выдержишь -40…-70% просадку без эмоционального или маржинального выхода. Рынок стал хрупким: каскады ликвидаций случаются несколько раз в год. Статичный холд больше не работает.

Разбираю математику падения

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

В этой статье покажу, как настроить безопасный и приватный DNS-резолвер на базе Unbound:

Полное руководство по развертыванию высокодоступного кластера Kubernetes 1.35 на Ubuntu 24.04

Эта подробная техническая статья представляет собой пошаговое руководство по созданию отказоустойчивого кластера Kubernetes версии 1.35 с использованием утилиты kubeadm. В руководстве рассматривается развертывание производственного кластера с тремя master-нодами и тремя worker-нодами, что обеспечивает высокую доступность и отказоустойчивость.

Kubernetes давно стал де-факто стандартом для оркестрации контейнеров. Его используют все – от крупных корпораций до мелких стартапов – и в ус не дуют. Потому что удобно: сервисы после падения поднимаются сами, трафик равномерно размазывается по репликам, деплой происходит в один клик, а масштабирование — по графику нагрузок, а не по звонкам в два часа ночи. Но это на бумаге. А вот на практике многие компании сталкиваются с тем, что за удобство приходится платить. Причем зачастую куда больше, чем рассчитывали первоначально. Бывали даже случаи, когда на кластер закладывали 200 тысяч рублей в месяц, а по факту отдавали 500-600. Естественно, работать в таких условиях нельзя. Поэтому надо разбираться, куда на самом деле уходят деньги и как сохранить их при себе.