milvus-logo
LFAI
Casa
  • Guida all'amministrazione
    • Gestire le dipendenze

Configurazione dell'archiviazione a oggetti con Milvus Operator

Milvus utilizza MinIO o S3 come storage di oggetti per conservare file di grandi dimensioni, come i file di indice e i log binari. Questo argomento spiega come configurare le dipendenze dello storage a oggetti quando si installa Milvus con Milvus Operator. Per maggiori dettagli, consultate Configurazione dello storage a oggetti con Milvus Operator nel repository di Milvus Operator.

Questo argomento presuppone che abbiate installato Milvus Operator.

Per ulteriori informazioni, vedere Distribuzione di Milvus Operator.

È necessario specificare un file di configurazione per utilizzare Milvus Operator per avviare un cluster Milvus.

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

È sufficiente modificare il modello di codice in milvus_cluster_default.yaml per configurare le dipendenze di terzi. Le sezioni seguenti illustrano come configurare rispettivamente object storage, etcd e Pulsar.

Configurare l'archiviazione degli oggetti

Un cluster Milvus utilizza MinIO o S3 come archiviazione a oggetti per conservare file di grandi dimensioni, come i file di indice e i log binari. Aggiungere i campi richiesti sotto spec.dependencies.storage per configurare l'archiviazione a oggetti; le opzioni possibili sono external e inCluster.

Archiviazione interna degli oggetti

Per impostazione predefinita, Milvus Operator distribuisce un MinIO interno al cluster per Milvus. Di seguito è riportato un esempio di configurazione per dimostrare come utilizzare questo MinIO come archivio oggetti interno.

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

Dopo aver applicato la configurazione di cui sopra, il MinIO in-cluster funzionerà in modalità standalone con un limite di memoria di 100Mi. Si noti che

  • Il campo deletionPolicy specifica la politica di cancellazione del MinIO in-cluster. È predefinito su Delete e ha Retain come opzione alternativa.

    • Delete indica che il deposito di oggetti nel cluster viene cancellato quando si arresta l'istanza Milvus.
    • Retain indica che il deposito di oggetti nel cluster viene mantenuto come servizio di dipendenza per gli avvii successivi dell'istanza Milvus.
  • Il campo pvcDeletion specifica se cancellare il PVC (Persistent Volume Claim) quando il MinIO in-cluster viene cancellato.

I campi di inCluster.values sono gli stessi di Milvus Helm Chart e si trovano qui.

Archiviazione esterna degli oggetti

L'uso di external nel file YAML del modello indica l'uso di un servizio di archiviazione di oggetti esterno. Per utilizzare un object storage esterno, è necessario impostare correttamente i campi spec.dependencies.storage e spec.config.minio nel CRD di Milvus.

Usare Amazon Web Service (AWS) S3 come archivio oggetti esterno

  • Configurare l'accesso ad AWS S3 per AK/SK

    Di solito si può accedere a un bucket S3 tramite una coppia di chiavi di accesso e una chiave segreta di accesso. È possibile creare un oggetto Secret per memorizzarli in Kubernetes come segue:

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

    Quindi è possibile configurare un bucket AWS S3 come storage esterno degli oggetti:

    # # 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"
    
  • Configurare l'accesso AWS S3 da AssumeRole

    In alternativa, si può fare in modo che Milvus acceda al bucket AWS S3 utilizzando AssumeRole, in modo da coinvolgere solo le credenziali temporanee invece del proprio AK/SK.

    Se questo è ciò che si preferisce, è necessario preparare un ruolo sulla console AWS e ottenere il suo ARN, che di solito è sotto forma di arn:aws:iam::<your account id>:role/<role-name>.

    Quindi creare un oggetto ServiceAccount per memorizzarlo in Kubernetes come segue:

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

    Una volta impostato il tutto, fare riferimento a ServiceAccount nel file YAML del modello e impostare spec.config.minio.useIAM su true per abilitare 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
    

Utilizzare Google Cloud Storage (GCS) come archivio oggetti esterno

Lo storage di oggetti AWS S3 non è l'unica scelta possibile. È possibile utilizzare anche il servizio di archiviazione degli oggetti di altri fornitori di cloud pubblici, come Google Cloud.

  • Configurazione dell'accesso a GCS da parte di AK/SK

    La configurazione è per lo più simile a quella dell'utilizzo di AWS S3. È ancora necessario creare un oggetto Secret per memorizzare le credenziali in 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>
    

    Quindi, è sufficiente modificare endpoint in storage.googleapis.com:443 e impostare spec.config.minio.cloudProvider in gcp come segue:

    # # 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
    
  • Configurazione dell'accesso GCS per AssumeRole

    Analogamente ad AWS S3, è possibile utilizzare Workload Identity per accedere a GCS con credenziali temporanee se si utilizza GKE come cluster Kubernetes.

    L'annotazione di ServiceAccount è diversa da quella di AWS EKS. È necessario specificare il nome dell'account del servizio GCP invece dell'ARN del ruolo.

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

    Quindi, è possibile configurare l'istanza Milvus per utilizzare il suddetto ServiceAccount e abilitare AssumeRole impostando spec.config.minio.useIAM su true come segue:

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

Cosa fare dopo

Imparare a configurare le altre dipendenze di Milvus con Milvus Operator:

Tradotto daDeepLogo

Try Managed Milvus for Free

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

Get Started
Feedback

Questa pagina è stata utile?