CI/CD Kubernetes платформа Gitorion. Highly Available исполнение

Привет, всем! В данной статье мы расскажем о 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. Будем рады конструктивной критике и замечаниям. Спасибо за внимание!