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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ресурсы

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

Хранилище

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

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

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

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

Сеть

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

  • NodePort требует указания HTTP-порта и SSH-порта, а также проверки доступности этих портов. NodePort не подходит для режима high availability

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

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

Redis

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

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

• Известная проблема: Изменение прав доступа к проекту Harbor вызывает Internal Server Error

PostgreSQL

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

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

Учётные данные учётной записи

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вычислительные ресурсы: CPU 16 ядер, память 16 Gi
• Способ хранения: используются ресурсы storage class для хранения файлов образов, журналов фоновых задач и базы уязвимостей для сканирования образов
• Сетевой доступ: используется способ 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, поэтому при каждом перезапуске pod база уязвимостей загружается заново, а новые сканирования временно блокируются до завершения синхронизации.

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

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

#Развертывание из 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: выполняет сканирование контейнерных образов на уязвимости для выявления проблем безопасности и обеспечения соответствия политике безопасности.

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

Для Registry также можно использовать Object Storage (S3) в качестве backend-хранилища.

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

Фрагмент настройки storage class:

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: <registry component pvc>
          jobservice:
            jobLog:
              existingClaim: <jobservice component pvc>
          trivy:
            existingClaim: <trivy component pvc>

Фрагмент настройки локального хранилища узла:

spec:
  helmValues:
    persistence:
      enabled: true
      hostPath:
        registry:
          path: <registry component node storage path>
        jobservice:
          path: <jobservice component node storage path>
        trivy:
          path: <trivy component node storage path>
    registry:
      nodeSelector:
        kubernetes.io/hostname: <node name>
    jobservice:
      nodeSelector:
        kubernetes.io/hostname: <node name>
    trivy:
      nodeSelector:
        kubernetes.io/hostname: <node name>

Настройка Object Storage (S3) в качестве backend-хранилища Registry:

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

• Корзина (bucket) Object Storage должна быть создана заранее.

• Secret <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: <jobservice component pvc>
            trivy:
              existingClaim: <trivy component pvc>

Дополнительные сведения см. в S3 storage driver

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

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

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

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

spec:
  helmValues:
    expose:
      type: ingress
      tls:
        enabled: false
      ingress:
        hosts:
          core: <domain name>

    externalURL: http://<domain name>

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

spec:
  helmValues:
    expose:
      type: nodePort
      nodePort:
        name: harbor
        ports:
          http:
            port: 80
            nodePort: <port number>

    externalURL: http://<node IP>:<port number>

#Настройка учётных данных доступа Redis

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

Пример для standalone:

spec:
  helmValues:
    database:
    redis:
      external:
        addr: "<redis access address>:<redis port>"
        existingSecret: <secret storing redis password>
        existingSecretKey: password
      type: external

Пример для Sentinel:

spec:
  helmValues:
    database:
    redis:
      external:
        addr: "<sentinel1 access address>:<sentinel1 port>,<sentinel2 access address>:<sentinel2 port>,<sentinel3 access address>:<sentinel3 port>"
        sentinelMasterSet: mymaster
        existingSecret: <secret storing redis password>
        existingSecretKey: password
      type: external

#Пример Redis с TLS

apiVersion: v1
kind: Secret
metadata:
  name: redis-ca-bundle
type: Opaque
stringData:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    <redis server root ca>
    -----END CERTIFICATE-----
---
spec:
  helmValues:
    caBundleSecretName: redis-ca-bundle
    redis:
      external:
        addr: "<redis access address>:<redis tls port>"
        existingSecret: <secret storing redis password>
        existingSecretKey: password
        tlsOptions:
          enable: true
      type: external

Примечания для Redis с TLS:

• caBundleSecretName — это глобальное значение Harbor Helm. Указанный Secret должен содержать ключ с именем ca.crt.
• Для Redis Sentinel с включённым TLS по-прежнему используйте адреса Sentinel в redis.external.addr, задайте redis.external.sentinelMasterSet и включите redis.external.tlsOptions.enable: true.
• Harbor поддерживает только проверку серверного сертификата для Redis TLS. Клиентские сертификаты не поддерживаются.
• Подключение Harbor к Alauda Cache Service for Redis OSS по TLS в настоящее время не поддерживается.

#Настройка учётных данных доступа PostgreSQL

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

spec:
  helmValues:
    database:
      external:
        host: <postgresql access address>
        port: <postgresql port>
        sslmode: <whether to enable ssl>
        username: <postgresql username>
        coreDatabase: <database name>
        existingSecret: <secret storing postgresql password>
      type: external

#Настройка учётной записи администратора

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

spec:
  helmValues:
    existingSecretAdminPassword: <secret storing harbor admin password>
    existingSecretAdminPasswordKey: password

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

spec:
  helmValues:
    existingSecretAdminPassword: harbor-password # Secret, содержащий пароль учётной записи администратора Harbor
    existingSecretAdminPasswordKey: password # Ключ Secret, содержащий пароль учётной записи администратора Harbor
    externalURL: http://192.168.142.11:32001 # Адрес доступа к Harbor
    expose:
      nodePort:
        name: harbor
        ports:
          http:
            nodePort: 32001 # Номер node port Harbor
            port: 80
      type: nodePort
    persistence:
      enabled: true
      hostPath:
        jobservice:
          path: /data/harbor/jobservice # Путь к локальному хранилищу узла для компонента Jobservice
        registry:
          path: /data/harbor/registry # Путь к локальному хранилищу узла для компонента Registry
        trivy:
          path: /data/harbor/trivy # Путь к локальному хранилищу узла для компонента 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 # Узловой селектор компонента Registry
      resources:
        request:
          cpu: 200m
          memory: 512Mi
        limit:
          cpu: 400m
          memory: 1Gi
    jobservice:
      nodeSelector:
        kubernetes.io/hostname: 192.168.142.11 # Узловой селектор компонента 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 # Узловой селектор компонента 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 # Secret, содержащий пароль базы данных
        existingSecretKey: password # Ключ Secret, содержащий пароль базы данных
      type: external
    redis:
      external:
        addr: harbor-redis:6379 # Адрес и номер порта Redis
        existingSecret: harbor-redis # Secret, содержащий пароль Redis
        existingSecretKey: password # Ключ Secret, содержащий пароль Redis
      type: external

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

spec:
  helmValues:
    existingSecretAdminPassword: harbor-password # Secret, содержащий пароль учётной записи администратора Harbor
    existingSecretAdminPasswordKey: password # Ключ Secret, содержащий пароль учётной записи администратора 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 # Storage class компонента Registry
          accessMode: ReadWriteMany
          size: 10Gi # Размер хранилища компонента Registry
        jobservice:
          jobLog:
            storageClass: ceph # Storage class компонента Jobservice
            accessMode: ReadWriteMany
            size: 1Gi # Размер хранилища компонента Jobservice
        trivy:
          storageClass: ceph # Storage class компонента 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 # Secret, содержащий пароль базы данных
        existingSecretKey: password # Ключ Secret, содержащий пароль базы данных
      type: external
    redis:
      external:
        addr: harbor-redis:6379 # Адрес и номер порта Redis
        existingSecret: harbor-redis # Secret, содержащий пароль Redis
        existingSecretKey: password # Ключ Secret, содержащий пароль Redis
      type: external

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

#Настройка Single Sign-On (SSO)

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

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

Создайте следующий ресурс OAuth2Client в глобальном кластере, чтобы зарегистрировать клиент аутентификации 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 access address>/c/oidc/callback
secret: Z2l0bGFiLW9mZmljaWFsLTAK # Секрет клиента
spec: {}

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

spec:
  helmValues:
    oidc:
      enable: true
      clientID: "harbor-dex"
      clientSecret: "Z2l0bGFiLW9mZmljaWFsLTAK"
      issuer: "<platform access address>/dex"

#Настройка HTTPS

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

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

apiVersion: v1
kind: Secret
metadata:
  name: harbor-tls-cert
  namespace: harbor
type: kubernetes.io/tls
data:
  tls.crt: <base64 encoded cert>
  tls.key: <base64 encoded key>

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

expose:
  type: ingress
  tls:
    enabled: true
    certSource: secret
    secret:
      secretName: harbor-tls-cert
  ingress:
    hosts:
      core: <domain name>

externalURL: https://<domain name>

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

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

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

trivy:
  skipUpdate: false
  offlineScan: false

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

trivy:
  skipJavaDBUpdate: true

Если вы оставляете включённым рабочий процесс офлайн-базы и init container init-offline-db завершает работу с OOM при распаковке базы данных, можно увеличить ресурсы только для инициализации отдельно от основных ресурсов выполнения Trivy:

trivy:
  offlineScan: true
  offlineDBInitResources:
    requests:
      cpu: 200m
      memory: 512Mi
    limits:
      cpu: 1
      memory: 2Gi

Эта настройка влияет только на init container во время инициализации Pod и не увеличивает постоянные лимиты ресурсов основного контейнера Trivy.

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

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

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

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

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