❌

Normal view

От FaaS к PaaS: почему я построил собственный оркестратор вместо Kubernetes

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

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

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

Читать далее

Что бэкапить в ИИ-приложении: модель, документы, индексы или историю диалогов?

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

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

Читать далее

Как ограничения научили нас ставить Kubernetes поверх любой операционной системы

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

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

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

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

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

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

Читать далее

Как ограничения научили нас ставить 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 мы реализовали единую гиперконвергентную архитектуру. 

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

Читать далее
❌