Сегодня Kubernetes — одно из наиболее оптимальных решений для работы с микросервисной архитектурой. Но это не традиционная комплексная система PaaS. В ванильный K8s входит несколько стандартных компонентов, которые отвечают только за минимальный набор необходимых функций. Но для эффективной работы приложений и деплоя продуктовой среды необходимо множество дополнений — CNI, СSI, DNS, Ingress контроллер, внешние LB и т. д. Цель нашей команды — готовая для комфортной работы с кластером PaaS‑платформа. В этой статье мы расскажем, как готовим Kubernetes в dBrain.cloud, чтобы ее достичь.

В этой статье будет рассмотрен принцип работы Kata Containers, а также будет практическая часть с их подключением к Docker.

Вот мы и подобрались к самому интересному: запуску Kubernetes в Kubernetes. В этой статье мы поговорим о таких технологиях, как Kamaji и Cluster API, а также о том, как интегрировать их с KubeVirt.

В прошлых статьях мы уже рассказывали, как мы готовим Kubernetes на bare metal, и о том, как превратить Kubernetes в средство запуска виртуальных машин. Эта статья завершает серию, объясняя, как, используя всё вышеперечисленное, можно построить полноценный managed Kubernetes service и запускать виртуальные Kubernetes-кластеры по клику.

И начнём мы, пожалуй с Cluster API.

Продолжение статьи о продуктовой гипотезе и дистрибуции. Здесь — только инженерная часть.

Эта статья — инженерный рассказ о том, как из набора разрозненных back-office продуктов выросла единая B2B SaaS-платформа.

Мы показываем путь от требований и прототипов до микросервисной архитектуры, объясняя не только что было сделано, но и почему именно так.

Клиенты часто спрашивают, как построить геораспределенный и катастрофоустойчивый Kubernetes. Так, чтобы при отказе целого дата-центра нагрузка переключалась на резервную площадку без смены IP-адресов сервисов.

Можно возразить, что проще изменить DNS-запись и направить трафик на инстанс в другом дата-центр. Но есть риск: кэширование на рекурсорах некоторых провайдеров может негативно повлиять на доступность. Они иногда игнорируют TTL и хранят старые данные неопределенный срок. Поэтому в таких сценариях крайне желательно сохранить IP-адрес.

Один из элементов «мозаики» такой геораспределенной системы — балансировщик нагрузки с возможностью использования адресов из anycast-подсети, которую выделяет поставщик услуг. В этой статье мы не будем затрагивать вопрос передачи данных и их консистентность на двух разных площадках — разберем только сетевую составляющую. Подробности под катом!

Начало всех начальных начал 

Добрый день, уважаемые хабропоселенцы;‑) Сегодня мы будем говорить, снова о хакатонах и разработке RAG‑моделей, вернее моделей с RAG‑подходами и наших попытках выйти за рамки простого векторного поиска. Не так давно мы участвовали на всероссийском хакатоне «Альфа‑Будущее», организованным Альфа‑Банком и посвящённому настройке RAG для вопросно‑ответных систем. 

Нам необходимо было создать интеллектуальный pipeline RAG‑системы, которая по пользовательскому запросу находит релевантные фрагменты в корпусе данных. Вообще, было на выбор две задачи, вторая звучала как «Разработка copilot приложения для клиентов микробизнеса», но нам ближе оказалась вторая задача. И, конечно же, мы «запилили» своё «модное» решение, о котором вам спешим рассказать в этой статье. Мы проиллюстрируем, как выстраивали архитектуру, какие модели тестировали, на чём остановились и почему, именно такой подход оказался для нас наиболее удачным. Покажем, как работает весь пайплайн — от чанкования документов до гибридного поиска и поделимся результатами бенчмарков и планами развития системы в дальнейшем. Всех заинтересованных лиц приглашаю по традиции под кат;-)

В компаниях с несколькими продуктами знания о коде и архитектуре почти неизбежно расползаются. Часть живёт в репозиториях, часть — в статьях с архитектурными решениями, часть — в корпоративной базе знаний (в нашем случае — Confluence). На небольшом масштабе это выглядит как порядок. Но по мере роста начинают проявляться системные эффекты.

Появляется дублирование функционала с разными подходами. Сложнее становится погружаться в новый продукт при кросс-командных переходах. Поиск по каждому репозиторию и каждому пространству документации по отдельности — медленный и утомительный. В итоге вопросы уходят к «знающим людям», которые постепенно превращаются в узкое горлышко.

Мы столкнулись с этим в явном виде и сформулировали задачу так: дать разработчикам и системным аналитикам быстрый и актуальный поиск по всей кодовой базе компании с возможностью диалога через универсального агента.

В этой статье я расскажу, как мы построили локальный RAG-сервис, оформили его как MCP-сервер и подключили к IDE. Подход будет полезен командам с большим количеством репозиториев, внутренней документацией и требованиями к безопасности.

Надоели чат‑боты, которые только болтают? Создаём настоящего ИИ‑помощника: читает файлы, ищет в сети, запоминает всё. LangGraph + MCP — пошаговый гайд для Python‑разработчиков. Меньше теории, больше работающего кода.

— Два готовых агента: классификатор вакансий + файловый помощник
— Поддержка Ollama, OpenAI, DeepSeek — выбирайте любую модель
— Асинхронная архитектура с обработкой ошибок
— Полная интеграция в Python‑проекты без no‑code конструкторов
— Код готов к продакшену: логирование, retry‑механизмы, конфигурация

От настройки окружения до рабочего агента за час.

Задумывались ли вы когда-нибудь, как построить самое стабильное приложение в мире? Какими свойствами оно должно обладать и какие архитектурные подходы делают это возможным? Впечатляет, что приложения вроде Discord и WhatsApp выдерживают миллионы одновременных пользователей, тогда как другие задыхаются уже на нескольких тысячах. Сегодня посмотрим, как Erlang позволяет обрабатывать огромную нагрузку и при этом держать систему живой и стабильной.

Это вторая статья - техническо-практический разбор протоколов и интерфейсов автоматизации сети.

Если хочется исторической справки, я отсылаю читателя к статье-спутнику, в которой мы двигаемся от начала времён в будущее человечества. Какую роль сыграли в нашем настоящем IETF, ISO, олдовые и современные вендоры и даже просто люди.
В этой же мы раскрываем дерево XML, пробуем на вкус капабилити NETCONF, шлём первые RPC и наконец уже расставим в правильном порядке буквы YANG, OpenConfig, gNMI.

Практическую пользу вам принесут только обе прочитанные статьи. Вторая без первой будет непонятна. Первая без второй - беллетристика.

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

В последние несколько лет все больше и больше людей ищут возможность войти в ИТ или повысить уровень своей квалификации. Вместе с тем полноценных обзоров по основам наиболее популярных технологий (Linux, виртуализации, контейнеризации и др.) написано не так уж и много (особенно на русском языке).

Главная задача данной статьи – объяснить начинающим специалистам необходимость виртуализации, указать на точки ее практического применения и дать ключевые понятия для дальнейшего изучения. По этой причине (а еще, безусловно, вследствие недостаточной квалификации автора) теоретический материал достаточно сильно упрощен.

В начале не было ничего. И создал DevOps кластер Kubernetes и сказал, что это есть хорошо. Но пришли злые программисты и начали требовать информацию о том, сколько ресурсов потребляют их контейнеры.

В этом техническом разборе рассмотрим, как инженеры Harness обнаружили и исправили критическую утечку памяти в Go: переназначение переменной контекста в циклах воркеров порождало невидимые цепочки, мешавшие сборщику мусора освобождать память в тысячах горутин, из-за чего их сервис-делегат CI/CD в итоге потреблял гигабайты памяти.

Покажу вам практическую реализацию семантического поиска на основе векторных представлений - эмбеддингов из текста. Здесь я создам систему, которая анализирует статьи с Хабра, извлекает из них темы и ключевые слова с помощью локально работающих больших языковых моделей LLM, и на основе этих данных создает векторные представления для эффективного поиска по смыслу, а не по запросу на вхождение определенного текста.

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

Для деплоя приложений в Kubernetes существует огромное количество различных инструментов. Если посмотреть на соответствующий раздел в CNCF Landscape, то можно потеряться в разнообразии. Поэтому иногда хорошо иметь в своем арсенале «серебряную пулю», которая подойдет для большинства задач. Helmwave вполне может стать именно таким инструментом.

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

Kubernetes — это не просто оркестратор контейнеров, а целая экосистема инструментов, которые позволяют построить PaaS без написания кода. Helm, ArgoCD, Crossplane, Knative и другие решения делают управление приложениями и инфраструктурой настолько простым, что разработка собственной платформы превращается в задачу конфигурации, а не программирования. Меня зовут Сергей Емельянов, я техлид команды в VK Tech, которая занимается созданием PaaS-платформы на базе Kubernetes для упрощения работы с данными. В серии статей разберем, как создать PaaS, используя мощь Kubernetes и его экосистему.

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

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