Тестовое задание на позицию SRE в Mindbox

Этот репозиторий содержит решение тестового задания, ключевой особенностью которого является не только разработка YAML-манифестов, но и создание полностью автоматизированного тестового стенда, который доказывает работоспособность предложенных архитектурных решений.

---

🚀 Быстрый старт

Проект полностью автоматизирован. Весь процесс — от настройки окружения до запуска тестов и очистки — выполняется одной командой.

1. Пререквизиты

Для запуска вам понадобится система на базе Debian/Ubuntu (включая WSL2) со следующими, уже установленными, инструментами:

• Git
• Docker (и Docker Desktop для пользователей Windows/WSL)

► Справка: Как установить Docker?

• Для Linux (Ubuntu/Debian): Следуйте официальной инструкции. Важно: после установки добавьте своего пользователя в группу docker (sudo usermod -aG docker $USER) и перезайдите в систему.

• Для Windows (через WSL2): Установите и запустите Docker Desktop. Затем в настройках Docker Desktop (Settings -> Resources -> WSL Integration) включите интеграцию с вашим дистрибутивом Ubuntu.

2. Запуск

Откройте терминал, склонируйте репозиторий и запустите универсальный скрипт run.sh. Он сделает всё остальное.

# Клонируйте репозиторий на локальную машину
git clone https://github.com/ainursheg/mindbox-sre-test.git
cd mindbox-sre-test

# Сделайте скрипт исполняемым и запустите его
chmod +x run.sh
./run.sh

Скрипт автоматически проверит и установит kubectl, kind и ansible, после чего запустит полный цикл тестирования. В конце вы увидите детальный отчет о состоянии кластера.

---

📝 Описание решения

Подход и процесс разработки

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

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

Архитектурные решения

Вся конфигурация приложения инкапсулирована в Helm-чарт, который находится в папке helm-chart/. Такой подход позволяет версионировать, настраивать и управлять жизненным циклом приложения как единым целым.

Все шаблоны внутри чарта подробно прокомментированы.

1. Максимальная отказоустойчивость

• Распределение по зонам (podAntiAffinity): Правило в kubernetes/01-webapp-deployment.yaml запрещает планировщику размещать поды одного приложения в одной и той же зоне доступности (topology.kubernetes.io/zone), защищая от сбоя целой зоны. Работоспособность этого механизма проверяется автоматическим тестом в плейбуке.
• Защита от плановых работ (PodDisruptionBudget): Манифест kubernetes/04-webapp-pdb.yaml гарантирует, что при плановых работах (например, обновлении нод) будет доступен как минимум N-1 под.
• Автоматическое восстановление (livenessProbe / readinessProbe): Настроены в kubernetes/01-webapp-deployment.yaml для автоматического перезапуска "зависших" контейнеров и исключения неготовых из ротации трафика. initialDelaySeconds учитывает время инициализации приложения.

2. Минимальное потребление ресурсов

• Автомасштабирование (HorizontalPodAutoscaler): kubernetes/03-webapp-hpa.yaml настраивает HPA для автоматического изменения количества подов (от 2 до 5) в зависимости от нагрузки на CPU. Это позволяет экономить ресурсы ночью и выдерживать пики днем. Работоспособность HPA доказывается стресс-тестом в плейбуке.
• Эффективное управление CPU (requests vs limits): В kubernetes/01-webapp-deployment.yaml установлены разные значения requests: "100m" и limits: "500m". Это позволяет поду потреблять минимум ресурсов в простое (requests), но разрешает "разгоняться" при пиках, например, на старте (limits).
• Стабильное управление памятью: requests и limits для памяти установлены в 128Mi, так как ее потребление стабильно. Это дает поду высокий QoS-класс "Guaranteed" по памяти, защищая его от OOM kill.

Отладка и решенные проблемы

В процессе создания стенда были решены следующие практические задачи, что является важной частью работы SRE-инженера:

1. Проблемы окружения WSL: Решены типичные проблемы совместимости Docker Desktop и WSL, включая конфликты docker context и сетевые таймауты при доступе к внешним ресурсам.
2. Конфигурация Metrics Server в Kind: Стандартная установка Metrics Server не работает в Kind. Проблема была решена через многоступенчатую отладку на основе логов и событий пода, и финальный, всеобъемлющий патч с помощью Kustomize, который исправляет аргументы запуска и настройки securityContext.
3. Тестирование HPA: Отлажена работа генератора нагрузки для создания стабильного и достаточного потока запросов, чтобы HPA корректно реагировал. Была решена проблема "CPU Throttling", когда генераторы нагрузки "душили" всю систему, не давая приложению возможности отмасштабироваться.

Что можно улучшить (Next Steps)

1. CI/CD: Интегрировать run.sh или Ansible-плейбук в CI/CD пайплайн (например, GitHub Actions) для запуска тестов на каждый коммит.
2. Улучшение Helm-чарта: Вынести больше параметров в values.yaml, настроить зависимости от других чартов (например, базы данных) и опубликовать чарт в ChartMuseum.
3. GitOps: Настроить ArgoCD/Flux для автоматического применения изменений из Git-репозитория в кластере.
4. Мониторинг и логирование: Развернуть стек Prometheus/Grafana для сбора метрик и Loki/Fluentd для централизованного сбора логов.