Привет, Хабр! Под конец 2025 года мы в Selectel запустили отказоустойчивый изолированный DNS-сервис и новую конфигурацию для работы с большими объемами данных, представили AI-консультанта для SelectOS и реализовали много других полезных обновлений. Подробности под катом!
10 лет назад мы запустили проект под названием dapp. Сегодня он известен как werf. За это время — тысячи коммитов, сотни релизов, переход на Go, Helm, CNCF, Nelm…
Собрали всю историю в одной статье — от первого Ruby-скрипта до экосистемы Open Source-инструментов.
Когда заходит речь о запуске виртуальных машин в Kubernetes через KubeVirt, первый вопрос, который возникает у инженеров: «А какой там оверхед?» Давайте разберём этот вопрос детально, рассмотрев каждую подсистему отдельно: вычисления, хранилище и сеть.
Статья основана на обсуждении в профессиональном сообществе.
Управление жизненным циклом узлов в Kubernetes легко превращается в марафон ручной настройки — от подготовки окружения в облачных сетапах до регулярного обновления скриптов и корректного удаления узлов. В Deckhouse Kubernetes Platform мы автоматизировали этот процесс, и неважно, работаете вы в облаке или в собственном дата-центре.
В статье технический руководитель команды Deckhouse Core рассказывает, как платформа скрывает сложность управления узлами за понятными ресурсами и инструментами, позволяя безопасно и предсказуемо развёртывать, масштабировать и обновлять узлы без ручного труда.
Команда Go for Devs подготовила перевод статьи инженеров Datadog о том, как из разрозненных пайплайнов вырастить надёжную мультитенантную платформу репликации данных. В материале — практический опыт масштабирования PostgreSQL, переход к асинхронной репликации, автоматизация через Temporal, работа с CDC и Kafka, а также реальные компромиссы между согласованностью, надёжностью и задержками.
Привет, Хабр!
Каждый человек рано или поздно сталкивается с выбором, какой ingress‑контроллер использовать для маршрутизации трафика. Помнится, раньше многие думали, что достаточно взять Nginx и не париться. Но реальность, как это обычно бывает, сложнее. Есть по меньшей мере три мощных игрока: NGINX, Traefik и HAProxy. И у каждого свои фичи и проблема.
Возьмём типичную IT-компанию со штатом в 100 человек. Как думаете, сколько учётных записей существует в их облачной инфраструктуре? 150? 200?
В действительности — около 2000.
И самое удивительное, что только десятая часть из них принадлежит реальным людям. Остальные — это боты, сервисные аккаунты, API-ключи, агенты ИИ, токены CI/CD систем. Они работают 24/7, имеют доступ к критичным данным и почти никогда не попадают в фокус отделов безопасности.
Пока CISO требует от сотрудников двухфакторку и регулярную смену паролей, в том же облаке живёт сервисный токен с правами администратора, созданный три года назад разработчиком, который давно уволился. Никто о нём не помнит. Но он продолжает «работать».
Несколько цифр:
На Хабре про OSTree обычно вспоминают не как про самостоятельную технологию, а как про "то, на чём держатся" Fedora CoreOS / Silverblue / Kinoite и вообще вся тема immutable / atomic desktop / container-optimized OS. Это видно по типовым материалам: обзор CoreOS с объяснением rpm-ostree и layering, обзор Silverblue, новости/разборы релизов Fedora, где rpm-ostree фигурирует как механизм поставки базовой системы.
При этом намного хуже покрыта практическая сторона "как сделать свой цикл поставки": поднять свой OSTree-репозиторий, выпускать свои refs и раскатывать их на узлы так, чтобы можно было обновиться и откатиться, а не как герои трагикомедии "обновили пакеты — и внезапно утро не наступило". На фоне обилия статей "как устроен Silverblue/CoreOS" такой сценарий встречается реже.
Мы раскроем полный цикл от публикации сервера до создания клиентских образов в этой статье.
В статье разбирается практический подход к мониторингу managed PostgreSQL в Yandex Cloud с использованием экспортёра pgSCV. Показано, как выстроить сбор метрик так, чтобы он не создавал дополнительной нагрузки на базу данных, масштабировался вместе с инфраструктурой и оставался управляемым.
Любой «более простой» инструмент DevOps — это просто Kubernetes в темных очках.
Я — Саша Краснов, СТО «Штурвала». Недавно я наткнулся на волшебную статью о Kubernetes, и просто не смог справиться с желанием перевести ее. Мой собственный опыт знакомства с Kubernetes был другим, но путь был похожим: от отрицания и «зачем же так сложно» до восторга от элегантных решений в отдельных контроллерах. Даже архаичные винтажные части, вроде API группы “”, встречающиеся тут и там, больше не раздражают, а вызывают любопытство археолога. Кубер — он сложный, но это не просто так.
После миграции с ClickHouse на StarRocks NAVER существенно оптимизировала обработку многотабличных JOIN. StarRocks повысил производительность запросов, обеспечил бесшовное масштабирование и позволил построить единый слой запросов, совместимый с множеством источников данных. Эти улучшения позволили предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных во всей экосистеме NAVER.
Привет, Хабр! Вы когда-нибудь обновляли ноду Kubernetes-кластера и замечали, как несколько ваших подов сразу пропали в процессе? Не самое приятное ощущение, верно?
Запускаете плановое обновление, kubectl drain начинает выгонять поды с ноды, и вдруг сервис теряет половину реплик. Клиенты начинают получать ошибки. Что пошло не так? Вы забыли про PodDisruptionBudget.
Мы проверили, способен ли ИИ участвовать в реальной инфраструктурной операции повышенного риска — обновлении Kubernetes-кластера сразу через несколько minor-версий.
Речь не про «сгенерировать YAML» или «написать Helm-чарт», а про полноценную операцию:
Предположим, вам необходимо мигрировать ваш кластер k8s в другой vlan или просто сменить ip адреса. Насколько это необходимо каждый решает сам. Будем считать, что перенос нагрузки ямлами на другой кластер затруднён или у кластера специфические настройки.
В качестве начальных условий: кластер on prem с root доступом на узлы, установлен через kubeadm или kubespray, в качестве cni calico. В нашем случае под ногами ubuntu в качестве системы. Если у вас кластер установлен the hard way , то статья вам не нужна, вы сами всё умеете.
В 2023 году к нам регулярно приходили разработчики с вопросом: «Кажется, тупит сеть. Посмотрите?» Вопросы были по делу, и каждый раз отвечать было сложно. Когда тойл от подобных обращений превысил разумные пределы, мы решили разработать SLO на летенси в Ingress. Но оказалось, что это не так уж просто.
Представьте, что однажды утром вы просыпаетесь, а мир вокруг стал другим. Нет, ничего страшного не случилось: ни ледникового периода, ни падения метеорита. Но все сервисы вдруг начали работать так, как работали в те времена, когда про Kubernetes еще никто не слышал.
Когда мы впервые увидели AI-чаты, это выглядело впечатляюще. Они писали код, помогали с документацией, объясняли архитектурные решения.
Это было хорошо. Но довольно быстро стало понятно главное:
Привет, Хабр! Меня зовут Вадим Королёв. Я руководитель команды разработки в X5 Tech. Очень люблю Next.js и решать проблемы, которые он приносит. С ним всегда происходит что-то интересное. Расскажу о причине утечки памяти в Node.js, которая оказалась глубже, чем можно было подумать.
В декабре, перед самым Новым годом, наше приложение начало вести себя так, будто вот-вот рухнет. С ростом пользователей посыпались алерты, вырос трафик, а из команды мониторинга сообщили, что поды в Kubernetes перезагружаются. Пока не падают, но выглядят плохо.
В этот момент я занимался архитектурой и оптимизацией Node.js в музыкальном стриминге. Открыл графики и увидел явный рост памяти, который уходил в пик и приводил к перезапуску подов. Так началась «классическая предновогодняя история». Next.js в Kubernetes внезапно начал есть память так, будто у него внутри чёрная дыра.
В статье подробно разбираем, как устроен CSI (Container Storage Interface), как проходит жизненный цикл тома от PVC до удаления и что на самом деле делают sidecar-контейнеры и драйверы.
Весной этого года NVIDIA открыла исходный код KAI Scheduler — Kubernetes-нативного планировщика GPU-нагрузок, который раньше входил в состав платформы Run:ai и теперь распространяется под лицензией Apache 2.0. Интерес к этому проекту закономерен: планировщик давно работает в продакшене и решает ряд проблем, с которыми сталкивается любая команда, пытающаяся эффективно распределять GPU-ресурсы в кластере.
Мы в Orion soft изучили технические детали KAI Scheduler, чтобы понять, как он устроен изнутри, какие задачи закрывает и какие идеи могут быть полезны инженерам, работающим с Kubernetes, ML-нагрузками и распределёнными GPU-оркестраторами. Ниже — разбор архитектуры, базовых сущностей и цикла планирования.Преимущества KAI Scheduler
Управление AI-нагрузками на GPU и CPU сталкивается с рядом задач, которые традиционные планировщики ресурсов не всегда способны решать. KAI Scheduler был разработан специально для того, чтобы закрыть эти проблемы:
