У нас есть следующий сценарий: В нашем приложении после входа пользователи могут S SH в свою собственную виртуальную среду. Эти среды должны быть полностью изолированы друг от друга и не должны содержать состояния.
Наша цель - создать полностью изолированную контейнерную среду для каждого активного пользователя (запустить образ docker для имитации среды пользователя каждый раз, когда пользователь хочет S SH).
У нас было две идеи для достижения этой цели
Первая идея заключалась в том, чтобы создать микросервис, называемый «диспетчер контейнеров». , Каждый раз, когда пользователь захочет S SH в свою среду, менеджер контейнеров заглядывает в БД, чтобы увидеть, какие модули доступны. Если ни один не доступен (= все используются другими пользователями), менеджер динамически развернет новый модуль, используя kubernetes-client- go. После развертывания модуля он сохраняет в БД, что он «бесплатный». Проблема с этим решением заключается в том, что трафик c от клиента должен быть перенаправлен на указанный модуль c. Я не уверен, что это достижимо, так как стручки эфемерны по дизайну. Как будет работать маршрутизация?
Другой вариант - иметь один микросервис, который запускает контейнер docker каждый раз, когда пользователь хочет ввести S SH в свою среду, а затем уничтожить процесс после выхода пользователя. Проблема в том, что (а) выполняется docker внутри docker и (б) есть несколько процессов, запущенных в одном микросервисе
Есть ли лучший дизайн, поэтому у нас нет иметь привязку «один модуль: один пользователь» и иметь несколько изолированных сред на одном модуле? Какова будет идеальная архитектура Kubernetes для достижения этой цели? Или, может быть, Кубернетес не подходит для такого сценария?