На протяжении долгого времени в техническом университете процесс развертывания нового приложения был через архивы с программным кодом, которые доставлялись на виртуальную машину через ftp и запускались вручную. И у каждой команды под каждую систему была своя виртуальная машина. Ресурсы расходовались не оптимально. Временным решением стало создание одной виртуальной машины под все небольшие проекты, но процесс администрирования всего этого лег на разработчиков, которые не хотели этим заниматься.
К Kubernetes мы присматривались два года. Изучали различные статьи, пытались его разворачивать, но после развертывания не понимали что делать дальше. Пока однажды мы не решили попробовать завернуть одну из систем в контейнер. Для оркестрации контейнера была выбрана система Docker Swarm, так как она проще, и тут возникла первая проблема – в выбранной системе была авторизация, а Docker Swarm проблема с сохранением сессии пользователя если контейнеров больше одного (мы использовали ADFS для авторизации в системе) – т.е. текущая сессия пользователя не сохранялась и при обновлении страницы выходила стратовая. Поиск различных решений сводил к одному – нужен Kubernetes с его Ingress контроллером, где есть «липкие сессии» (sticky session). При выборе дистрибутива было принято решение использовать «ванильный» k8s.
В очередной раз установив Kubernetes начался поиск решения как доставить туда наш контейнер. Контейнеры собирались на отдельной виртуальной машине и загружались в локальный Docker Container Registry, а чтобы развернуть этот контейнер в Kubernetes использовался Gitlab Runner на мастере. Не самое лучшее решение, но компетенций на другое не хватало. И вот когда Deployment был развернут возник вопрос. Как вывести контейнер наружу. Так как мы использовали Bare Metal конфигурацию, то при первом запросе в Google вылез Metal LB. Если бы мы знали тогда, что можно использовать Ingress Nginx с параметром Host Network: True, то это сэкономило бы нам месяц экспериментов с Metal LB и мы знали, что от него можно сразу отказаться. Для Metal LB использовалась L2 конфигурация, где создавался виртуальный пул адресов, который виден только внутри кластера. А как вывести это наружу? Конечно установить Nginx на мастер и прописывать виртуальные адреса в /etc/hosts, чтобы Nginx их видел. К счастью в голове тогда была мысль, что это как-то неправильно.
И когда узнав про Host Network был поднял кластер из трёх мастеров и трёх рабочих нод без Metal LB. Правда кластер был инициализирован через обычного пользователя user, а не root и для того, чтобы Gitlab Runner видел кластер – его пришлось добавлять в группу user. Опять же вся отказоустойчивость рассыпается, когда все развертывание идет через один мастер. И начались поиски лучшего решения.
Итоговая инсталляция развернута с помощью kubeadm. Кластер включает в себя 3 master и 3 worker. Сетевой плагин - weave.net, а Ingress контроллер это Ingress Nginx развернутый как Daemon Set для отказоустойчивости систем при отказе одной рабочей ноды. В кластере Kubernetes развернуты только с Stateless приложения с сохранением своих данных на PV томах автоматически создаваемых на СХД через NFS provisioner, в отдельных БД (MSSQL, MYSQL, PostgreSQL) и на S3 Minio. CI/CD построено на базе Gitlab со сбором докер образов на отдельной ВМ и развертыванием их через gitlab-agent и gitlab-runner установленных в кластере Kubernetes.
Использовав лишь часть функционала Kubernetes мы получили экономию серверных ресурсов перенеся часть систем из виртуальных машин в контейнеры. Получили отказоустойчивость «из коробки» и простой вариант развертывания системы, где лишь надо правильно собрать Docker образ и проверить что он запускается. За Kubernetes будущее.
