Configurar o armazenamento de objectos com o Milvus Operator
O Milvus usa o MinIO ou o S3 como armazenamento de objetos para manter arquivos de grande escala, como arquivos de índice e logs binários. Este tópico apresenta como configurar as dependências de armazenamento de objetos quando você instala o Milvus com o Milvus Operator. Para obter mais detalhes, consulte Configurar o armazenamento de objetos com o Milvus Operator no repositório do Milvus Operator.
Este tópico pressupõe que você implantou o Milvus Operator.
É necessário especificar um arquivo de configuração para usar o Milvus Operator para iniciar um cluster do Milvus.
kubectl apply -f https://raw.githubusercontent.com/zilliztech/milvus-operator/main/config/samples/milvus_cluster_default.yaml
Só é necessário editar o modelo de código em milvus_cluster_default.yaml
para configurar dependências de terceiros. As secções seguintes apresentam como configurar o armazenamento de objectos, etcd, e Pulsar respetivamente.
Configurar o armazenamento de objetos
Um cluster Milvus usa MinIO ou S3 como armazenamento de objetos para persistir arquivos de grande escala, como arquivos de índice e logs binários. Adicione os campos obrigatórios em spec.dependencies.storage
para configurar o armazenamento de objectos, as opções possíveis são external
e inCluster
.
Armazenamento interno de objectos
Por defeito, o Milvus Operator implementa um MinIO no cluster para o Milvus. Segue-se um exemplo de configuração para demonstrar como utilizar este MinIO como um armazenamento de objectos 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
Após a aplicação da configuração acima, o MinIO no cluster será executado em modo autónomo com um limite de memória de até 100Mi. Note que
O campo
deletionPolicy
especifica a política de eliminação do MinIO em cluster. A predefinição éDelete
e temRetain
como opção alternativa.Delete
indica que o armazenamento de objectos em cluster é eliminado quando pára a instância do Milvus.Retain
indica que o armazenamento de objectos no cluster é mantido como serviço de dependência para arranques posteriores da instância do Milvus.
O campo
pvcDeletion
especifica se o PVC (Persistent Volume Claim) deve ser excluído quando o MinIO no cluster for excluído.
Os campos em inCluster.values
são os mesmos que os do Milvus Helm Chart, e pode encontrá-los aqui.
Armazenamento de objectos externos
A utilização de external
no ficheiro YAML do modelo indica a utilização de um serviço de armazenamento de objectos externo. Para utilizar um armazenamento de objectos externo, é necessário definir corretamente os campos em spec.dependencies.storage
e spec.config.minio
no Milvus CRD.
Utilizar o Amazon Web Service (AWS) S3 como armazenamento externo de objectos
Configurar o acesso ao AWS S3 por AK/SK
Um bucket S3 pode normalmente ser acedido por um par de uma chave de acesso e uma chave secreta de acesso. Você pode criar um objeto
Secret
para armazená-los no seu Kubernetes da seguinte forma:# # 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>
Em seguida, você pode configurar um bucket do AWS S3 como o armazenamento de objeto 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 o acesso ao AWS S3 por AssumeRole
Como alternativa, você pode fazer com que o Milvus acesse seu bucket do AWS S3 usando AssumeRole, para que apenas credenciais temporárias sejam envolvidas em vez de seu AK/SK real.
Se preferir, tem de preparar uma função na sua consola AWS e obter o seu ARN, que tem normalmente a forma de
arn:aws:iam::<your account id>:role/<role-name>
.Em seguida, crie um objeto
ServiceAccount
para armazená-lo em seu Kubernetes da seguinte maneira:apiVersion: v1 kind: ServiceAccount metadata: name: my-release-sa annotations: eks.amazonaws.com/role-arn: <my-role-arn>
Depois de tudo pronto, faça referência ao
ServiceAccount
acima no arquivo YAML do modelo e definaspec.config.minio.useIAM
paratrue
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
Usar o Google Cloud Storage (GCS) como armazenamento de objeto externo
O armazenamento de objetos do AWS S3 não é a única opção. Você também pode usar o serviço de armazenamento de objetos de outros provedores de nuvem pública, como o Google Cloud.
Configurar o acesso ao GCS por AK/SK
A configuração é, em grande parte, semelhante à da utilização do AWS S3. Você ainda precisa criar um objeto
Secret
para armazenar suas credenciais no seu 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>
Depois, só precisa de alterar
endpoint
parastorage.googleapis.com:443
e definirspec.config.minio.cloudProvider
paragcp
como se 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
Configurar o acesso ao GCS por AssumeRole
Semelhante ao AWS S3, você também pode usar o Workload Identity para acessar o GCS com credenciais temporárias se estiver usando o GKE como seu cluster do Kubernetes.
A anotação do
ServiceAccount
é diferente da do AWS EKS. Tem de especificar o nome da conta de serviço GCP em vez da função ARN.apiVersion: v1 kind: ServiceAccount metadata: name: my-release-sa annotations: iam.gke.io/gcp-service-account: <my-gcp-service-account-name>
Em seguida, pode configurar a sua instância Milvus para utilizar o
ServiceAccount
acima e ativar o AssumeRole definindospec.config.minio.useIAM
paratrue
da seguinte forma: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 ...
O que vem a seguir
Saiba como configurar outras dependências do Milvus com o Milvus Operator: