К 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 их видел. К счастью в голове тогда была мысль, что это как-то неправильно.