Kubernetes *

NetworkPolicy могут выглядеть корректно, применяться без ошибок и при этом оставлять кластер открытым там, где вы уверены в изоляции.

Разберём пять типичных ошибок — от CNI без поддержки политик до неверных селекторов — и покажем, как проверять правила реальным трафиком, а не по наличию объектов в API.

Если в кластере больше пяти Helm-релизов, рано или поздно появляется скрипт. Сначала десять строк с helm upgrade --install, потом sleep 30 между базой и приложением, потом sops ▎ -d values.yml | helm -f -, потом ветка if [ “$ENV” = prod ]. В какой-то момент никто не может сказать, что именно он раскатит на проде, пока он это не сделает.

▎ nelmwave заменяет этот скрипт одним манифестом

В статье рассматривается опыт миграции сети Kubernetes-кластера на новый IP-пул (Pool IP) с использованием CNI Cilium. Особое внимание уделено процессу смены IP-адресов для Pod'ов и Service'ов в работающем кластере без длительной остановки, а также подводных камнях, с которыми пришлось столкнуться при обновлении до версии 1.20.0. Материал будет полезен инженерам по эксплуатации Kubernetes использующих уже Cilium, а так же желающим познакомиться с этим инструментом.

В cloud-native-среде безопасность давно не ограничивается защитой периметра. Уязвимость может появиться в IaC-шаблоне, попасть в контейнерный образ, пройти через CI/CD и проявиться уже в продакшене.

Тема очень сложная, поэтому когда я наткнулся на большой англоязычный материал о cloud-native-безопасности в публичном репозитории Security Technical Advisory Group, то сразу решил его перевести.

Cобрал практическое саммари: какие риски возникают на этапах разработки, сборки, развертывания и эксплуатации (runtime) и какими механизмами их закрывают — от DevSecOps и защиты цепочки поставки до Zero Trust и политик для работающих нагрузок.

25 марта 2026 года голосовая и видеосвязь Discord перестала нормально работать для большинства пользователей. Причиной стал не один большой сбой, а цепочка событий: изменение конфигурации Kubernetes привело к потере части пользовательских сессий, затем система столкнулась с лавиной переподключений и новыми узкими местами в инфраструктуре.

В статье команда Discord разбирает этот инцидент изнутри: как 17% остановленных сессий запустили каскадный отказ, почему механизмы восстановления сами стали источником нагрузки и какие архитектурные изменения помогли сделать систему устойчивее.

Вышел Cozystack v1.6.0. Релиз опубликован 22 июля 2026 года и включает все исправления, ранее вышедшие в патч-релизах v1.5.1–v1.5.3. Ниже — перевод официального анонса, дополненный главными исправлениями из патч-релиза v1.6.1 от 5 августа.

В этом выпуске изменилось несколько важных частей платформы. Рабочие узлы тенантных кластеров Kubernetes теперь работают на Talos Linux вместо Ubuntu, тенанты могут включать аутентификацию OIDC для Kubernetes и Grafana, а новый API SecurityGroup даёт более безопасный интерфейс для управления сетевыми политиками приложений.

За последние несколько месяцев плотной работы над инфраструктурой для проекта я прошёл путь от первых команд в терминале Linux до настройки полностью отказоустойчивого K3s‑кластера с Zero‑Downtime деплоем. Шишек на этом деле я набил огромное количество, и мне определённо есть чем поделиться.

Сразу оговорюсь: в этой статье не будет монотонных гайдов, слепых копипастов YAML‑манифестов и пересказа официальной документации. С базовой настройкой вы отлично справитесь, прочитав мануалы создателей этих инструментов.

Для меня этот материал — способ структурировать собственный опыт. Хотя, не буду скрывать, обсуждения в комментариях мне тоже интересны. Я хочу разобрать реальные ошибки при переходе от простого Docker Compose к Kubernetes, показать процесс траблшутинга и критически взглянуть на проделанную работу, чтобы понять: а всё ли было сделано верно?

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

Управление данными в Kubernetes часто кажется сложным. Если грамотно не подключить внешнее хранилище, то при любом перезапуске пода все накопленные файлы бесследно исчезнут. Этот материал — практическое руководство для тех, кто только осваивает администрирование K8s и хочет разобраться в логике работы дисков без погружения в запутанную документацию.

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

Привет! Я Катя, младший системный администратор в Selectel. Надеюсь, моя работа поможет выстроить в голове четкую картину и сэкономит часы на дебаге, если нужный диск однажды откажется подключаться.

Привет, это Антон Пионтковский из команды Monium Metrics, и вместе с коллегами мы создаём observability‑платформу для сбора, хранения и анализа телеметрии Yandex Monium. Мы храним миллиарды метрик и обрабатываем 50 гигабайт логов в секунду, а внутри Яндекса с Monium работают 16 тысяч сотрудников.

Чтобы справиться с объёмом метаданных метрик Kubernetes, мы научились фильтровать их по времени. Сначала наивно с помощью линейного сканирования, и потому только для небольшого круга пользователей. Но результат нам так понравился, что мы захотели включить фильтр для всех. Поскольку первоначальный подход нельзя было скейлить, мы использовали специальный — range encoded bit sliced — индекс, и получили ускорение в 6–20 раз, а в удачных случаях — до двух порядков.

Расскажу, как мы дошли до такой жизни, как устроен этот индекс, и что потребовалось сделать, чтобы всё в продакшн‑среде работало быстро.

Привет, Хабр! Меня зовут Алексей, я архитектор в команде Скала^р (входим в Группу Rubytech).
Мы разрабатываем программно-аппаратные комплексы (ПАК) — для баз данных, динамической инфраструктуры, интеллектуального хранения данных, больших данных и отраслевых задач в госсекторе, финансах и промышленности. В этой статье — про один из самых молодых, но самых турбулентных классов ПАК в нашем портфеле: инфраструктуру под ИИ-задачи, на примере «Машины искусственного интеллекта Скала^р (Скала^р МИИ)».

Формат статьи немного нетипичный для обзора продукта. Я не буду перечислять фичи по порядку — вместо этого попробую показать путь типового заказчика: с какими проблемами он сталкивается не на этапе закупки, а через два-три месяца эксплуатации, когда стенд уже работает, деньги потрачены, а перформанс почему-то не тот, что ожидался. И сразу — что мы сделали в ПАК, чтобы заказчик в принципе не попадал в эту точку.

В компании есть Kubernetes, GitLab с пайплайнами и стена дашбордов в Grafana. А деплоить всё равно страшно — по пятницам нельзя, релиз согласовывают в личке, о падении прода первым сообщает клиент. Если картинка знакомая, то у меня плохие новости в формате чек-листа. Ниже десять симптомов карго-культа с проверочными вопросами.

Всем привет! Меня зовут Петрович и я работаю техлидом java команды в небольшом международном финтехе. В этой статье я хотел бы поделиться с вами опытом миграции наших сервисов с Redis на Hazelcast, а также о том какие уроки мы усвоили. Статья будет полезна тем кто рассматривает отказоустойчивые и более простые в поддержке альтернативы Redis.

Наша команда отвечает за подсистему оценки платежеспособности клиентов (в народе - скоринг). Стек - классический джентльменский набор для java команды - последняя LTS версия Java, Spring Boot (с Hibernate), база PostgreSQL, брокер сообщений RabbitMQ, авторизация через Keycloak, кэш Redis, собираем в docker контейнеры с помощью jib и деплоим в k8s через gitlab, arttifactory используем для хранения стартеров и библиотек.

В прод окружении наши немногочисленные сервисы работают в кластерах k8s в единственном экземпляре, будучи, как правило, распределенными по 3 нодам с приличным запасом по ресурсам. Сделано так специально чтобы в случае отказа одной из нод другие могли автоматически принять нагрузку с выбывшей из строя напарницы без участия сотрудников разработки или поддержки. Ну и rollout update делать удобно и быстро - у нас распределенный монолит и при деплое необходимо деплоить сразу все сервисы одновременно.

С точки зрения кластеров k8s наша подсистема полностью изолирована и не зависит от других подсистем компании. Другими словами, все необходимые для работы подсистемы ресурсы мы хостим и поддерживаем сами. Redis, Keycloak, S3 - всё это работает внутри каждого из наших кластеров, обеспечивая достаточное резервирование. Всё, кроме Redis.

Хочу поделится с более конкретным примером и подробным описанием настройки плагинов для ArgoCD чем это описано в их офф документации.

Привет! Я Даниил, DevOps-инженер в KTS.

Недавно я поработал со Stackland. Концепция облачноподобной платформы с кучей коробочных сервисов на своем железе в закрытом контуре давно была любопытна нам (и нашим заказчикам), так что пройти мимо готового решения от Яндекса было бы преступлением. По горячим следам я решил написать эту статью, чтобы поделиться опытом развертывания Stackland на голом железе. Так что ниже вас ждет скорее не обзор, а туториал.

Коротко о том, как это было: сначала я подготовил L2-сеть, бастион с NAT, DNS и NTP, три сервера, образ Stackland и YAML-конфиги. Затем запустил sladm install и через час получил консоль, готовый мониторинг с визуализацией в Grafana и возможность по кнопке в UI поднять managed PostgreSQL, Kafka, ClickHouse и другие сервисы.

Подробнее о том, как это было, рассказываю ниже.

Часто первое, что хочется сделать при неполадках в кластере, — уменьшить его и надеяться, что всё решится само. Получается, большой кластер = куча проблем?

Автор статьи решил зайти максимально далеко: поднять Kubernetes-кластер с миллионом узлов и посмотреть, что будет.

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

В 2024 году была опубликована интересная статья, в которой описано, как за 54 дня обучения Llama 3 405B кластер Meta из 16 384 карт H100 пережил 419 внезапных прерываний, примерно по одному каждые три часа. 58,7% из них пришлись на GPU и их память. Процессоры за то же время отказали дважды. Свежее по такому масштабу никто ничего не публиковал, но тренд на Kubernetes с тех пор только усилился: по опросу CNCF за 2025 год, 82% пользователей контейнеров гоняют кубер в проде и 66% компаний с genAI-моделями держат на нем инференс.

Сам Kubernetes до сих пор как будто бы уверен, что отказы лечатся рестартами. Для stateless-сервиса это правда, а вот для пода с GPU нет: если контейнер упадет, то kubelet поднимет его заново на том же мертвом устройстве, и все пойдет по кругу.

Я Стас Погоржельский, технологический евангелист VK Cloud. Про то, как раздавать GPU через DRA, на Хабре уже писали, про отказоустойчивость кластеров в целом тоже. Эта статья про то, о чем обе умалчивают: что происходит после того, как выданное устройство умерло. Мы посмотрим на это наглядно: соберем отказный стенд, отберем у пода GPU и посмотрим глазами kubectl, кто и когда об этом узнает. А потом разберем механизмы 1.36, с которыми из этой ситуации впервые можно выйти без вечного Pending и без убийства ноды целиком.

Прерываемые ноды в Managed Kubernetes появились ещё в феврале 2025 года, и Selectel анонсировал их отдельной статьёй в своём блоге — про экономию до 70% и про то, что «нода оперативно вернётся в кластер, а восстановление займёт не более минуты». Про поды, которые в этот момент на ноде работают, там не сказано ничего: ни про SIGTERM, ни про drain, ни про PDB, ни про потерю данных. Как раз эту дырку мы и полезли закрывать.

SRE‑инженер Mindbox рассказывает, как DevOps‑команда столкнулась с неконтролируемым запуском хаос‑тестов, когда проводила плановые проверки с помощью Chaos Mesh. Что запускало «зомби‑тесты», какие пробовали решения и на чем в итоге остановились — делимся в статье.

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

Привет, Хабр! Меня зовут Михаил Гольбах, я ведущий разработчик интерфейсов Yandex Cloud. Уже несколько лет мы с командой развиваем Ферму — сервис, который поднимает preview‑окружение под каждый пулл‑реквест. В этой статье расскажу, как Ферма выросла из простого self‑hosted‑скрипта на одной виртуальной машине в оркестратор на Docker и Kubernetes и почему в итоге мы открыли её код.

Разработчикам регулярно требовались виртуальные машины, но self-service не существовал. Образ, ресурсы, сеть и доступы настраивала инфраструктурная команда. По отдельности операции были несложными, но в сумме пользователи ждали, а инженерное время уходило на повторяемую ручную работу.

Так появился внутренний dev cloud на KubeVirt. Разработчик сам создаёт VM из поддерживаемого шаблона, управляет lifecycle и портами, меняет ресурсы, смотрит Events, метрики и serial-консоль. Платформа сохраняет контроль над доступами, шаблонами, бюджетами команд и ёмкостью нод.

В статье показано как на базе KubeVirt получился цельный внутренний продукт с минимальными трудозатратами, в котором разработчик действует самостоятельно, а платформа сохраняет контроль над dev-контуром и блокирует создание VM сверх бюджета команды.