Всем привет. Может я ошибся чатом, заранее извиняюсь если не

Question

Всем привет. Может я ошибся чатом, заранее извиняюсь если не

по теме пишу.
У нас стоит задача переделать наш legacy сервис, который используется нашими проектами.
В двух словах это куча baremetal'a в разных датацентрах СНГ с единым API, через который мы запускаем игровые сервера (UDP, не нами написанные).
с 2011 года это работает и обновлять ОС, софт и сами игровые сервера это боль. Да еще и каждый отдельный игровой сервер привязан к определенной ноде с определенным ip-адресом. Это неудобно.
Сейчас для нового проекта нам необходимо решить все эти проблемы и то, что тут нужно юзать Docker для сборок игровых серверов, это однозначное решение.
Это дает нам гибкость для автоматического тестирования, выкатывания сразу во все регионы и легкого обновления сборки благодаря layers (скачиваем только мелкие diff's нодах).
Вопрос относительно оркестрации. Насколько уместно тут использовать Kubernetes? Мы хотим умный шедулинг по селекторам, affinity/antiaffinity, да и taints/tolerations куба очень привлекательны, хотим failover в случае падения (то есть перезапуск на другой ноде с минимальным простоем). По сути это stateful, нет никакой балансировки, все пользователи подключаются на один игровой сервер напрямую по указанным ip:port, состояние хранится в памяти и его невозможно реплицировать куда-то. Хотелось бы live migration контейнера в случае maintenance ноды, но с кубом CRIU не работает.
Виртуализация нам не нужна, это ненужный оверхед. Концепция контейнеров идеально нам подходит, т.к. все ворклоады наши.
Также хочется чтобы у каждого контейнера был свой, статический внешний ip-адрес, который бы в случае падения ноды переносился на другую ноду.
Важный момент: запускаем игровые сервера по требованию, нужно как можно быстрее это делать, потому что по ту сторону сидят и ждут пользователи.
P.S. смотрю в сторону куба потому что держим кластера с вебом на нем уже около года

#devops #programming #russian

0

23.12.2018