Кейсы клиентов

Стек проекта: VMware, Kubernetes, Docker, Gitlab (CI, gitlab-runners DinD), Helm 3, Prometheus, VictoriaMetrics, Fluent Bit, HAProxy, Velero, EFK, Pacemaker/Corosync.

Проблемы, выявленные после аудита:
— Некоторые приложения деплоились без реквестов и лимитов.
— Helm 3 не видел системные сервисы (NGINX Ingress, Fluent Bit, Prometheus), и они стали работать, как обычные deploy/daemonset и т. п., что вызывало кучу неудобств для внесения изменений в конфиги.
— В кластерах использовался GitLab Runner, настроенный на одном из внешних серверов.
— Все логи из кластера писались в один индекс Elasticsearch, и разным группам разработчиков было неудобно искать свои логи в общей массе.
— В кластерах не было системы резервного копирования.

Решение:
— По согласованию с клиентом, разработчики добавили в свои чарты реквесты и лимиты для приложений. На случай если разработчики всё же где-то забудут указать ограничения, мы дополнительно добавили LimitRange в неймспейсы.
— Сделали резервные копии всех текущих манифестов системных приложений (NGINX Ingress, Fluent Bit, Prometheus). Старое ПО вручную удалили и установили новое через Helm 3.
— Перевели раннеры под управление кластеров Kubernetes.
— Установили и настроили алертменеджер, а также по согласованию с заказчиком распределили по группам некоторые алерты.
— Сделали для каждой команды свой индекс и выделили отдельный индекс для логов системных приложений. Так стало гораздо удобнее и разработчикам, администраторам кластера.
— Дополнительно потребовалось решение, которое позволило бы писать логи Fluent Bit в ELK-кластер, состоящий их трёх хостов. Мы решили использовать HAProxy, развёрнутый из Helm-чарта прямо в неймспейс с Fluent Bit.
— Установили Velero — теперь бэкапы сохраняются в S3-облако. Дополнительно был подготовлен disastery-план на случай, если кластер выйдет из строя.

Результат: инженеры Southbridge обеспечили функционирование и масштабирование двух кластеров Kubernetes. Видоизменили системные компоненты кластеров. Обеспечили поддержку поставок изменений (CI/CD) в кластерах Kubernetes. Обеспечили мониторинг кластеров и приложений, работающих в них. Создали дашборды в Grafana. Обеспечили доступность кластеров и работающих в них приложений в режиме 24/7. Сформировали и обеспечили для кластеров поддержку в актуальном состоянии DRP. Совместно со службой 24/7 обеспечили оповещение и помощь в эскалации по всем проблемам кластеров.

Еще больше подробностей в блоге

Возможности платформы:
— формирование данных на основе фотографий, аудио записей и ответов на вопросы по продуктовой категории, которые делают потребители с помощью мобильного приложения;
— обработка данных системой распознавания изображений и модераторами, после которой результаты доступны в онлайн-аналитике;
— интеграция аналитики в мотивационную программу полевого персонала и менеджмента для улучшения торговых показателей.

Присутствовали проблемы:
— скрипты деплоя были написаны на Shell и расположены непосредственно в репозиториях приложений; учитывая, что приложения разрабатываются в некотором кол-ве веток (до 10-20) это делало весьма трудоёмким (и чреватым ошибками) внесение правок в систему деплоя;
— в Deployments не были указаны requests/limits, вследствие чего нагрузка распределялась по нодам весьма неравномерно. Readiness/liveness probes также не указывались, что вызывало необходимость ручного перезапуска контейнеров (подов) с приложениями по любому поводу - от подвисания приложения до рестарта БД;
— автоматического фейловера для postgresql не было, при сбоях master'ов приложения падали, пока администратор вручную не поднимет базу или сервер;
— не производилось резервное копирование PostgreSQL (бэкап предыдущим подрядчиком был настроен на свои мощности и ушёл вместе с ним - остался только быстро растущий архива WAL, съедающий место на дисках);
— автоматический vacuum (или repack) для postgresql не был настроен, из-за чего также постоянно возникали проблемы с заканчивающимся местом на дисках (в несколько баз идёт очень интенсивная запись с профилем, вызывающим bloating);
— redis, являющийся необходимым сервисом для работы приложений (большая часть без него просто не запускается, при отказе redis падает) был развёртнут в k8s как StatefulSet в виде кластера на sentinel и sidecar (представлявшем собой шелл-скрипт иногда отрабатывал непредсказуемо); этот sidecar вхолостую расходовал CPU на нодах и не обеспечивал отказоустойчивости (более того, являлся причиной периодических отказов сервиса redis);
— сетевое взаимодействие между физ. нодами и нодами k8s было настроено с наборами одинаковых IP на linux-bridge и правилами ebtables. Эта схема была создана, очевидно, для обеспечения отказоустойчивости при выходе одного из серверов из строя, но была несколько недоработана и крайне трудоёмка в понимании и поддержке.

Используемый стек технологий: CentOS GNU/Linux, Kubernetes, Gitlab, Ceph, PostgreSQL, Redis, Pacemaker, Ansible.

Решение: Для обеспечения поставленной цели были предприняты следующие действия:
— разработан отказоустойчивый сетап с автофейловером для PostgreSQL на базе Pacemaker с ресурс-агентом pgsql, развернуто несколько трёхнодовых кластеров и на них смигрированы все БД;
— настроена непрерывная архивация PostgreSQL, позволяющая восстановить состояние любой базы на любой момент времени за несколько дней назад;
настроен pg_repack по расписанию для таблиц с выраженным bloating (написан скрипт-обёртка для обхода проблемы незакрытых транзакций и вычисления необходимого дискового пространства);
— развёрнут новый кластер Kubernetes, в него смигрированы все приложения, старый кластер уничтожен;
— для обработки отказов вида "падение ноды с ingress" применена кластеризация Pacemaker с ресурс-агентом kumina-hetzner-ip для управления Hetzner Failover IP;
redis вынесен из k8s, для него разработан фейловер на Pacemaker + HA redis;
— деплой приложений в k8s был полностью переписан на ansible, применены resource requests и limits; также по просьбе разработчиков была применена схема blue-green deploy, позволяющая мгновенно и без простоя переключать трафик со "старого" кода на "новый".

Результат: Стабильность работы приложений значительно выросла, простои по вине инфраструктуры значительно сократились (пока не в 0, но мы продолжаем поиски решения комплексных проблем, связанных с растущей нагрузкой от приложений), трудоёмкость обслуживания уменьшилась в десятки раз (в основном, всё "просто работает").
Инфраструктура активно развивается, были развернуты новые экземпляры приложений и баз в других локациях (и планируется ещё).

Используемый стек технологий: Gitlab (CI, registry, gitlab-runner), Helm v3, Prometheus, Grafana, PostgreSQL, EFK, Kubernetes, Redis, Kafka, Clickhouse

Решение:
— развернут новый кластер k8s,
— создана репликация master-slave PostgreSQL,
— разработан унифицированный CI для всех микросервисов через Helm,
— добавлены окружения для тестирования,
— дополнительно на серверах вне кластеры были подняты apache Kafka и Clickhouse (необходимо для работы приложения).

Результат: Построен отказоустойчивый кластер с системой мониторинга и логирования. Доступность инфраструктуры вышла на уровень 99.95%, а небольшая доля простоев не связана с проблемами инфраструктуры. Из-за унифицированного CI клиенту стало возможным управлять им самостоятельно без привлечения инженеров, на базе этого CI позже были добавлены другие проекты. В дальнейших планах, при росте нагрузке, настроить масштабирование приложения.