Я новичок в Kubernetes. Тем не менее: я хочу добавить возможности аварийного переключения к существующей докеризованной службе, которую вы, вероятно, считаете устаревшей службой, в том смысле, что для нее требуется активная / резервная обработка аварийного переключения (полное обоснование будет довольно длинным для описания, у него есть для пространственной индексации и обработки геоданных, где для данного сценария наличие нескольких активных экземпляров ухудшит ситуацию с точки зрения масштабируемости и производительности, например, сегментирование станет невероятно трудным для обработки).
Моя служба - это HTTP Служба REST (на C ++) является клиентом БД для распределенной БД RQLite, в которой хранятся все данные, управляемые этой службой. Я хочу достичь следующего:
- Я хочу, чтобы 3 сервиса RQLite работали и работали постоянно и, если возможно, распределялись между тремя узлами (NB: сам RQLite использует RAFT с группой по умолчанию из трех ).
- Я также хочу, чтобы 2-3 службы моего собственного приложения работали все время, одна из них должна быть главной, все остальные должны оставаться в режиме ожидания.
- Службы должны иметь возможность знать другой (например, разрешить IP-адреса экземпляров RQLite)
Я мог бы пропустить его, но не знаю, активно ли Kubernetes поддерживает активный / резервный режим. Я нашел несколько устаревших ответов, подобных приведенному здесь ( Как следует контейнеризовать приложение, использующее активную / пассивную избыточную модель, с использованием кубернетов? ).
Но прежде чем рассматривать многие детали, которые все новые для меня, я хотел бы получить ваше объяснение, действительно ли Kubernetes является правильной основой для такого рода сценариев (Nomad может быть лучше для таких «устаревших» приложений?)?
Было бы здорово, если бы вы могли приведу минимальный пример, демонстрирующий, как Kubernetes может решить мои проблемы с отказоустойчивостью.