Почему Kubernetes и DBaaS не решают все проблемы с базами данных: что даёт OpenEverest

by Laura Czajkowski

Объединяя базы данных и Kubernetes

9 апр. 2026 г. 5 мин.

OpenEverest — это платформа с открытым исходным кодом для автоматизации развертывания и управления любой базой данных в любой инфраструктуре Kubernetes.

Запуск баз данных в Kubernetes популярен. Для cloud-native организаций Kubernetes является стандартным де-факто подходом к запуску баз данных. Согласно Datadog, базы данных — самый популярный рабочий нагрузочный сценарий для развертывания в контейнерах: 45 процентов организаций, использующих контейнеры, применяют этот подход. Сообщество Data on Kubernetes Community обнаружило, что производственные развертывания стали обычным явлением, а самые продвинутые команды запускают в контейнерах более 75 процентов своих рабочих нагрузок с данными.

Изначально Kubernetes не был создан для состояний-зависимых рабочих нагрузок — проекту пришлось разработать несколько новых функций, таких как StatefulSets в Kubernetes 1.9, а позже — поддержку Operator для интеграции с базами данных. После этой работы, проделанной за первые 10 лет существования Kubernetes, можно было бы подумать, что все сложные проблемы, связанные с базами данных в Kubernetes, уже решены. Однако это не так.

Использование базы данных как сервиса с Kubernetes

Сегодня мы можем успешно запускать базы данных в Kubernetes и совмещать эти нагрузки с компонентами приложений, которые также работают в контейнерах. Это упрощает разработку приложений, поскольку вся инфраструктура находится в одном месте и может управляться из одной точки. Хотя такой подход упрощает вопросы «Дня 1» в разработке приложений, он не решает многих вопросов «Дня 2», которые по-прежнему необходимо учитывать.

Проблемы Дня 2 включают все задачи, которые должны быть настроены и работать, чтобы ваше приложение эффективно функционировало с течением времени. Это включает в себя отказоустойчивость, безопасность, эксплуатационное управление и непрерывность бизнеса. Для разработчиков, работающих с базами данных, это означает такие задачи, как резервное копирование, доступность и failover. Некоторые из этих элементов проще в контейнерах. Kubernetes был создан для мониторинга контейнеров в pod-ах и перезапуска образов при возникновении проблемы. Однако состояния-зависимые базы данных требуют более тщательного планирования, чем безсостояниевые приложения.

Operators Kubernetes могут автоматизировать для вас некоторые из этих процессов, позволяя Kubernetes через базу данных инициировать кластер, чтобы автоматически выполнить задачу резервного копирования. Но это не охватывает весь процесс, и он опирается на решения разработчика о том, как лучше всего следовать этому процессу. Если вы не являетесь экспертом в области резервного копирования или доступности, вас может соблазнить передать все эти вопросы стороннему провайдеру, чтобы он занялся ими.

Такой подход работает. Предложения cloud-based database as a service (DBaaS) росли почти вдвое быстрее, чем развертывания on-premises согласно Gartner — 64% против 36% — поскольку разработчики выбирали более простой вариант. Однако это привязывало их к конкретному облачному провайдеру или сервису. Даже если разработчики выбирают базу данных с открытым исходным кодом для своего приложения, они все равно оказываются привязаны к провайдеру и его способу работы. С точки зрения мобильности это может означать серьезные затраты на использование DBaaS вместо самостоятельной реализации.

Будущее Kubernetes и базы данных как сервиса

Автоматизация рабочих нагрузок Kubernetes с помощью Operators может обеспечить тот же уровень функциональности, что и DBaaS, при этом по-прежнему избегая привязки к конкретному провайдеру. Это должно вписываться в то, как команды хотят запускать внутренние платформы для разработчиков или заниматься platform engineering для своих разработчиков. Однако добиться этого для всех баз данных единообразным способом — отдельная задача.

В Percona мы уже делали часть этой работы в рамках нашего собственного проекта Everest. Но он поддерживал только те базы данных, которые интересуют нас, а именно MySQL, PostgreSQL и MongoDB. А как насчет других баз данных, у которых есть Operators? Что насчет других систем для управления и наблюдения за базами данных? Хотя идея полностью open source варианта базы данных как сервиса великолепна в теории, на практике для этого требуется сообщество, готовое участвовать и поддерживать развитие такого решения.

Если вы действительно что-то любите, иногда приходится отпустить это. Как Вуди в Toy Story 3, нужно сказать: «Прощай, партнер», надеясь, что все пойдет «К бесконечности и дальше», как у Базза Лайтера. Именно это мы и сделали с Everest — или, используя его новое имя, OpenEverest. OpenEverest теперь полностью open source проект, в котором может участвовать любой желающий. После того как проект был передан и принят Cloud Native Computing Foundation, запуск баз данных в Kubernetes станет проще для всех. Со временем OpenEverest будет поддерживать больше баз данных в зависимости от того, что хочет видеть сообщество и где оно помогает дополнительными вкладом или поддержкой.

Для разработчиков объединение Kubernetes и баз данных помогает им быть более продуктивными. Но для тех, кто управляет инфраструктурой или решает проблемы Дня 2, связанные с Kubernetes, базы данных по-прежнему остаются потенциально сложными в управлении. Работа с edge cases, автоматизацией и масштабной отказоустойчивостью по-прежнему является серьезным препятствием для баз данных в Kubernetes, однако этот подход остается необходимым, если вы хотите реализовать platform engineering или внутренние платформы для разработчиков без привязки к поставщику. Этот новый проект с открытым исходным кодом — хорошая отправная точка для выполнения этого требования. Превращение его в community open source software project под эгидой фонда, а не в прерогативу одной компании, поможет этому подходу добиться успеха.

—

New Tech Forum предоставляет площадку для технологических лидеров — включая вендоров и других внешних авторов — чтобы исследовать и обсуждать новые корпоративные технологии с беспрецедентной глубиной и широтой. Отбор субъективен и основан на нашем выборе технологий, которые, как мы считаем, важны и представляют наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы для публикации и оставляет за собой право редактировать весь предоставленный контент. Все запросы отправляйте на doug_dineley@foundryco.com.

by Laura Czajkowski

Contributor

Подписаться на Laura Czajkowski в LinkedIn

Лаура Чайковски — директор по развитию сообщества в Percona, компании по базам данных с открытым исходным кодом, работающей с несколькими СУБД, включая MySQL, PostgreSQL, MongoDB, Valkey и другие. Профессиональный опыт Лауры связан с созданием и развитием эффективных сообществ разработчиков вокруг open source и данных. До прихода в Percona Лаура руководила работой с разработчиками и сообществом в компаниях Vonage, Couchbase, MongoDB и Canonical.