Kubernetes cluster
Инфраструктуру я решил строить на kubernetes-кластере (microk8s). Для этого я приобрел у https://www.godaddy.com/ два доменных имени – antivariantum.com и qacedu.com (а позже еще и sdetedu.com). И у https://hetzner.com/ два виртуальных сервера – один под antivatiantum.com и второй под qacedu.com.
- antivariantum.com – матер-нода. На ней располагаются все обслуживающие приложения (мониторинг, безопасность, тестирование производительности), некоммерческие приложения (почтовый сервер, телеграм-бот), старые проекты в отключенном состоянии (тестовый сервер моего старого курса manual qa, которые я включу при необходимости) и этот блог
- qacedu.com – рабочая нода с продуктовыми проектами. Тут разврачиваются продуктовые проекты, на данный момент это API, школа и CoreControl.
Плюсы и минусы такого выбора, планы по изменению
Плюсы:
- SLA (в частности, доступность и производительность). Проводя “небезопасные эксперименты” на ноде antivariantum.com я могу случайно сильно нагрузить ее хост. Но на продуктовую ноду это не повлияет. Это повышает стабильность работы для конечных пользователей коммерческих проектов.
- Безопасность. Использование kubernetes (и docker) дает возможность изолировать приложения. При нарушении безопасности одного из проектов, распространение на другие проекты (боковое движение) злоумышленника может быть затруднительным.
- Автоматическое масштабирование. Kubernetes берет на себя заботу об автоматическом масшатбировании. Достаточно только задать количество replicaset и он создаст такое же колчиесто копий (реплик) подпропроекта и будет распределять нагрузку равномерно между ними.
- Управление распределением ресурсов. Я четко могу задать количество выделяемых ресурсов (CPU, RAM, диск) каждому подпроекту и он не сможет их превысить.
Минусы:
- Требуется много ресурсов. Альтернативный способ использовать docker-composer на много легче по ресурсам, чем kubernetes.
- Четкое разделение подов по нодам (если не понимаете о чем, смотрите ниже) исключает использование одной из главных “фишек” kubernetes – автоматического выбора ноды для размещения пода. Kubernetes рассматривает все ноды кластера как одно целое, даже если ноды разбросаны физически на разные континенты. И сам выбирает место для запуска пода там где есть “место” для развертывания.
Планы по улучшению
Есть смысл иметь два кластера и разделить их так же как сейчас разделено по нодам (обслуживающая и продуктовая)
Коротко про терминологию kubernetes
- Кластер (Cluster) – несколько виртуальных или физических серверов провайдера объединенные в одну систему. Серверы, входящие в кластер, имеют внутренюю сеть с локальными ip-адресами, как будто они находятся в одном помещени и присоединены к одному роутеру.
- Ноды (Node) – это собственно серверы соединеные в кластер. Мастер-нода – это управляющая нода в кластере (с нее осуществляется управление кластером)
- Под (Pod) – один или несколько контейнеров, предаставляющие одно приложение. Например, для работы этого блога нужен cms wordpress, установленный в одном контейнере и база данных в другом контейнере. Но они вместе представляют единое приложение – wordpress. Поэтому соединены в одну логическую единицу – под. Выше на схеме поды обозначены кубиком в пятиугольнике.
- Контейнер (Container) – по сути, это docker-контейнер, виртуальная машина на которой установлена операционная система (обычно Linux) и набор необходимых программ.
Схема
Теперь, когда я рассказала почему я выбрал kuberntes и напомнил что это, давайте перейдем непосредственно к схеме. Тут я просто перечислю какие приложения (поды) выполняются, а детали про каждый из них обсудим в других постах:
Master-node (antivariantum.com)
Поды слева-направо:
- Snort – система безопасности (контроль внешних запросов)
- k6 – тестирование производительности
- influxdb – база данных для хранения хода тестирования
- Falco – система безопасности kubernetes
- Grafana – интерефес для построения метрик, полученных из разных источников (prometheus, loki, promtail, influxdb)
- Telegram-bot – система оповещения (не люблю slack). Отправляет оповещения из Falco, Jira, GitHub, Grafana и вообще чего угодно (это api который имеет эндпоинт, который можно вызвать из любого веб-хука).
- Landing (wordpress) – этот блог
- Mail Server – почтовый сервер
- Prometheus – собирает метрики (используемую нодами/подами память, процессорное время и много еще чего)
- Loki и Promtail – как prometheus, но собирает не метрики, а логи во времени. Интересный инструмент, можно сопоставить по времени когда происходил скачок загрузки процессора и посмотреть что было записано в логи в это время.
- Тестовый сервер старой школы мануального тестирования (база данных mySQL и web-интерфейс для него phpMyAdmin, база данных MongoDB и web-интерфейс MongoExpress, тестовый API и Swagger). Сейчас отключены, так как я не провожу курсы, но будут включены при необходимости (готов обсудить индивидуальные занятия, обращайтесь)
Продуктовая рабочая нода qacedu.com
- API – общий API проекта + Swagger
- Временный лендинг (реклама школы), онлайн, но запрещено сканирование поисковыми роботами и пока нигде не упоминается
- School – фронт школы
- CoreControl – фронт админки
- CRM – фронт CRM
- TechPulse – фронт TechPulse
- FlowForge – фронт системы согласования
Подробно о каждом поде в других постах.
Categories: