Инженеры Southbridge помогли IT-команде «АльфаСтрахования» обеспечить бесперебойное функционирование и масштабирование двух кластеров Kubernetes, настроить CI/CD и обеспечить мониторинг кластеров и приложений, работающих в них.
Стек проекта:
VMware, Kubernetes, Docker, Gitlab (CI, gitlab-runners DinD), Helm 3, Prometheus, VictoriaMetrics, Fluent Bit, HAProxy, Velero, EFK, Pacemaker/Corosync.
Знакомство с проектом
В начале 2020 года к нам на поддержку пришёл проект «АльфаСтрахования». Явных проблем с кластерами и инфраструктурой заказчика не было. Инженеры Southbridge провели аудит двух кластеров Kubernetes, на основе которого внедрили изменения в проект. Ниже — итоги аудита и реализованные технические решения.Обновили и привели в соответствие версии Docker и ядер Linux
❌ На некоторых нодах различались версии Docker и ядер Linux, что могло вызвать разное поведение софта, запускаемого на этих нодах.✅ На тот момент клиент использовал версию кластеров 1.15.3. Сначала мы обновили её до 1.16.14.
Репозиторий кубспрея был развёрнут с неточностями. Код был запущен без копирования истории Git — обновлять его из Upstream стало невозможно. Кроме того, при добавлении инвентаря в каталог prod был затёрт существующий пример. Мы склонировали репозиторий в новый каталог кубспрея, добавили в него ветку alfastrah, в которой создали инвентарь inventory/alfastrah. В него перенесли инвентарь из старого кубспрея и добавили обновления.
Дальше без даунтайма обновили версию Docker с 18.9.7 до 19.03.12.
Вместо kernel-ml поставили ядро kernel-lt и сделали yum update. Дали доступ на запись кубспрея: добавили публичный ключ пользователя southbridge в проект в global-infrastructure/kubespray как deploy key с правами на запись.
После обновления Docker запустили обновление кластера также без даунтайма.
В итоге мы обновили версию K8s-кластера с 1.15.3 до 1.17.11 (работы происходили в январе 2021 года, сейчас эта версия уже устарела — прим. редакции), и версии ядер Linux и версии Docker были приведены к одинаковому состоянию.
Решили проблемы с деплоем приложений
❌ Приложения заказчика деплоились без реквестов и лимитов. В принципе, это не такая уж страшная штука, но она могла привести к неприятным последствиям. Например, вызвать некорректную работу шедулера при распределении подов. Также деплои без реквестов и лимитов иногда приводят к тому, что два пода с большой утилизацией по CPU попадают на одну ноду и из-за этого работают нестабильно.✅ По согласованию с клиентом, разработчики добавили в свои чарты реквесты и лимиты для приложений. На случай если разработчики всё же где-то забудут указать ограничения, мы дополнительно добавили LimitRange в неймспейсы.
По итогу аудита безопасности в кластерах мы настроили PSP, а в рамках обеспечения доступности приложений настроили PDB.
Настроили системные сервисы
❌ Большинство системных сервисов в кластерах заказчика — NGINX Ingress, Fluent Bit, Prometheus — когда-то были установлены с помощью Helm 2. Позже Helm 2 выпилили и заменили на Helm 3. Новый Helm не видел системные сервисы, и они стали работать, как обычные deploy/daemonset и т. п., что вызывало кучу неудобств для внесения изменений в конфиги.✅ Мы подробно разобрали все конфиги на предмет таких custom-изменений, как дополнительные ScrapeConfig или custom rules Prometheus, и подготовили новые чарты приложений.
После согласования с клиентом сделали резервные копии всех текущих манифестов приложений. Старое ПО вручную удалили и установили новое через Helm 3. После обновления выяснилось, что некоторого функционала не хватало, так как часть конфигов была в secret в виде base64. Мы их добавили в виде values-чартов.
Также в системном ПО кластера не велась версионность конфигов системных приложений. После обновления ПО и перевода на Helm 3 заливать любые изменения в Git стало нормой.
Перевели раннеры под управление K8s-кластеров
❌ В кластерах использовался GitLab Runner, настроенный на одном из внешних серверов.Раннер на внешнем сервере — это не очень хорошо. Основные проблемы:
- Требуется открывать доступ к K8s API. Иногда API открывают на весь мир, что небезопасно.
- Деплой в кластер Kubernetes зависит от канала связи между раннером и кластером K8s. Если во время деплоя на канале связи возникнет сбой, деплой не пройдёт успешно. Для разных типов приложений это может иметь разную степень критичности. Например, этот момент важно учесть, разрабатывая механизм миграции в базу данных. Если связь прервётся при миграции, можно получить проблемы, которые придётся устранять вручную.
✅ Мы перевели раннеры под управление кластеров Kubernetes.
Установили алертменеджер и настроили хранение логов
❌ Клиент не использовал алертменеджер.✅ Мы установили и настроили его, а также по согласованию с заказчиком распределили по группам некоторые алерты. К примеру, алерты из NS *-dev-* не поступали в наш Redmine, а направлялись разработчикам.
❌ В разработке участвовало несколько групп разработчиков, каждая из которых работала в своём приложении. При этом все логи из кластера писались в один индекс Elasticsearch, и разным группам было неудобно искать свои логи в общей куче.
✅ Мы сделали для каждого приложения свой индекс. Кроме того, выделили отдельный индекс для логов системных приложений. Так стало гораздо удобнее и разработчикам, и администраторам кластера.
Вырезка из values.yml чарта fluent-bit: https://xpaste.pro/p/NcGWfKKg
Дополнительно потребовалось решение, которое позволило бы писать логи Fluent Bit в ELK-кластер, состоящий их трёх хостов. Встроенный proxy Fluent Bit так делать не мог. Такую возможность поддерживает только плагин Forward, а в нашем случае, чтобы до ELK нормально доходили данные, нужен был Output. Мы решили использовать HAProxy, развёрнутый из Helm-чарта прямо в неймспейс с Fluent Bit.
Настроили хранение метрик
❌ В какой-то момент Prometheus начал раздуваться по памяти и постоянно перезапускаться. Как оказалось, проблема была в InfluxDB, который после перезагрузки восстанавливал свою работоспособность.✔ В итоге мы заменили InfluxDB на более лёгкую и быструю VictoriaMetrics.
Подключили систему резервного копирования
❌ В кластерах не было системы резервного копирования. В целом всё, что устанавливается в кластер, разворачивается из git-репозиториев — при потере данных изменения из репозиториев можно внести заново. Но восстановить потерянные данные с бэкапов гораздо быстрее и легче, особенно если эти данные потребовались спустя какое-то время.✔ Мы установили Velero — теперь бэкапы сохраняются в S3-облако. Дополнительно был подготовлен disastery-план на случай, если кластер выйдет из строя.
Результат
В результате инженеры Southbridge:- Обеспечили функционирование и масштабирование двух кластеров Kubernetes.
- Видоизменили системные компоненты кластеров.
- Обеспечили поддержку поставок изменений (CI/CD) в кластерах Kubernetes.
- Обеспечили мониторинг кластеров и приложений, работающих в них.
- Создали дашборды в Grafana.
- Обеспечили доступность кластеров и работающих в них приложений в режиме 24/7.
- Сформировали и обеспечили для кластеров поддержку в актуальном состоянии DRP.
- Совместно со службой 24/7 обеспечили оповещение и помощь в эскалации по всем проблемам кластеров.
Планы
У заказчика в качестве балансировщика трафика используются две ноды с установленным Virtual IP на основе Pacemaker + Corosync. На нодах стоит NGINX Ingress.Решение с Virtual IP работает довольно хорошо. Но при определённых настройках в среде VMware может не происходить миграция IP. Это создаёт потенциальные проблемы — периодически проекты могут быть недоступны за балансировщиком.
В дальнейшем планируется переезд на аппаратный балансировщик, вынесенный за пределы кластеров.
