Развертывание экземпляра Harbor#

В этом документе описывается подписка на Harbor Operator и функциональность, основанная на развертывании экземпляра Harbor.

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

• Этот документ применим к версиям Harbor 2.12 и выше, предоставляемым платформой. Он отделён от платформы и основан на технологиях, таких как Operator.

• Убедитесь, что Harbor Operator был развернут (подписан) в целевом кластере, то есть Harbor Operator готов создавать экземпляры.

#Планирование развертывания

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

#Основная информация

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

2. Экземпляр Harbor содержит несколько компонентов, таких как Registry — компонент, отвечающий за управление файлами образов, PostgreSQL — компонент, предоставляющий хранилище для метаданных приложения и информации о пользователях, и Redis — компонент для кэширования и др. Платформа предоставляет профессиональные PostgreSQL Operator и Redis Operator, поэтому при развертывании экземпляров Harbor ресурсы Redis и PostgreSQL не разворачиваются напрямую, а подключаются через настройку соответствующих учётных данных доступа к существующим экземплярам.

#Планирование ресурсов перед развертыванием

Планирование ресурсов перед развертыванием — это решения, которые необходимо принять до развертывания и которые вступают в силу во время развертывания. Основные аспекты включают:

Высокая доступность

• Harbor поддерживает развертывание с высокой доступностью, с основными последствиями и ограничениями:

  • Каждый компонент будет использовать несколько реплик

  • Сетевой доступ больше не поддерживает NodePort, требуется доступ через доменные имена, настроенные через Ingress

  • Методы хранения больше не поддерживают node storage, требуется доступ через StorageClass или PVC

Ресурсы

Согласно рекомендациям сообщества, для работы экземпляра Harbor без высокой доступности требуется минимум 2 ядра CPU и 4Gi памяти, а в режиме высокой доступности — минимум 8 ядер CPU и 16Gi памяти для стабильной работы.

Хранилище

• Для Harbor можно использовать общие методы хранения, предоставляемые платформой, такие как классы хранилищ, persistent volume claims, node storage и др.

• Чтобы намеренно отказаться от сохранения данных для Trivy, оставьте spec.helmValues.persistence.persistentVolumeClaim.trivy.storageClass неустановленным. Тогда база данных уязвимостей будет храниться в emptyDir, и при каждом перезапуске пода Trivy будет заново загружать базу данных, блокируя сканирование до завершения загрузки.

• Node storage не подходит для режима высокой доступности, так как хранит файлы в указанном пути на узле хоста.

• Кроме того, Harbor поддерживает объектное хранилище. Инструкции по настройке см. в разделе Использование объектного хранилища в качестве бэкенда реестра.

Сеть

• Платформа предоставляет два основных метода сетевого доступа: NodePort и Ingress

  • NodePort требует указания HTTP и SSH портов и обеспечения их доступности. NodePort не подходит для режима высокой доступности

  • Ingress требует указания доменного имени и обеспечения корректного разрешения домена

• Платформа поддерживает протокол HTTPS, который необходимо настроить после развертывания экземпляра. Подробнее см. Настройка HTTPS.

Redis

• Текущая версия компонента Redis, от которой зависит Harbor, — v6. Рекомендуется использовать Redis Operator, предоставляемый платформой, для развертывания экземпляров Redis, а затем завершить интеграцию Redis, настроив учётные данные доступа.

  • Доступ к Redis осуществляется путём настройки ресурса secret с определённым форматом содержимого. Подробнее см. Настройка учётных данных доступа Redis, PostgreSQL и аккаунта.

• Известная проблема: Ошибка внутреннего сервера при изменении прав проекта Harbor

PostgreSQL

• Текущая версия компонента PostgreSQL, от которой зависит Harbor, — v14. Рекомендуется использовать PostgreSQL Operator, предоставляемый платформой, для развертывания экземпляров PostgreSQL, а затем завершить интеграцию PostgreSQL, настроив учётные данные доступа.

  • Доступ к PostgreSQL осуществляется путём настройки ресурса secret с определённым форматом содержимого. Подробнее см. Настройка учётных данных доступа Redis, PostgreSQL и аккаунта.

Учётные данные аккаунта

При инициализации экземпляра Harbor необходимо настроить учётную запись администратора и её пароль. Это делается путём настройки ресурса secret. Подробнее см. Настройка учётных данных доступа Redis, PostgreSQL и аккаунта.

#Планирование конфигурации после развертывания

Планирование конфигурации после развертывания — это планирование, не требующее решений до развертывания, но позволяющее изменять настройки по мере необходимости с помощью стандартизированных операций после развертывания. Это включает в себя единую аутентификацию (SSO), настройку HTTPS, конфигурацию внешнего балансировщика нагрузки и др. Подробнее см. Последующие операции.

#Развертывание экземпляра

Harbor Operator, предоставляемый платформой, предлагает два основных метода развертывания: развертывание из шаблонов и развертывание из YAML.

Платформа предоставляет два встроенных шаблона: шаблон Harbor Quick Start и шаблон Harbor High Availability, а также поддерживает пользовательские шаблоны для удовлетворения специфических сценариев клиентов.

Информация о встроенных шаблонах и развертывании из YAML приведена ниже:

#Развертывание из шаблона Harbor Quick Start

Этот шаблон предназначен для быстрого создания лёгкого экземпляра Harbor, подходящего для сценариев разработки и тестирования, не рекомендуется для продуктивных сред.

• Вычислительные ресурсы: 2 ядра CPU, 4Gi памяти
• Метод хранения: локальное node storage, требуется указать IP узла хранения и путь
• Сетевой доступ: метод NodePort, общий IP узла с хранилищем, требуется указать порты
• Зависимые сервисы: требуется настройка учётных данных доступа к существующим Redis и PostgreSQL
• Другие настройки: требуется настройка учётных данных аккаунта, функция SSO по умолчанию отключена

Завершите развертывание, заполнив соответствующую информацию согласно подсказкам шаблона.

#Развертывание из шаблона Harbor High Availability

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

• Вычислительные ресурсы: 16 ядер CPU, 16 Gi памяти
• Метод хранения: использование ресурсов класса хранения для хранения файлов образов, логов фоновых задач и базы данных уязвимостей сканирования образов
• Сетевой доступ: метод Ingress, требуется указать доменное имя
• Зависимые сервисы: требуется настройка учётных данных доступа к существующим Redis и PostgreSQL
• Другие настройки: требуется настройка учётных данных аккаунта, функция SSO по умолчанию отключена

Для обеспечения высокой доступности Harbor внешние зависимости должны соответствовать следующим условиям:

1. Экземпляры Redis и PostgreSQL должны быть высокодоступными
2. Балансировщик нагрузки в сети должен быть высокодоступным; при использовании ALB необходимо настроить VIP
3. В кластере должно быть более 2 узлов

Завершите развертывание, заполнив соответствующую информацию согласно подсказкам шаблона.

#Развертывание из шаблона Harbor Object Storage

Развёртывание экземпляра Harbor с использованием объектного хранилища.

• Вычислительные ресурсы: 8 ядер CPU, 16 Gi памяти
• Хранилище: файлы образов используют объектное хранилище, логи фоновых задач — базу данных
• Сетевой доступ: доступ через Ingress, указать доменное имя
• Зависимости: настройка учётных данных доступа к существующим Redis и PostgreSQL
• Другие настройки: настройка учётных данных аккаунта, функция SSO по умолчанию отключена

В этом шаблоне сканер Trivy не сохраняет данные; он монтирует emptyDir, поэтому при каждом перезапуске пода база данных уязвимостей загружается заново, и новые сканирования временно блокируются до завершения синхронизации.

Убедитесь, что предоставленные учётные данные объектного хранилища имеют необходимые разрешения API S3, см. Учётные данные объектного хранилища.

Завершите развертывание, заполнив соответствующую информацию согласно подсказкам шаблона.

#Развертывание из YAML

Развертывание из YAML — это самый базовый и мощный способ развертывания. Здесь приведены соответствующие YAML-фрагменты для каждого аспекта из раздела Планирование развертывания, а также два полных примера YAML для типовых сценариев, чтобы помочь пользователям понять метод конфигурации YAML и при необходимости внести изменения.

#Высокая доступность (фрагменты YAML)

В режиме высокой доступности количество реплик компонентов Harbor должно быть не менее 2. Фрагмент конфигурации YAML:

spec:
  helmValues:
    core:
      replicas: 2
    portal:
      replicas: 2
    jobservice:
      replicas: 2
    registry:
      replicas: 2

#Хранилище (фрагменты YAML)

Хранение данных Harbor включает три основные части:

• Registry: управление и хранение образов контейнеров и артефактов. Обеспечивает операции загрузки, скачивания и хранения образов.
• Jobservice: выполнение фоновых задач, таких как репликация образов между реестрами, сбор мусора и другие запланированные или по требованию задачи.
• Trivy: выполнение сканирования образов на уязвимости для выявления проблем безопасности и обеспечения соответствия политикам безопасности.

В настоящее время поддерживаются три метода конфигурации хранилища: класс хранилища, PVC и локальное node storage. При использовании класса хранилища или PVC хранилище должно поддерживать многозадачное чтение и запись (ReadWriteMany).

Для Registry также можно использовать объектное хранилище (S3) в качестве бэкенда.

Jobservice поддерживает хранение логов заданий в нескольких местах (файл, база данных, stdout). Если вы не выбрали вывод логов jobservice в файл, настройка хранилища для jobservice не требуется. Подробнее см. Настройка хранения логов заданий.

Фрагмент конфигурации класса хранилища:

spec:
  helmValues:
    persistence:
      enabled: true
      persistentVolumeClaim:
        registry:
          storageClass: ceph
          accessMode: ReadWriteMany
          size: 10Gi
        jobservice:
          jobLog:
            storageClass: ceph
            accessMode: ReadWriteMany
            size: 1Gi
        trivy:
          storageClass: ceph
          accessMode: ReadWriteMany
          size: 5Gi

Фрагмент конфигурации PVC (PVC должны быть созданы заранее):

spec:
  helmValues:
    harbor:
      persistence:
        enabled: true
        persistentVolumeClaim:
          registry:
            existingClaim: <PVC компонента registry>
          jobservice:
            jobLog:
              existingClaim: <PVC компонента jobservice>
          trivy:
            existingClaim: <PVC компонента trivy>

Фрагмент конфигурации локального node storage:

spec:
  helmValues:
    persistence:
      enabled: true
      hostPath:
        registry:
          path: <путь node storage компонента registry>
        jobservice:
          path: <путь node storage компонента jobservice>
        trivy:
          path: <путь node storage компонента trivy>
    registry:
      nodeSelector:
        kubernetes.io/hostname: <имя узла>
    jobservice:
      nodeSelector:
        kubernetes.io/hostname: <имя узла>
    trivy:
      nodeSelector:
        kubernetes.io/hostname: <имя узла>

Настройка объектного хранилища (S3) в качестве бэкенда хранения Registry:

• Используйте Amazon S3 или совместимые с S3 сервисы объектного хранения, такие как MinIO, Ceph.

• Корзина объектного хранилища должна быть создана заранее.

• Секрет <object-storage-secret> должен быть создан заранее.

  spec:
    helmValues:
      harbor:
        persistence:
          enabled: true
          imageChartStorage:
            disableredirect: true
            s3:
              existingSecret: <object-storage-secret>
              bucket: <bucket>
              region: <region>
              regionendpoint: <regionendpoint>
              v4auth: true
            type: s3
          persistentVolumeClaim:
            jobservice:
              jobLog:
                existingClaim: <PVC компонента jobservice>
            trivy:
              existingClaim: <PVC компонента trivy>

Подробнее см. Драйвер хранения S3

Если вы хотите использовать Ceph в платформе, обратитесь к Ceph Distributed Storage.

#Сетевой доступ (фрагменты YAML)

Сетевой доступ включает два основных метода: доступ по доменному имени и доступ через NodePort.

Фрагмент конфигурации доступа по доменному имени:

spec:
  helmValues:
    expose:
      type: ingress
      tls:
        enabled: false
      ingress:
        hosts:
          core: <доменное имя>

    externalURL: http://<доменное имя>

Фрагмент конфигурации доступа через NodePort:

spec:
  helmValues:
    expose:
      type: nodePort
      nodePort:
        name: harbor
        ports:
          http:
            port: 80
            nodePort: <номер порта>

    externalURL: http://<IP узла>:<номер порта>

#Конфигурация учётных данных доступа Redis

Это фрагмент конфигурации для учётных данных Redis в экземпляре Harbor после настройки ресурса secret с учётными данными Redis:

Пример для standalone:

spec:
  helmValues:
    database:
    redis:
      external:
        addr: "<адрес доступа redis>:<порт redis>"
        existingSecret: <секрет с паролем redis>
        existingSecretKey: password
      type: external

Пример для Sentinel:

spec:
  helmValues:
    database:
    redis:
      external:
        addr: "<адрес sentinel1>:<порт sentinel1>,<адрес sentinel2>:<порт sentinel2>,<адрес sentinel3>:<порт sentinel3>"
        sentinelMasterSet: mymaster
        existingSecret: <секрет с паролем redis>
        existingSecretKey: password
      type: external

#Конфигурация учётных данных доступа PostgreSQL

Это фрагмент конфигурации для учётных данных PostgreSQL в экземпляре Harbor после настройки ресурса secret с учётными данными PostgreSQL:

spec:
  helmValues:
    database:
      external:
        host: <адрес доступа postgresql>
        port: <порт postgresql>
        sslmode: <включён ли ssl>
        username: <имя пользователя postgresql>
        coreDatabase: <имя базы данных>
        existingSecret: <секрет с паролем postgresql>
      type: external

#Конфигурация учётных данных администратора

Это фрагмент конфигурации для учётных данных администратора в экземпляре Harbor после настройки ресурса secret с учётными данными аккаунта:

spec:
  helmValues:
    existingSecretAdminPassword: <секрет с паролем администратора harbor>
    existingSecretAdminPasswordKey: password

#Полный пример YAML: одиночный экземпляр, node storage, сетевой доступ NodePort

spec:
  helmValues:
    existingSecretAdminPassword: harbor-password # Секрет с паролем администратора harbor
    existingSecretAdminPasswordKey: password # Ключ секрета с паролем администратора harbor
    externalURL: http://192.168.142.11:32001 # Адрес доступа к Harbor
    expose:
      nodePort:
        name: harbor
        ports:
          http:
            nodePort: 32001 # Номер nodePort Harbor
            port: 80
      type: nodePort
    persistence:
      enabled: true
      hostPath:
        jobservice:
          path: /data/harbor/jobservice # Путь node storage компонента jobservice
        registry:
          path: /data/harbor/registry # Путь node storage компонента registry
        trivy:
          path: /data/harbor/trivy # Путь node storage компонента trivy
    portal:
      resources:
        request:
          cpu: 100m
          memory: 128Mi
        limit:
          cpu: 200m
          memory: 256Mi
    nginx:
      resources:
        request:
          cpu: 100m
          memory: 128Mi
        limit:
          cpu: 200m
          memory: 256Mi
    core:
      resources:
        request:
          cpu: 200m
          memory: 256Mi
        limit:
          cpu: 400m
          memory: 512Mi
    registry:
      nodeSelector:
        kubernetes.io/hostname: 192.168.142.11 # Node selector компонента registry
      resources:
        request:
          cpu: 200m
          memory: 512Mi
        limit:
          cpu: 400m
          memory: 1Gi
    jobservice:
      nodeSelector:
        kubernetes.io/hostname: 192.168.142.11 # Node selector компонента jobservice
      resources:
        request:
          cpu: 200m
          memory: 256Mi
        limit:
          cpu: 400m
          memory: 512Mi
    trivy:
      skipUpdate: true
      offlineScan: true
      nodeSelector:
        kubernetes.io/hostname: 192.168.142.11 # Node selector компонента trivy
      resources:
        request:
          cpu: 200m
          memory: 512Mi
        limit:
          cpu: 400m
          memory: 1Gi
    database:
      external:
        host: harbor-database # Адрес доступа к базе данных
        port: 5432 # Порт базы данных
        sslmode: require # Включён ли SSL
        username: harbor # Имя пользователя базы данных
        coreDatabase: registry # Имя базы данных
        existingSecret: harbor-database # Секрет с паролем базы данных
        existingSecretKey: password # Ключ секрета с паролем базы данных
      type: external
    redis:
      external:
        addr: harbor-redis:6379 # Адрес и порт доступа к Redis
        existingSecret: harbor-redis # Секрет с паролем Redis
        existingSecretKey: password # Ключ секрета с паролем Redis
      type: external

#Полный пример YAML: высокая доступность, StorageClass, сетевой доступ Ingress

spec:
  helmValues:
    existingSecretAdminPassword: harbor-password # Секрет с паролем администратора harbor
    existingSecretAdminPasswordKey: password # Ключ секрета с паролем администратора harbor
    externalURL: http://harbor.example.com # Адрес доступа к Harbor
    expose:
      type: ingress
      tls:
        enabled: false
      ingress:
        hosts:
          core: harbor.example.com # Доменное имя Harbor
    persistence:
      enabled: true
      persistentVolumeClaim:
        registry:
          storageClass: ceph # Класс хранения компонента registry
          accessMode: ReadWriteMany
          size: 10Gi # Размер хранилища компонента registry
        jobservice:
          jobLog:
            storageClass: ceph # Класс хранения компонента jobservice
            accessMode: ReadWriteMany
            size: 1Gi # Размер хранилища компонента jobservice
        trivy:
          storageClass: ceph # Класс хранения компонента trivy
          accessMode: ReadWriteMany
          size: 5Gi # Размер хранилища компонента trivy
    portal:
      replicas: 2 # Количество реплик компонента portal
      resources:
        request:
          cpu: 200m
          memory: 256Mi
        limit:
          cpu: 400m
          memory: 512Mi
    core:
      replicas: 2 # Количество реплик компонента core
      resources:
        request:
          cpu: 200m
          memory: 256Mi
        limit:
          cpu: 400m
          memory: 512Mi
    registry:
      replicas: 2 # Количество реплик компонента registry
      resources:
        request:
          cpu: 400m
          memory: 1Gi
        limit:
          cpu: 800m
          memory: 2Gi
    jobservice:
      replicas: 2 # Количество реплик компонента jobservice
      resources:
        request:
          cpu: 200m
          memory: 256Mi
        limit:
          cpu: 400m
          memory: 512Mi
    trivy:
      skipUpdate: true
      offlineScan: true
      resources:
        request:
          cpu: 400m
          memory: 1Gi
        limit:
          cpu: 800m
          memory: 2Gi
    database:
      external:
        host: harbor-database # Адрес доступа к базе данных
        port: 5432 # Порт базы данных
        sslmode: require # Включён ли SSL
        username: harbor # Имя пользователя базы данных
        coreDatabase: registry # Имя базы данных
        existingSecret: harbor-database # Секрет с паролем базы данных
        existingSecretKey: password # Ключ секрета с паролем базы данных
      type: external
    redis:
      external:
        addr: harbor-redis:6379 # Адрес и порт доступа к Redis
        existingSecret: harbor-redis # Секрет с паролем Redis
        existingSecretKey: password # Ключ секрета с паролем Redis
      type: external

#Последующие операции

#Настройка единой аутентификации (SSO)

Настройка SSO включает следующие шаги:

1. Зарегистрировать клиента аутентификации SSO в global cluster
2. Подготовить конфигурацию аутентификации SSO
3. Настроить экземпляр Harbor для использования аутентификации SSO

Создайте следующий ресурс OAuth2Client в global cluster для регистрации клиента аутентификации SSO:

apiVersion: dex.coreos.com/v1
kind: OAuth2Client
name: OIDC
metadata:
  name: nbqxeytpoiwwizlyzpzjzzeeeirsk # Это значение вычисляется на основе хэша поля id, онлайн-калькулятор: https://go.dev/play/p/QsoqUohsKok
  namespace: cpaas-system
alignPasswordDB: true
id: harbor-dex # Идентификатор клиента
public: false
redirectURIs:
  - <адрес доступа harbor>/c/oidc/callback
secret: Z2l0bGFiLW9mZmljaWFsLTAK # Секрет клиента
spec: {}

Отредактируйте экземпляр Harbor, добавив следующую конфигурацию:

spec:
  helmValues:
    oidc:
      enable: true
      clientID: "harbor-dex"
      clientSecret: "Z2l0bGFiLW9mZmljaWFsLTAK"
      issuer: "<адрес доступа платформы>/dex"

#Настройка HTTPS

После развертывания экземпляра Harbor HTTPS можно настроить по необходимости.

Сначала создайте секрет TLS-сертификата в пространстве имён, где расположен экземпляр:

apiVersion: v1
kind: Secret
metadata:
  name: harbor-tls-cert
  namespace: harbor
type: kubernetes.io/tls
data:
  tls.crt: <сертификат в base64>
  tls.key: <ключ в base64>

Затем отредактируйте YAML-конфигурацию экземпляра Harbor для включения HTTPS-доступа:

expose:
  type: ingress
  tls:
    enabled: true
    certSource: secret
    secret:
      secretName: harbor-tls-cert
  ingress:
    hosts:
      core: <доменное имя>

externalURL: https://<доменное имя>

#Настройка политики базы данных уязвимостей для сканирования образов

Функциональность сканирования образов Harbor реализована компонентом Trivy. Учитывая сетевую среду пользователя, политика базы данных уязвимостей по умолчанию для этого компонента — использование встроенной офлайн-базы уязвимостей. Поскольку база данных не обновляется, новые уязвимости не обнаруживаются своевременно.

Если вы хотите поддерживать базу данных уязвимостей в актуальном состоянии, отредактируйте YAML-конфигурацию экземпляра Harbor для включения политики онлайн-обновления (эта политика требует доступа к GitHub):

trivy:
  skipUpdate: false
  offlineScan: false

После включения политики онлайн-обновления Trivy будет определять необходимость обновления базы данных уязвимостей перед сканированием на основе времени последнего обновления. Поскольку загрузка базы данных занимает некоторое время, если вам не требуется сканирование уязвимостей Java, вы можете также отключить обновление базы данных уязвимостей Java, отредактировав YAML-конфигурацию экземпляра Harbor:

trivy:
  skipJavaDBUpdate: true

#Дополнительная информация

#Развёртывание Harbor в среде IPv6

Harbor поддерживает развертывание в среде IPv6, но необходимо убедиться, что версии ваших клиентских инструментов поддерживают IPv6. Если возникает ошибка invalid reference format, проверьте, поддерживает ли ваша версия клиента IPv6.

Связанные вопросы сообщества:

• https://github.com/distribution/distribution/pull/3489
• https://github.com/containers/buildah/discussions/4928