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.
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 esDelete
y tieneRetain
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 establecespec.config.minio.useIAM
entrue
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
porstorage.googleapis.com:443
y configurarspec.config.minio.cloudProvider
porgcp
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 estableciendospec.config.minio.useIAM
entrue
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: