рисую её план.
Немного вводной инфы:
Продуктовая компания, коробочное решение с возможностью SaaS, клиентов много (200+).
Продукт на PHP, также используется для Asterisk, который с продуктом сильно интегрирован.
БД по большей части PostrgreSQL, местами у есть маленькие MySQL (легаси).
Всё это в Docker контейнерах и разворачивается с Ansible. Код/статика на самих виртуалках. Бекапы делаются регулярно.
Мониторится всё с Prometheus+Grafana, логи в EFK. Релизы несколько раз в год, CI/CD в за(й)чаточном состоянии, тестирование ручное.
Всё это хостится в облаке МТС (требования 152-ФЗ), в vCloud Director.
Для "коробок" клиентов есть общий SaaS "котёл" (одна жирная виртуалка для php-fpm и один большой PostgreSQL с базами клиентов).
Также для "больших" клиентов предлагается развернуть продукт на виртуалке с отдельным IP или их железе.
Выглядит это всё не очень красиво с инфраструктурной точки зрения и не очень удобно управляется.
Поэтому хочу всё это сделать удобным и сделать инфраструктуру с кубом.
Пока что у меня получилась вот такая схема:
Кластер Kubernetes разворачивается в облаке, три namespace (названия условные):
1. System, там всякие инфраструктурные вещи типа мониторинга, алертов, Gitlab, логирование etc.
2. Deploy, там клиенты, поды PHP+NGINX, поды Asterisk.
3. Testing/Demo. Здесь тестовые среды для разрабов, а также демо версии продукта для новых заказчиков, чтобы потыкаться.
"Эмулировать" текущую систему управления производительностью продукта для каждого клиента думаю просто с помощью лимитов/реквестов.
Соответственно, новых клиентов разворачивать не руками с Ansible, а по команде в CI/CD.
Хранилище на Minio, код и статика маунтятся в поды как pv, различные штуки типа записей звонков/документов/etc складываются туда же по S3,
доступ к ним такой же.
Для БД кластер PostgreSQL с Patroni, на отдельных виртуалках, кластер большой, скорее всего.
Для тестов ещё один кластер Patroni, но маленький.
Для старых клиентов до момента переезда небольшой кластер Percona, который можно будет после обновления всех старых клиентов с мускулем выпилить.
Для тех клиентов, которые хотят видеть продукт на своём железе, всё оставить в таком же виде, как оно работает сейчас (контейнеры на отдельном сервере),
но просто доработать процессы с учётом того, что основная часть клиентов всё-таки в кубе. Ещё рассматриваю вариант с k3s на одну ноду, чтобы процесс не переделывать (возможно, идея плохая).
Как с вашей т.з. это выглядит, что мне лучше переработать?
Есть ещё вопросы всякие, но мне пока интересна оценка в целом по тому, что придумал, детали буду раскуривать сам когда буду тестовую площадку делать.
как k8s улучшит текущую ситуацию?
demo/testing в одном кластере с продом может быть больно держать монтировать minio как pv странно выглядит (s3fs-fuse?) asterisk в кубе тоже вероятная боль, но я не работал с ним лет 5, так что хз. В целом выглядит как попытка запихнуть не cloud native приложения в куб. Может быть больно
Обсуждают сегодня