Привет, всем! В данной статье мы расскажем о Highly Available исполнении CI/CD платформы Gitorion. В данном случае платформа размещается в двух дата центрах. При отказе любого из дата центров команда разработчиков может продолжить непрерывную интеграцию и доставку в выжившем дата центре.
Абстрактная постановка задачи
Для CI/CD платформы Gitorion разработать вариант размещения в двух дата центрах - ведущем и ведомом. В штатном режиме модули разрабатываемого приложения и самой платформы (Forgejo, Jenkins, Harbor, Keycloak) размещаются в ведущем дата центре. При аварии ведущего дата центра все модули запускаются и продолжают работать в ведомом дата центре.
Схема Highly Available исполнения
На рисунке приведена общая схема. Платформа размещается в двух дата центрах - ведущем "Дата центр 1" и ведомом "Дата центр 2". Ниже под рисунком приведено краткое описание и назначение нод.
Ноды ведущего дата центра "Дата центр 1":
dc1-db - Master-нода базы данных платформы;
dc1-nas - Primary-нода сетевого файлового хранилища платформы;
dc1-plane - Control-plane нода кластера Kubernetes, на которой запущены модули плоскости управления Kubernetes;
dc1-worker - Worker-нода, на которой запущены модули самой платформы (Forgejo, Jenkins, Keycloak, Docker-registry) и модули разрабатываемого на платформе проекта.
Ноды ведомого дата центра "Дата центр 2":
dc2-db - Slave-нода базы данных платформы;
dc2-nas - Secondary-нода сетевого файлового хранилища платформы;
dc2-plane - Control-plane нода кластера Kubernetes, на которой запущены модули плоскости управления Kubernetes;
dc2-worker - Worker-нода, на которой запущен Ingress-nginx, реализующий дополнительную точку входа.
Highly Available кластер Kubernetes
Все компоненты платформы и проекта, разрабатываемого с помощью платформы, запускаются в Docker-контейнерах в кластере Kubernetes. Поэтому первым делом мы развернули Highly Available кластер Kubernetes. Решение, предложенное на официальном сайте Kubernetes, позволяет построить кластер высокой доступности только в 3х дата центрах. Кластер etcd падает, если большинство нод etcd недоступны, и невозможно провести кворум, и следом падает кластер Kubernetes. Мы нашли способ развернуть Highly Available кластер Kubernetes в 2х дата центрах, заменив штатную базу данных Kubernetes etcd на SQL-базу данных с помощью Kine от K3S. Чтобы не перегружать данный материал, все тонкости реализации мы вынесли в отдельную статью CI/CD Kubernetes платформа Gitorion. Highly Available кластер Kubernetes.
Реплицируемый NAS для HA кластера Kubernetes
Далее потребовалось спроектировать систему хранения файлов и директорий для модулей, запускаемых в Highly Available кластере Kubernetes. В каждом из дата центров мы выделили отдельный узел под сетевой NAS, к которому подключили необходимое количество жестких дисков. С помощью LVM cоздали Volume Group и требуемое количество LV разделов. Реплицировали с помощью DRBD разделы LV из ведущего дата центра в ведомый. В ведущем дата центре подключили модули Kubernetes к NAS с помощью PersistentVolume по сетевому протоколу NFS. NAS в ведомом дата центре на подхвате и содержит реплики LVM разделов. Тонкости реализации мы также вынесли в отдельную статью CI/CD Kubernetes платформа Gitorion. Реплицируемый NAS для Highly Available кластера Kubernetes.
База данных CI/CD платформы Gitorion
В платформе установлены несколько приложений, которым требуется база данных, - это Kine, Git-сервер Forgejo, приватный репозиторий Docker-образов Harbor и Keycloak. В ведущем дата центре мы выделили отдельный узел и установили на него PostgreSQL, в котором создали базы данных для перечисленных выше приложений. В ведомом дата центре так же на отдельном узле установили PostgreSQL и настроили логическую Master-Slave репликацию. В штатном режиме модули Kubernetes запущены в ведущем дата центре и подключаются к Master-реплике PostgreSQL. Slave-реплика PostgreSQL в ведомом дата центре на подхвате. Модули Kubernetes подключили к внешней базе данных при помощи сервисов Service без селекторов, в Endpoints-которых задали IP-адреc БД PostgreSQL. Для примера приведем спецификации Service и Endpoints для подключения модуля Forgejo.
apiVersion: v1
kind: Endpoints
metadata:
name: db
namespace: forgejo
subsets:
- addresses:
- ip: 3.3.3.3
ports:
- port: 5432
---
apiVersion: v1
kind: Service
metadata:
name: db
namespace: forgejo
spec:
ports:
- port: 5432Модуль Forgejo подключается к внешней базе данных PostgreSQL, используя имя сервиса db.forgejo.svc.cluster.local
Сценарий падения ведомого дата центра
В случае падения ведомого дата центра, компоненты платформы и разрабатываемого проекта продолжают работать в ведущем дата центре. Команда разработчиков продолжает непрерывную интеграцию и доставку в штатном режиме.
После восстановления упавшего дата центра нужно подключить Slave-реплику PostgresSQL к Master-реплике и восстановить логическую репликацию. Подключить Secondary DRBD ноду к Primary DRBD ноде и тоже настроить репликацию.
Сценарий падения ведущего дата центра
В случае падения ведущего дата центра, в ведомом дата центре следует выполнить следующие действия:
подключить Kine к PostgreSQL в ведомом дата центре и перезапустить модули плоскости управления Kubernetes на Plane-ноде dc2-plane;
перевести DRBD в Primary StandAlone режим и смонтировать разделы LVM для томов PersistentVolume. Перезапустить NFS-сервер;
в Endpoint-ах служб без селекторов заменить IP-адрес PostgreSQL ведущего дата центра на IP-адрес PostgreSQL в выжившем. Например для Forgejo:
apiVersion: v1
kind: Endpoints
metadata:
name: db
namespace: forgejo
subsets:
- addresses:
- ip: 4.4.4.4
ports:
- port: 5432в спецификациях Deployment и StatelulSet компонентов платформы в affinity привязать модули Kubernetes к worker-ноде ведомого дата центра;
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/hostname
operator: In
values:
- "dc2-worker"
удалить модули Kubernetes в упавшем дата центре, и плоскость управления Kubernetes автоматически запустит их на worker-ноде в выжившем дата центре.
В итоге Kubernetes запустит модули приложений на worker-ноде в выжившем дата центре, согласно affinity в спецификациях. Модули приложений подключатся к своим базам данных в PostgreSQL в ведомом дата центре. Также модули подключатся но NFS к NAS в ведомом дата центре. Разработчики смогут продолжить вносить правки в ПО и выполнять непрерывную доставку. Модули разрабатываемого приложения также продолжат работать в выжившем дата центре.
Восстановление упавшего дата центра
Далее следует восстановить узлы в упавшем дата центре или заново развернуть в другом дата центре и подключить к выжившему дата центру, как показано на картинке ниже.
Базу данных PostgreSQL в поднятом дата центре следует подключить как Slave-реплику к Master-реплике в выжившем дата центе и настроить логическую репликацию. DRBD ноду в поднятом дата центре следует подключить как Secondary реплику к Primary DRBD реплике в выжившем дата центре и реплицировать LVM разделы. Теперь восстановленный дата центр будет на подхвате, на случай падения ведущего дата центра.
Заключение
На этом мы завершаем наш мини-цикл статей про высокую доступность CI/DC платформы Gitorion. Будем рады конструктивной критике и замечаниям. Спасибо за внимание!
