In-memory SQL база данных для k8s

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Приветствую.

Вопрос скорее знатокам k8s и прикручивании БД к ним.
Есть задачка. Довольно древний софт, который с БД умеет работать либо через unixODBC, либо через native MySQL драйвер, либо с redis, но только как с одной нодой, про master-slave/sentinel не знает ничего.
И хочется этот софт запихнуть в k8s, в формате replicaset, т.е. чтобы можно было легко расширяться горизонтально.
Чтобы шарить состояния между нодами (контейнерами в поде в данном случае) есть мысль использовать в соседнем контейнере какую-то in-memory базу данных, но хитрость в том, чтобы они шарили данные между собой. Т.е. при поднятии нового пода через replicaset, новый под мог подтянуть состояние из текущих, плюс, данные должны быть синхронизироваться по мере поступления новых данных.
Что интересно, сохранение данных при выключении всех подов не требуется, поэтому сохранение состояния на диск не обязательно (точнее, даже не требуется, данные не долгоживущие)
Вариант с внешним Redis-хранилищем через ha-proxy возможен, но тут упираюсь в тот момент, что количество деплойментов (каждый в своем namespace) потенциально велико и количество «баз данных» в redis может не хватить.
Вариант в внешним MySQL — есть сейчас, но хочется чего-то другого, без сохранения данных на диск, а в варианте отказоустойчикого кластера только так и можно.
Чтобы понимать количество данных, в пики нагрузок не будет превышать 500МБ/namespace, время жизни от 1 сек до 6 часов. По факту это сессии.
Собственно, ищется какая-то простая in-memory БД с SQL(MySQL/UnixODBC) интерфейсом с возможностью легкого горизонтального масштабирования.

В общем, желаю пинка в нужном направлении гугления/чтения/велосипедостроения.
PS: Посмотрел на VoltDB, он не умеет unixODBC (вроде как).
PPS: Вопрос горизонтального масштабирования старого софта решен на сетевом уровне через anycast IP.