Раньше я уже рассказывал на Хабре об Inquir Compute, который тогда был платформой для запуска serverless-функций. С тех пор проект вырос в PaaS с поддержкой контейнерных приложений, баз данных, фоновых задач и собственной системой управления вычислительными ресурсами.

Вместо Kubernetes или Nomad я решил развивать собственный оркестратор с allocation plane, планировщиком и вычислительными раннерами на containerd. Главная причина не в желании переписать существующие инструменты, а в возможности объединить долгоживущие приложения и serverless-функции в одну ресурсную модель, напрямую связанную с жизненным циклом сервисов и тарификацией платформы.

Расскажу, как развивалась архитектура Inquir Compute, почему я считаю собственный оркестратор правильным выбором для этого проекта, какие задачи удалось решить и над чем ещё предстоит работать.

Привет, Хабр! На связи Михаил Витко, менеджер PaaS-продуктов Рег.облака. Представим ситуацию. После восстановления ИИ-помощник принимает запросы и отвечает без ошибок. Но на вопрос о сроке возврата товара называет 14 дней вместо 30: база уже знает о новой редакции регламента, а поиск работает по старому индексу. Проверка доступности сервиса такую поломку не обнаружит.

В статье подробно разберем, как резервировать RAG-помощника по корпоративным документам и восстанавливать его части в согласованном состоянии. Тема обширная, поэтому мы разделили материал на две части. В первой поговорим о том, какие данные нужно сохранять, что можно пересоздать после сбоя и как организовать резервное копирование в S3, PostgreSQL и Kubernetes. А во второй обсудим, как восстановить приложение без рассогласования данных и проверить, что оно корректно работает после сбоя. 

Привет, Хабр! 

Думаю, вам не надо рассказывать обо всех плюсах Kubernetes и о том, как его использование упрощает жизнь. Так что поговорим о другом — о дистрибутивах Linux, заточенных чисто под K8s: почему они вообще появились, чем они лучше классических дистров, как их ставить, куда душе угодно, а также про Talos OS и её плюшки.

Именно по этой теме я делал доклад для прошлой Kuber Conf от АОТ (видео тут, если вам так проще воспринимать информацию). А для любителей букв я и подготовил эту текстовую версию. Меня зовут Денис Романенко, я техдир Deckhouse Platform во «Фланте».

И начнём мы с базы.

K8s де-факто — это набор Go-контроллеров, для установки которых вам нужен Linux. На заре времён с кубером работали просто: собирали нужные кластеры на стандартном дистрибутиве (почти всегда — серверном), куда и накатывали компоненты Kubernetes.

Да, подход простой и надёжный, почти формата «работает — не трогай», но минусы у него тоже есть.

Привет, Хабр! 

Думаю, вам не надо рассказывать обо всех плюсах Kubernetes и о том, как его использование упрощает жизнь. Так что поговорим о другом — о дистрибутивах Linux, заточенных чисто под K8s: почему они вообще появились, чем они лучше классических дистров, как их ставить, куда душе угодно, а также про Talos OS и её плюшки.

Именно по этой теме я делал доклад для прошлой Kuber Conf от АОТ (видео тут, если вам так проще воспринимать информацию). А для любителей букв я и подготовил эту текстовую версию. Меня зовут Денис Романенко, я техдир Deckhouse Platform во «Фланте».

И начнём мы с базы.

K8s де-факто — это набор Go-контроллеров, для установки которых вам нужен Linux. На заре времён с кубером работали просто: собирали нужные кластеры на стандартном дистрибутиве (почти всегда — серверном), куда и накатывали компоненты Kubernetes.

Да, подход простой и надёжный, почти формата «работает — не трогай», но минусы у него тоже есть.

Привет, Хабр. Меня зовут Павел Кутаков. Я главный архитектор VK Data Platform, VK Tech.

Более 10 лет подход с разделением compute- и storage-слоев де-факто считается стандартом, следование которому позволяет максимально эффективно использовать доступные ресурсы. Но на практике подобный подход применим не всегда — например, по нашему мнению, он не всегда оптимален для построения платформ данных. Именно поэтому при разработке VK Data Platform мы реализовали единую гиперконвергентную архитектуру. 

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

В прошлой статье про Sextant в конце стоял роадмап на четыре версии. Все четыре вышли к 23 октября, а за ними — ещё восемь релизов: алерты из Prometheus и Alertmanager, логи удалённых подов из Loki, OpenShift, OLM, k3s/RKE2, vcluster и фильтры в таблицах. Всего за неделю — 13 релизов, от 0.20.0 до 0.25.5.

Но главное в этой неделе — сообщество. Первые внешние pull request’ы вошли в релизы, идея из внешнего PR сократила память на отслеживаемый объект в пять раз, а целая версия 0.25.5 выросла из одного обсуждения про AI-агентов на кластерах с ограниченным RBAC.

Sextant — десктопный клиент Kubernetes на Rust и Tauri 2, замена Lens без аккаунта и телеметрии, со встроенным MCP-сервером для AI-агентов. Он бесплатный и таким останется. Весь его код сгенерирован Claude Code: человек ставит задачи, принимает архитектурные решения и делает ревью, а каждое изменение много раз проходит тесты.

Под катом — дайджест релизов, обзор нового по темам и благодарности всем, кто присылал баги, идеи и код.

Когда инфраструктура начинает тормозить или что-то ломается после очередного деплоя, важно быстро найти причину и понимать, как её устранить. Для этого нужны знания, которые выходят за рамки привычного стека инструментов. Собрали 14 бесплатных уроков для инфраструктурных инженеров — от диагностики сетевых проблем и восстановления LVM до Kubernetes, CI/CD и DevSecOps, с разбором конкретных задач и практических подходов к их решению.

Развернуть кластер Kubernetes вручную — задача не столько сложная, сколько продолжительная: поднять виртуальные машины, установить компоненты Control Plane, настроить CNI, CSI, DNS, разложить сертификаты. Понять, что надо было иначе, удалить, сделать заново, и так раза три.

Развёртывание — это только первый этап жизни кластера, дальше нужно заниматься поддержанием его деятельности, и это стоит дорого. Каждая рутинная операция эксплуатации в ручном режиме — это десятки человеко-часов и постоянные дежурства.

Вечером, за сутки до переноса четырёх миллионов игроков на новую версию игры, вся российская часть нашей инфраструктуры стала недоступна: после атаки на Yandex Cloud легла зона, в которой она жила. Расскажу, как мы год готовились к этой миграции, какие предположения подтвердились, а какие нет, где нам помог Claude Code с доступом ко всей инфраструктуре и где мы ошиблись, несмотря на его помощь. В конце покажу, что стало с аудиторией и выручкой.

Контейнер упёрся в лимит памяти, но OOMKilled так и не появился. Сервис продолжает работать, задержки растут, CPU почти простаивает, а привычные метрики не объясняют, что происходит. На примере экспериментов с cgroup v2 разберём, как memory.high заставляет процессы ждать освобождения памяти и почему в Kubernetes это может обернуться минутами деградации производительности перед рестартом.

Три часа ночи, API отвечает 500, и рука сама набирает systemctl restart. Иногда это помогает, но есть инциденты, где рестарт добивает то, что ещё работало, и стирает улики. Пять таких: битый конфиг, OOM killer, retry storm, CrashLoopBackOff и диск, забитый логом, — с командами, которые находят настоящую причину, и шпаргалкой на одну таблицу.

Новичок открывает первый кейс, о котором я рассказывал в первой статье., читает брифинг, и через пять секунд сайт пишет: «Готово, жми „Начать“». Он жмёт и смотрит на пустое окно терминала. Секунд через десять там ошибка, страница сама перезагружает терминал, и только потом появляется консоль.

Сервер при этом не падал, CPU и память в норме, алерты молчат. Были только строчки в журнале, которые я чуть не записал в «обычный шум».