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.

È 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:

• Configurare il Meta Storage con Milvus Operator
• Configurare la memorizzazione dei messaggi con Milvus Operator