Настройка объектного хранилища с помощью Milvus Operator

Milvus использует MinIO или S3 в качестве объектного хранилища для хранения крупных файлов, таких как индексные файлы и двоичные журналы. В этой теме рассказывается о том, как настроить зависимости объектного хранилища при установке Milvus с Milvus Operator. Дополнительные сведения см. в разделе Настройка объектного хранилища с Milvus Operator в репозитории Milvus Operator.

В этой теме предполагается, что вы развернули Milvus Operator.

Вам нужно указать файл конфигурации для использования Milvus Operator для запуска кластера Milvus.

kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_default.yaml

Для настройки сторонних зависимостей достаточно отредактировать шаблон кода в milvus_cluster_default.yaml. В следующих разделах описывается настройка объектного хранилища, etcd и Pulsar соответственно.

Настройка хранилища объектов

Кластер Milvus использует MinIO или S3 в качестве объектного хранилища для хранения больших файлов, таких как индексные файлы и двоичные журналы. Добавьте необходимые поля в поле spec.dependencies.storage для настройки объектного хранилища, возможные варианты: external и inCluster.

Внутреннее хранилище объектов

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

apiVersion: milvus.io/v1beta1
kind: Milvus
metadata:
  name: my-release
  labels:
    app: milvus
spec:
  # Omit other fields ...
  dependencies:
    # Omit other fields ...
    storage:
      inCluster:
        values:
          mode: standalone
          resources:
            requests:
              memory: 100Mi
        deletionPolicy: Delete # Delete | Retain, default: Retain
        pvcDeletion: true # default: false

После применения вышеуказанной конфигурации внутрикластерное MinIO будет работать в автономном режиме с ограничением памяти до 100Mi. Обратите внимание, что

• Поле deletionPolicy определяет политику удаления для in-cluster MinIO. По умолчанию оно принимает значение Delete, а в качестве альтернативного варианта может использоваться Retain.

  • Delete указывает, что внутрикластерное хранилище объектов удаляется при остановке экземпляра Milvus.
  • Retain указывает, что внутрикластерное хранилище объектов сохраняется в качестве службы зависимостей для последующих запусков экземпляра Milvus.

• Поле pvcDeletion указывает, удалять ли PVC (Persistent Volume Claim) при удалении внутрикластерного MinIO.

Поля в разделе inCluster.values такие же, как в Milvus Helm Chart, и вы можете найти их здесь.

Внешнее хранилище объектов

Использование external в файле YAML шаблона указывает на использование внешней службы хранения объектов. Чтобы использовать внешнее хранилище объектов, необходимо правильно задать поля spec.dependencies.storage и spec.config.minio в Milvus CRD.

Использование Amazon Web Service (AWS) S3 в качестве внешнего хранилища объектов

• Настройте доступ к AWS S3 по AK/SK

  Доступ к ведру S3 обычно осуществляется с помощью пары ключей доступа и секретного ключа доступа. Вы можете создать объект Secret для их хранения в Kubernetes следующим образом:

  # # change the <parameters> to match your environment
  apiVersion: v1
  kind: Secret
  metadata:
    name: my-release-s3-secret
  type: Opaque
  stringData:
    accesskey: <my-access-key>
    secretkey: <my-secret-key>
  

  Затем можно настроить ведро AWS S3 в качестве внешнего хранилища объектов:

  # # change the <parameters> to match your environment
  apiVersion: milvus.io/v1beta1
  kind: Milvus
  metadata:
    name: my-release
    labels:
      app: milvus
  spec:
    # Omit other fields ...
    config:
      minio:
        # your bucket name
        bucketName: <my-bucket>
        # Optional, config the prefix of the bucket milvus will use
        rootPath: milvus/my-release
        useSSL: true
    dependencies:
      storage:
        # enable external object storage
        external: true
        type: S3 # MinIO | S3
        # the endpoint of AWS S3
        endpoint: s3.amazonaws.com:443
        # the secret storing the access key and secret key
        secretRef: "my-release-s3-secret"
  

• Configure AWS S3 Access by AssumeRole

  В качестве альтернативы, вы можете заставить Milvus получить доступ к вашему ведру AWS S3, используя AssumeRole, так что будут задействованы только временные учетные данные, а не ваш реальный AK/SK.

  Если вы предпочитаете именно этот вариант, вам нужно подготовить роль в консоли AWS и получить ее ARN, который обычно имеет вид arn:aws:iam::<your account id>:role/<role-name>.

  Затем создайте объект ServiceAccount для его хранения в Kubernetes следующим образом:

  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: my-release-sa
    annotations:
      eks.amazonaws.com/role-arn: <my-role-arn>
  

  Когда все готово, ссылайтесь на вышеупомянутый ServiceAccount в YAML-файле шаблона и установите spec.config.minio.useIAM на true, чтобы включить AssumeRole.

  apiVersion: milvus.io/v1beta1
  kind: Milvus
  metadata:
    name: my-release
    labels:
      app: milvus
  spec:
    # Omit other fields ...
    components:
      # use the above ServiceAccount
      serviceAccountName: my-release-sa
    config:
      minio:
        # enable AssumeRole
        useIAM: true
        # Omit other fields ...
    dependencies:
      storage:
        # Omit other fields ...
        # Note: you must use regional endpoint here, otherwise the minio client that milvus uses will fail to connect
        endpoint: s3.<my-bucket-region>.amazonaws.com:443
        secretRef: "" # we don't need to specify the secret here
  

Использование облачного хранилища Google (GCS) в качестве внешнего хранилища объектов

Объектное хранилище AWS S3 - не единственный выбор. Вы также можете использовать службу хранения объектов других провайдеров публичных облаков, например Google Cloud.

• Настройка доступа к GCS с помощью AK/SK

  Конфигурация в основном аналогична настройке при использовании AWS S3. Вам по-прежнему нужно создать объект Secret для хранения учетных данных в Kubernetes.

  # # change the <parameters> to match your environment
  apiVersion: v1
  kind: Secret
  metadata:
    name: my-release-gcp-secret
  type: Opaque
  stringData:
    accesskey: <my-access-key>
    secretkey: <my-secret-key>
  

  Затем нужно только изменить endpoint на storage.googleapis.com:443 и установить spec.config.minio.cloudProvider на gcp, как показано ниже:

  # # change the <parameters> to match your environment
  apiVersion: milvus.io/v1beta1
  kind: Milvus
  metadata:
    name: my-release
    labels:
      app: milvus
  spec:
    # Omit other fields ...
    config:
      minio:
        cloudProvider: gcp
    dependencies:
      storage:
        # Omit other fields ...
        endpoint: storage.googleapis.com:443
  

• Настройка доступа к GCS по AssumeRole

  Аналогично AWS S3, вы также можете использовать Workload Identity для доступа к GCS с временными учетными данными, если вы используете GKE в качестве кластера Kubernetes.

  Аннотация ServiceAccount отличается от аннотации AWS EKS. Вам нужно указать имя учетной записи службы GCP вместо ARN роли.

  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: my-release-sa
    annotations:
      iam.gke.io/gcp-service-account: <my-gcp-service-account-name>
  

  Затем вы можете настроить свой экземпляр Milvus на использование вышеуказанного ServiceAccount и включить AssumeRole, установив spec.config.minio.useIAM на true, как показано ниже:

  labels:
      app: milvus
  spec:
    # Omit other fields ...
    components:
      # use the above ServiceAccount
      serviceAccountName: my-release-sa
    config:
      minio:
        cloudProvider: gcp
        # enable AssumeRole
        useIAM: true
        # Omit other fields ...  
  

Что дальше

Узнайте, как настроить другие зависимости Milvus с помощью Milvus Operator:

• Настройка хранилища метаданных с помощью Milvus Operator
• Настройте хранилище сообщений с помощью Milvus Operator