milvus-logo
LFAI
Home
  • Guía de administración
    • Gestión de dependencias

Configurar el almacenamiento de objetos con Milvus Operator

Milvus utiliza MinIO o S3 como almacenamiento de objetos para persistir archivos a gran escala, como archivos de índice y registros binarios. Este tema presenta cómo configurar las dependencias de almacenamiento de objetos cuando instala Milvus con Milvus Operator. Para más detalles, consulte Configurar el almacenamiento de objetos con Milvus Oper ator en el repositorio de Milvus Operator.

Este tema asume que usted ha desplegado Milvus Operator.

Consulte Despliegue de Milvus Operator para obtener más información.

Necesita especificar un archivo de configuración para utilizar Milvus Operator para iniciar un cluster Milvus.

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

Sólo necesita editar la plantilla de código en milvus_cluster_default.yaml para configurar las dependencias de terceros. Las siguientes secciones presentan cómo configurar el almacenamiento de objetos, etcd y Pulsar respectivamente.

Configurar el almacenamiento de objetos

Un cluster Milvus utiliza MinIO o S3 como almacenamiento de objetos para persistir archivos a gran escala, como archivos de índice y registros binarios. Añada los campos requeridos en spec.dependencies.storage para configurar el almacenamiento de objetos, las opciones posibles son external y inCluster.

Almacenamiento de objetos interno

Por defecto, Milvus Operator despliega un MinIO en el cluster para Milvus. El siguiente es un ejemplo de configuración para demostrar cómo utilizar este MinIO como almacenamiento interno de objetos.

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

Después de aplicar la configuración anterior, el MinIO in-cluster se ejecutará en modo autónomo con un límite de memoria de hasta 100Mi. Tenga en cuenta que

  • El campo deletionPolicy especifica la política de borrado del MinIO in-cluster. Por defecto es Delete y tiene Retain como opción alternativa.

    • Delete indica que el almacenamiento de objetos en el clúster se elimina cuando detiene su instancia de Milvus.
    • Retain indica que el almacenamiento de objetos en el clúster se conserva como servicio de dependencia para posteriores arranques de su instancia de Milvus.
  • El campo pvcDeletion especifica si se elimina el PVC (Persistent Volume Claim) cuando se elimina el MinIO in-cluster.

Los campos bajo inCluster.values son los mismos que los de Milvus Helm Chart, y puede encontrarlos aquí.

Almacenamiento externo de objetos

El uso de external en el archivo YAML de plantilla indica el uso de un servicio de almacenamiento de objetos externo. Para utilizar un almacenamiento de objetos externo, debe configurar correctamente los campos en spec.dependencies.storage y spec.config.minio en el CRD de Milvus.

Utilice Amazon Web Service (AWS) S3 como almacenamiento externo de objetos

  • Configurar el acceso a AWS S3 por AK/SK

    Normalmente se puede acceder a un cubo S3 mediante un par de una clave de acceso y una clave secreta de acceso. Puede crear un objeto Secret para almacenarlos en su Kubernetes de la siguiente manera:

    # # 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>
    

    A continuación, puede configurar un bucket de AWS S3 como almacenamiento de objetos externo:

    # # 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"
    
  • Configurar el acceso a AWS S3 por AssumeRole.

    Alternativamente, puede hacer que Milvus acceda a su cubo de AWS S3 utilizando AssumeRole, de modo que solo intervengan credenciales temporales en lugar de su AK/SK real.

    Si esto es lo que prefiere, necesita preparar un rol en su consola AWS y obtener su ARN, que usualmente está en la forma de arn:aws:iam::<your account id>:role/<role-name>.

    A continuación, cree un objeto ServiceAccount para almacenarlo en su Kubernetes como se indica a continuación:

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

    Una vez todo listo, haz referencia al anterior ServiceAccount en el archivo YAML de la plantilla, y establece spec.config.minio.useIAM en true para habilitar 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
    

Utilizar Google Cloud Storage (GCS) como almacenamiento de objetos externo

El almacenamiento de objetos AWS S3 no es la única opción. También puede utilizar el servicio de almacenamiento de objetos de otros proveedores de nubes públicas, como Google Cloud.

  • Configurar el acceso a GCS por AK/SK

    La configuración es en su mayor parte similar a la del uso de AWS S3. Todavía necesitas crear un objeto Secret para almacenar tus credenciales en tu 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>
    

    A continuación, solo tiene que cambiar endpoint por storage.googleapis.com:443 y configurar spec.config.minio.cloudProvider por gcp como se indica a continuación:

    # # 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
    
  • Configurar el acceso a GCS mediante AssumeRole

    De forma similar a AWS S3, también puede utilizar Workload Identity para acceder a GCS con credenciales temporales si está utilizando GKE como su clúster Kubernetes.

    La anotación de ServiceAccount es diferente a la de AWS EKS. Debe especificar el nombre de la cuenta de servicio de GCP en lugar del ARN del rol.

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

    A continuación, puede configurar su instancia Milvus para utilizar el anterior ServiceAccount y habilitar AssumeRole estableciendo spec.config.minio.useIAM en true como se indica a continuación:

    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 ...  
    

A continuación

Aprenda a configurar otras dependencias de Milvus con Milvus Operator:

Traducido porDeepL

Try Managed Milvus for Free

Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

Get Started
Feedback

¿Fue útil esta página?