Мониторинг и логирование - не сильные мои стороны, Redis я вижу впервые в жизни, а тонкой настройкой Prometheus, Grafana и подобного не занимался никогда - не было потребностей.
Я - инфраструктурщик. В команде разработки работал только единожды и, возможно, подходы, которые я опишу - не самые оптимальные на практике.
Потестировать написанное было негде, сейчас даже minikube-а нет под рукой. Но насколько я понимаю, такой задачи и не ставилось, главное - описать подход?
"ТЗ" сформулировано очень кратко. Поэтому для начала - несколько допущений.
- Предполагается, что у заказчика нет т.н. disconnected environment - то есть сети, изолированной от Интернета (как, например, в банковских средах) и нет необходимости в предварительных манипуляциях с образами и дистрибутивами ПО (private registry, например).
- Предполагается из формулировок, что развертывать ПО необходимо в существующий кластер Kubernetes, будем считать, что это "ванильный Kubernetes" (а не Openshift, к примеру).
- Имеется доступ уровня роли cluster admin в Kubernetes.
- Persistent Storage на данный момент отсутствует/не требуется. Например, для Redis - снапшоты и логи (RDB и AOF), для Prometheus - long-term storage для метрик (Thanos, Victoria Metrics и др)
- 3 ноды Redis - будем считать, что это 1 мастер-нода и 2 слейва (а не 3 мастера, к примеру). Как уже упоминал, с Redis я не знаком вообще.
- Считаем, что есть все необходимые сетевые доступы, созданы все объекты и выполнены все пререквизиты, специфичные для той или иной среды (IAM-роли для AWS, к примеру)
- Считаем, что "подчиненный" из задачи 2 знает, как подключаться к кластеру Kubernetes, на котором будут производиться работы, и у него есть учетная запись в данном кластере с правами уровня роли cluster admin.
- Как настроены ингрессы в кластере Kubernetes - не указано, поэтому для проверки работоспособности используется port-forward
Из текста задания - нужна параметризация. Как минимум в части следующих параметров:
- кол-во узлов кластера Redis
- кол-во БД в кластере Redis
- кол-во дней ротации метрик
- версия Prometheus
Разумеется, все манифесты и плейбуки должны лежать в VCS (Gitlab, Bitbucket, etc)
Почему Ansible, а не "your_favourite_templating_tool"?
- Я с ним более-менее знаком
- Есть Ansible Vault для шифрования sensitive data в плейбуках
- Ansible не привязан к Kubernetes и при необходимости конфигурирования сторонних ресурсов (виртуальных машин к примеру, для задач того же persistent storage или других) не нужно менять инструментарий
- На мой взгляд, Ansible подходит для задач саппорта L2 (в рамках задачи №2 - для коллеги уровня "middle") - плейбуки разделены на шаги, при выполнении наглядно виден процесс завершения шагов и даже если что-то пошло не так, инженер всегда может указать при эскалации, на каком шаге возникла проблема и что именно за проблема.
- при возникновении потребности можно легко включить в CI/CD конвейер
Почему Helm?
- потому что я не располагаю достаточным количеством свободного времени для того, чтобы проработать задачу без Helm
- потому что в 3 версии уже нет серверной компоненты с требованиями повышения привилегий
- потому что чарты установки Redis и Prometheus через Helm доступны, легко находятся и вменяемо документированы
- потому что параметризация через чарты намного сокращает кол-во файлов конфигурации, автоматически настраиваются экспортеры метрик для Redis и должен работать Service Discovery
- long-term storage для метрик
- persistent storage для Redis
- кастомные метрики исходя из потребностей разработчиков
- установить Grafana, настроить дашборды для отдела эксплуатации/мониторинга
- исключить Helm из цепочки
- оптимизация кластера Redis (репликация, диспетчер/кворум, кол-во узлов и их размер)
- замена Prometheus на Prometheus Operator - готовый настроенный на работу друг с другом набор компонентов для мониторинга рабочих нагрузок в Kubernetes
- дальнейшая шаблонизация/параметризация в зависимости от потребностей
- security-related - включить пароли, Vault, TLS/SSL, и т.д.