#Синхронизация образов Harbor с реестром кластера

В этом руководстве объясняется, как настроить правила репликации в Harbor для автоматической синхронизации образов из Harbor в реестры в кластерах при загрузке новых образов.

#Предварительные требования

• Рабочий сервис Harbor
• Клиент podman или другие инструменты управления образами, установленные локально для загрузки образов в Harbor
• Kubernetes-кластер с развернутым реестром
• Установленный и настроенный локально kubectl для доступа к Kubernetes-кластеру

#Обзор

Основные настройки в Harbor

• Registry Endpoint: Добавление информации о целевом реестре в Harbor
• Replication Rule: Определение, какие образы синхронизировать и путь синхронизации

Обзор процесса

#Шаги настройки

#Шаг 1: Настройка Registry Endpoint в Harbor

Сначала настройте информацию о целевом реестре в Harbor с помощью функции Registry Endpoint.

1. Войдите в Harbor и перейдите в Administration > Registries
2. Нажмите NEW ENDPOINT и заполните следующие поля:

• Provider: Выберите тип вашего реестра. В этом примере выберите Harbor
• Name: Укажите описательное имя для целевого реестра. Рекомендуется использовать формат <cluster-name>-registry для удобства идентификации
• Endpoint URL: Введите URL вашего реестра (например, https://cluster1-registry.example.com)
• Access ID: Имя пользователя с правами Push/Delete для целевого реестра
• Access Secret: Пароль для указанного пользователя
• Verify Remote Cert: Определяет, нужно ли проверять сертификат удаленного реестра. Снимите галочку для самоподписанных или недоверенных сертификатов

3. Нажмите TEST CONNECTION для проверки конфигурации и сетевого соединения
4. Нажмите OK для сохранения настроек

#Шаг 2: Настройка Replication Rule в Harbor

Далее настройте правило репликации, чтобы определить, как Harbor будет синхронизировать образы с целевым реестром.

1. Перейдите в Administration > Replications
2. Нажмите NEW REPLICATION RULE и заполните:

Основные настройки

• Name: Используйте описательное имя, например <cluster-name>-registry-replication
• Replication mode: Выберите Push-based для запуска синхронизации при загрузке образов в Harbor

Фильтр исходных ресурсов

Настройте фильтры для выбора артефактов для репликации:

• Name: Фильтр по имени ресурса. Оставьте пустым или используйте ** для выбора всех. В этом примере оставьте пустым для синхронизации всех репозиториев
• Tag: Фильтр по тегу/версии. Оставьте пустым или используйте ** для выбора всех тегов. В этом примере оставьте пустым для синхронизации всех тегов
• Label: Фильтр по меткам артефактов. Оставьте пустым для выбора всех артефактов. В этом примере оставьте пустым для синхронизации всех артефактов
• Resource: Фильтр по типу ресурсов. В этом примере выберите ALL для синхронизации всех типов артефактов

Назначение

Определите цель синхронизации и структуру пути:

• Destination registry: Выберите конечную точку реестра, настроенную на шаге 1
• Namespace: Имя пространства имён, в которое будут реплицированы ресурсы. Если пусто, ресурсы будут размещены в том же пространстве имён, что и источник. В этом примере оставьте пустым для использования того же пространства имён
• Flattening: Сокращение вложенной структуры репозиториев при копировании образов. Оставьте пустым для сохранения исходной иерархии образов

Дополнительные настройки

• Trigger Mode: Выберите способ запуска синхронизации. Для этого примера выберите Event Based для запуска синхронизации при событиях загрузки в Harbor
• Отметьте "Delete remote resources when locally deleted", если хотите, чтобы удаление в Harbor распространялось на целевой реестр
• Bandwidth: Установите максимальную пропускную способность сети на одного рабочего репликации (используйте -1 для неограниченной)
• Options:
• Отметьте Override для перезаписи существующих ресурсов на целевом реестре
• Отметьте Enable rule для активации правила репликации

#Шаг 3: Проверка синхронизации образов

Загрузка образа в Harbor

Загрузите образ в Harbor для запуска синхронизации:

podman pull alpine:latest
podman tag alpine:latest <your-harbor-address>/library/alpine:latest
podman push <your-harbor-address>/library/alpine:latest

Мониторинг задания синхронизации в Harbor

1. В Harbor перейдите в Administration > Replications
2. Выберите созданное правило репликации, чтобы увидеть автоматически запущенную задачу синхронизации
3. Нажмите на запись выполнения для просмотра подробной информации

Проверка результатов синхронизации

Создайте pod в целевом кластере, чтобы проверить успешность синхронизации образа:

kubectl run alpine-test --image=<your-cluster-registry-address>/library/alpine:latest -- sleep 3600

Если pod успешно запускается, синхронизация работает корректно.

#Итог

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

#FAQ

#Можно ли использовать функцию репликации для аварийного восстановления Harbor?

Функция репликации Harbor может обеспечить лишь предварительное решение для аварийного восстановления (DR) и имеет определённые ограничения.

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

Ниже приведён анализ проблем, которые решает данное решение, и тех, которые остаются нерешёнными.

#Решаемые проблемы

• Автоматическая синхронизация данных образов: Образы контейнеров и Helm-чарты с основного экземпляра могут автоматически синхронизироваться на вторичный. При включённой опции "синхронизация удалений" образы, удалённые с основного экземпляра, автоматически удаляются и со вторичного.
• Автоматическое переключение (failover): В случае сбоя основного экземпляра внешнее разрешение доменного имени может автоматически переключиться на вторичный, позволяя пользователям загружать уже синхронизированные образы (время восстановления, RTO, зависит в основном от реализованного механизма переключения).

#Нерешаемые проблемы

1. Автоматическая синхронизация необразных данных (критично!):

• Описание проблемы: Функция репликации Harbor не синхронизирует метаданные, такие как учётные записи пользователей, настройки разрешений (например, OIDC), группы участников проектов или журналы аудита.
• Влияние: Пользователи, чьи метаданные не синхронизированы, не смогут получить доступ к Harbor после переключения, что существенно снижает эффективность аварийного восстановления.

2. Recovery Point Objective (RPO):

• Описание проблемы: Функция репликации не предназначена специально для аварийного восстановления. Репликация образов зависит от выполнения фоновых задач, которые не гарантируют, что все образы основного реестра будут синхронизированы на вторичный в момент сбоя.
• Влияние: При сбое основного реестра пользователи не смогут загрузить образы, которые ещё не были синхронизированы.

3. Возврат к основному экземпляру:

• Описание проблемы: Текущее решение поддерживает только автоматическое переключение на вторичный экземпляр. Возврат к основному требует ручного вмешательства.
• Влияние: Перед возвратом необходимо синхронизировать инкрементальные данные со вторичного экземпляра обратно на основной, иначе эти данные будут потеряны.

#Рекомендации для комплексного решения DR

Для создания надёжного механизма аварийного восстановления следует сосредоточиться на синхронизации на уровне базы данных PostgreSQL (PG) и хранилища. Например, реализовать репликацию базы данных PostgreSQL в реальном времени и включить синхронизацию на уровне хранилища (например, кросс-региональную репликацию S3) для обеспечения полной согласованности как метаданных, так и всех данных.

#Ссылки

• Harbor Replication