На протяжении долгого времени в техническом университете процесс развертывания нового приложения был через архивы с программным кодом, которые доставлялись на виртуальную машину через 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 будущее.
Комментарии (21)
ProFfeSsoRr
16.01.2023 23:38Раз у вас свои железки, то на чем вы делали мастера и воркеры? Прям на железе, или на виртуалках?
mnozhaev
17.01.2023 00:32-1А почему не пробовали установку с kubespray? Или к примеру deckhouse?
Fitrager Автор
17.01.2023 04:17+2Deckhouse однажды пробовал, но тогда не хватило компетенции разобраться. Мне кажется чтобы понять Kubernetes надо начинать с самого обычного k8s и разворачивать поэтапно.
ProFfeSsoRr
17.01.2023 08:55+1Да разобраться в kubespray сложнее, чем в том, как самому kubeadm в ансибл загнать. Ну, прям вот с ходу kubespray конечно поставит кластер, но как только захочется его кастомизировать...
CrzyDocTI
17.01.2023 17:49никаких проблем не возникнет если знаете ansible, а ansible достаточно легок в освоении.
я начинал с ванильного k8s, потом kubespray на ansible - все что требовалось кастомизировать - кастомизировалось за один день максимум.
еще момент - я использовал форк kubespray от southbridge(https://github.com/southbridgeio/kubespray) - они раскатывают кластер целиком при помощи ansible, а последний официальный kubespray использует под собой kubeadm
ProFfeSsoRr
19.01.2023 01:43Так вот, когда неплохо знаешь ansible - запилить свой ansible для kubeadm чуть ли не быстрее, чем разобраться в kubespray. Мы, потратив немало времени на подпиливание kubespray в итоге плюнули, переписали с нуля и это вышло быстро, и работает оно быстро и стабильно. Очень быстро!
а последний официальный kubespray использует под собой kubeadm
Ага, но с костылями, "исторически сложившимися". В общем, как человек, закопавший в kubespray достаточно времени, говорю, что не стоит другим закапывать в него своё время. Если ты понимаешь примерно, как обвязать ансиблом kubeadm - стоит просто это сделать и всё.
CrzyDocTI
19.01.2023 05:37вы и без kubeadm все делали? там и сертификаты выписывались не на год - что в то время еще было головной болью
NealOliver60
18.01.2023 04:01+1Для сборки докер образов присмотритесь к kaniko. Отлично интегрируется с гитлабом, и собирать все будет в том же кубе, от придатка с отдельной вм с докером и dind гитлаб агентами избавитесь.
oller
С мониторингом логов как поступили?
В kubernetes крайне неудобная система логирования, весь вывод консоли в лог, а потом кибаноподобные монстры с сотнями фильтров, для 1000+микросервисов наверное оправдано, для 50+ ну вот вообще никак
ProFfeSsoRr
Эм, k8s тут ничего не изобретал, это best practices для контейнеров в принципе, k8s просто его поддержал.
В чем у вас проблема с логами?
Heggi
Проблема не в логах как таковых, а в "кибаноподобных монстрах", которые хотят ресурсов как не в себя, даже если логов там всего пара десятков мегабайт в день.
stitrace
Можно собирать логи с контейнеров каким нибудь легковесным fluent-bit и отправлять на syslog сервер, у него есть output плагин для syslog. В централизованном хранении логов много плюсов, это у вас сейчас их 50 мегабайт в день, дальше будет больше и у вас уже будет реализованное решение.
Fitrager Автор
Спасибо за идею. Попробую.
Heggi
Сейчас у нас несколько серверов с голым докером, который пишет логи в syslog. Попытки заменить это все на кубер заканчивалось тем, что система логирования (ELK) требует выделить под это все еще один сервер как минимум.
Вариант с Loki, конечно, легковеснее, но все-равно.
А вот то что fluent-bit может писать в syslog - это открытие надо пощупать. Это то что нам и нужно.
ProFfeSsoRr
Ну так конкретнее, какие монстры? Loki ресурсов меньше эластика потребляет, к примеру.
Heggi
Легковеснее сислога нет ничего, наверное :)
Тут уже подсказали как научить кубер писать в сислог, буду экспериментировать.
ProFfeSsoRr
А смотреть потом из сислога чем? ;)
Heggi
Консолью. У нас нет необходимости в каком-то веб-интерфейсе и прочих свистелках для просмотра логов.
Fitrager Автор
Для разработчиков я делаю job в Gitlab, которая выводит логи их приложения прямо в Gitlab. Какой-то централизованной системы логов пока нет.