Configurare Milvus su Amazon EKS
Milvus è progettato fin dall’inizio per supportare Kubernetes e può essere distribuito facilmente su AWS. Per creare un cluster di database vettoriale Milvus affidabile ed elastico, possiamo usare Amazon Elastic Kubernetes Service (Amazon EKS) come Kubernetes gestito, Amazon S3 come Object Storage, Amazon Managed Streaming for Apache Kafka (Amazon MSK) come Message Storage e Amazon Elastic Load Balancing (Amazon ELB) come Load Balancer.
Panoramica dell’architettura di Milvus
Architettura di Milvus
EKS è il servizio Kubernetes gestito di Amazon che viene eseguito su EC2 o in modalità serverless su Fargate. È ideale per le organizzazioni che usano già Kubernetes on-premises, consentendo loro di migrare le proprie distribuzioni su AWS con modifiche minime.
Questo blog utilizza EC2 per la distribuzione perché Fargate non può gestire le persistent volume claim (PVC) necessarie per le dipendenze di Milvus, come etcd.
Forniremo una guida passo dopo passo sulla distribuzione di un cluster Milvus utilizzando EKS e altri servizi. Una versione più dettagliata di questo blog è disponibile qui.
Prerequisiti
AWS CLI
Installa AWS CLI sul tuo PC/Mac locale o su un’istanza Amazon EC2, che servirà come endpoint per le operazioni trattate in questo documento. Se usi Amazon Linux 2 o Amazon Linux 2023, gli strumenti AWS CLI sono installati per impostazione predefinita. Consulta Come installare AWS CLI.
Di seguito è riportato uno screenshot che verifica che AWS CLI sia installato.
% which aws
/usr/local/bin/aws
% aws --version
aws-cli/2.15.34 Python/3.11.8 Darwin/23.5.0 exe/x86_64 prompt/off
Strumenti EKS: Kubectl, eksctl, helm
Installa gli strumenti EKS sul dispositivo endpoint preferito, inclusi:
Consulta Guida introduttiva a EKS per i passaggi di installazione dettagliati. Di seguito è riportato uno screenshot che verifica le installazioni e le versioni su un laptop Mac M2 che usa z shell:
% kubectl version
Client Version: v1.30.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
# Download eksctl
ARCH=arm64
PLATFORM=$(uname -s)_$ARCH
curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"
tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz
sudo mv /tmp/eksctl /usr/local/bin
% eksctl version
0.185.0
% helm list --all-namespaces
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
my-milvus default 1 2024-07-09 16:00:14.117945 -0700 PDT deployed milvus-4.1.34 2.4.5
Crea un bucket Amazon S3
Leggi le regole di denominazione dei bucket e osservale quando assegni un nome al tuo bucket AWS S3 utilizzando la console AWS.
Crea un bucket Amazon S3
Crea una KMS, Customer managed key.
La chiave KMS non può essere una chiave gestita da AWS. Deve essere una Customer-managed key. Dopo averla creata, dovrai attendere circa 10 minuti affinché la chiave diventi attiva prima di poterla usare in AWS Secrets Manager. Utilizzando la console AWS, vai a KMS > Customer managed keys.
Crea una KMS, Customer managed key. .png
Crea un segreto personalizzato in AWS Secrets Manager.
Assicurati di aver atteso circa 10 minuti dopo aver creato la tua KMS Customer managed key. Ora, crea un nuovo segreto AWS Secrets Manager. Utilizzando la console AWS.
Scegli un altro tipo di segreto per il tipo di segreto.
Imposta l’editor delle coppie chiave/valore su Plaintext. Inserisci JSON con chiavi che corrispondano esattamente a “username” e “password”.
Il nome del segreto deve iniziare con AmazonMSK_.
La chiave di crittografia deve essere una chiave gestita dal cliente KMS, non una chiave gestita da AWS.
Crea un segreto personalizzato in AWS Secrets Manager. .png
Crea un’istanza MSK
Quindi, usa la console AWS per creare un cluster Amazon MSK con la funzionalità Kafka autoCreateTopics e la sicurezza SASL/SCRAM abilitate.
Considerazioni durante la creazione di MSK:
L’ultima versione stabile di Milvus (v2.4.x) dipende dalla funzionalità autoCreateTopics di Kafka, quindi durante la creazione di MSK è necessario utilizzare una configurazione personalizzata, oltre a modificare la proprietà auto.create.topics.enable dal valore predefinito false a true.
Inoltre, per aumentare il throughput dei messaggi di MSK, si consiglia di aumentare i valori di message.max.bytes e replica.fetch.max.bytes.
auto.create.topics.enable=true
message.max.bytes=10485880
replica.fetch.max.bytes=20971760
Consulta le configurazioni MSK personalizzate per i dettagli.
Crea un’istanza MSK.png
Milvus non supporta l’autenticazione basata su ruoli IAM per MSK, quindi durante la creazione di MSK, abilita l’opzione di autenticazione SASL/SCRAM nella configurazione di sicurezza e configura il nome utente e la password in AWS Secrets Manager. Consulta Autenticazione con credenziali di accesso con AWS Secrets Manager per i dettagli.
Il gruppo di sicurezza per MSK deve consentire l’accesso dal gruppo di sicurezza o dall’intervallo di indirizzi IP del cluster EKS.
impostazioni di sicurezza
Attendi ~15 minuti per il provisioning dell’istanza MSK. Una volta pronta, fai clic su di essa e potrai associare il segreto personalizzato di AWS Secrets Manager creato in precedenza.
AWS Secrets Manager
Crea un cluster Amazon EKS
Esistono molti modi per creare un cluster EKS, ad esempio tramite la console, CloudFormation o eksctl. Consulta il documento Configurazione per utilizzare Amazon EKS.
Questo post userà eksctl. eksctl è un semplice strumento da riga di comando per creare e gestire cluster Kubernetes su Amazon EKS. eksctl offre il modo più rapido e semplice per creare un nuovo cluster con nodi per Amazon EKS. Per ulteriori informazioni, consulta la documentazione ufficiale di eksctl.
Passaggio 1: Crea un file eks_cluster.yaml.
Consulta la documentazione di Milvus per un esempio di file .yaml.
Sostituisci il nome del cluster con il nome del tuo cluster,
Sostituisci region-code con la regione AWS in cui desideri creare il cluster.
Sostituisci private-subnet-idx con le tue subnet private. Nota: questo file di configurazione crea un cluster EKS in un VPC esistente specificando subnet private. Puoi anche rimuovere la configurazione di VPC e subnet in modo che eksctl crei automaticamente un nuovo VPC.
**Passaggio 2: Esegui il comando eksctl create cluster -f eks_cluster.yaml per creare il cluster EKS. **
create cluster -f eks_cluster.yaml
Consulta Amazon EKS Quickstart. Questo comando creerà le seguenti risorse:
Un cluster EKS con la versione specificata.
Un gruppo di nodi gestito con 3 istanze EC2 m6i.2xlarge.
Un provider di identità IAM OIDC e un ServiceAccount chiamato aws-load-balancer-controller verranno usati in seguito durante l’installazione di AWS Load Balancer Controller.
Un namespace milvus e un ServiceAccount milvus-s3-access-sa all'interno di questo namespace. Questo verrà utilizzato in seguito durante la configurazione di S3 come object storage per Milvus.
Nota: Per semplicità, a milvus-s3-access-sa vengono concessi permessi di accesso completo a S3. Nelle distribuzioni di produzione, si consiglia di seguire il principio del privilegio minimo e di concedere accesso solo allo specifico bucket S3 utilizzato per Milvus.
- Più add-on, dove vpc-cni, coredns, kube-proxy sono add-on core richiesti da EKS. aws-ebs-csi-driver è il driver AWS EBS CSI che consente ai cluster EKS di gestire il ciclo di vita dei volumi Amazon EBS.
% eksctl create cluster -f eks_cluster.yaml
2024-07-10 17:45:32 [ℹ] eksctl version 0.185.0
2024-07-10 17:45:32 [ℹ] using region us-west-2
2024-07-10 17:45:32 [✔] using existing VPC (vpc-84c5b3fc) and
…
2024-07-10 17:45:32 [ℹ] building cluster stack "eksctl-MilvusEKSTest-cluster"
2024-07-10 17:45:33 [ℹ] deploying stack
…
Attendi il completamento della creazione del cluster. Al completamento, dovresti vedere una risposta simile al seguente output:
% EKS cluster "MilvusEKSTest" in "us-west-2" region is ready
Una volta creato il cluster, puoi visualizzare i nodi eseguendo:
% kubectl get nodes -A -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
ip-172-31-22-240.us-west-2.compute.internal Ready <none> 11m v1.28.8-eks-ae9a62a 172.31.22.240 52.40.226.172 Amazon Linux 2 5.10.219-208.866.amzn2.x86_64 containerd://1.7.11
ip-172-31-31-71.us-west-2.compute.internal Ready <none> 11m v1.28.8-eks-ae9a62a 172.31.31.71 35.165.133.62 Amazon Linux 2 5.10.219-208.866.amzn2.x86_64 containerd://1.7.11
ip-172-31-33-44.us-west-2.compute.internal Ready <none> 11m v1.28.8-eks-ae9a62a 172.31.33.44 35.91.5.162 Amazon Linux 2 5.10.219-208.866.amzn2.x86_64 containerd://1.7.11
Passaggio 3: Crea una ebs-sc StorageClass configurata con GP3 come tipo di storage e impostala come StorageClass predefinita.
Milvus utilizza etcd come Meta Storage e necessita di questa StorageClass per creare e gestire le PVC.
- Esegui questo comando cat.
% cat <<EOF | kubectl apply -f -
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
EOF
storageclass.storage.k8s.io/ebs-sc created
- Esegui un comando patch dopo la creazione per rendere questa StorageClass quella predefinita.
% kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
storageclass.storage.k8s.io/gp2 patched
- Verifica che la storage class sia stata configurata correttamente.
% kubectl get storageclass
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
ebs-sc ebs.csi.aws.com Delete WaitForFirstConsumer false 6m39s
gp2 kubernetes.io/aws-ebs Delete WaitForFirstConsumer false 44m
Passaggio 4: Installa AWS Load Balancer Controller
Questo verrà utilizzato in seguito per il Service Milvus e l'Ingress Attu. Fai riferimento alle istruzioni ufficiali di EKS Load Balancer Controller.
Aggiungi il repo eks-charts e aggiornalo.
% helm repo add eks https://aws.github.io/eks-charts
"eks" has been added to your repositories
% helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "eks" chart repository
...Successfully got an update from the "zilliztech" chart repository
...Successfully got an update from the "milvus" chart repository
Update Complete. ⎈Happy Helming!⎈
Installa l’AWS Load Balancer Controller. Sostituisci cluster-name con il nome del tuo cluster. Il ServiceAccount chiamato aws-load-balancer-controller era già stato creato quando è stato creato il cluster EKS.
% helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
-n kube-system \
--set clusterName=MilvusEKSTest \
--set serviceAccount.create=false \
--set serviceAccount.name=aws-load-balancer-controller
NAME: aws-load-balancer-controller
LAST DEPLOYED: Wed Jul 10 19:00:34 2024
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
AWS Load Balancer controller installato!
Verifica se il controller è stato installato correttamente. L’output dovrebbe essere simile a:
% kubectl get deployment -n kube-system aws-load-balancer-controller
NAME READY UP-TO-DATE AVAILABLE AGE
aws-load-balancer-controller 2/2 2 2 88s
Distribuire un cluster Milvus su Amazon EKS
Milvus supporta diversi metodi di distribuzione come Operator e Helm. Usare Operator è più semplice, ma Helm è più diretto e flessibile. Quindi usiamo Helm per la distribuzione.
Puoi personalizzare la configurazione tramite i valori durante la distribuzione di Milvus con il file milvus_helm.yaml.
Per impostazione predefinita, Milvus crea minio e pulsar all’interno del cluster rispettivamente come Object Storage e Message Storage. Apporteremo alcune modifiche alla configurazione per renderla più adatta alla produzione.
Passaggio 1: Aggiungi il repo Helm di Milvus e aggiornalo.
% helm repo add milvus https://zilliztech.github.io/milvus-helm/
helm repo update
"milvus" esiste già con la stessa configurazione, operazione ignorata
Attendi mentre scarichiamo gli ultimi aggiornamenti dai tuoi repository di chart...
...Aggiornamento ottenuto correttamente dal repository di chart "eks"
...Aggiornamento ottenuto correttamente dal repository di chart "zilliztech"
...Aggiornamento ottenuto correttamente dal repository di chart "milvus"
Aggiornamento completato. ⎈Buon Helming!⎈
Passaggio 2: Crea un file milvus_cluster.yaml.
Il codice seguente personalizza l’installazione di Milvus, ad esempio configurando Amazon S3 come object storage, Amazon MSK come coda di messaggi, ecc. Forniremo spiegazioni dettagliate e indicazioni di configurazione dopo il blocco di codice.
#####################################
# Sezione 1
#
# Configura S3 come Object Storage
#####################################
# Service account
# - questo service account viene utilizzato dall’accesso a S3 esterno
serviceAccount:
create: false
name: milvus-s3-access-sa
# Chiudi minio all’interno del cluster
minio:
enabled: false
# S3 esterno
# - queste configurazioni vengono utilizzate solo quando `externalS3.enabled` è true
externalS3:
enabled: true
host: "s3.<region-code>.amazonaws.com"
port: "443"
useSSL: true
bucketName: "<bucket-name>"
rootPath: "<root-path>"
useIAM: true
cloudProvider: "aws"
iamEndpoint: ""
#####################################
# Sezione 2
#
# Configura MSK come Message Storage
#####################################
# Chiudi pulsar all’interno del cluster
pulsar:
enabled: false
# Kafka esterno
# - queste configurazioni sono utilizzate solo quando `externalKafka.enabled` è true
externalKafka:
enabled: true
brokerList: "<broker-list>"
securityProtocol: SASL_SSL
sasl:
mechanisms: SCRAM-SHA-512
username: "<username>"
password: "<password>"
#####################################
# Sezione 3
#
# Esporre il servizio Milvus per l'accesso dall'esterno del cluster (servizio LoadBalancer).
# oppure accedervi dall'interno del cluster (servizio ClusterIP). Impostare il tipo di servizio e la porta per servirlo.
#####################################
service:
type: LoadBalancer
port: 19530
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: external #AWS Load Balancer Controller soddisfa i servizi che hanno questa annotazione
service.beta.kubernetes.io/aws-load-balancer-name : milvus-service #Nome definito dall'utente assegnato ad AWS Network Load Balancer
#service.beta.kubernetes.io/aws-load-balancer-scheme: internal # internal o internet-facing, consentendo in seguito l'accesso pubblico via internet
service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing" #Posiziona il load balancer su subnet pubbliche
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip #Gli IP dei Pod dovrebbero essere utilizzati come IP di destinazione (anziché gli IP dei nodi)
#####################################
# Sezione 4
#
# Installazione di Attu, la GUI di gestione di Milvus
#####################################
attu:
enabled: true
name: attu
service:
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: external
service.beta.kubernetes.io/aws-load-balancer-name : milvus-attu-service
service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
labels: {}
type: LoadBalancer
port: 3000
ingress:
enabled: false
#####################################
# Sezione 5
#
# Distribuzione HA dei componenti principali di Milvus
#####################################
rootCoordinator:
replicas: 2
activeStandby:
enabled: true # Abilita active-standby quando imposti più repliche per il root coordinator
resources:
limits:
cpu: 1
memory: 2Gi
indexCoordinator:
replicas: 2
activeStandby:
enabled: true # Abilita active-standby quando imposti più repliche per l'index coordinator
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
queryCoordinator:
replicas: 2
activeStandby:
enabled: true # Abilita active-standby quando imposti più repliche per il query coordinator
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
dataCoordinator:
replicas: 2
activeStandby:
enabled: true # Abilita active-standby quando imposti più repliche per il data coordinator
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
proxy:
replicas: 2
resources:
limits:
cpu: 1
memory: 4Gi
#####################################
# Sezione 6
#
# Allocazione delle risorse di Milvus
#####################################
queryNode:
replicas: 1
resources:
limits:
cpu: 2
memory: 8Gi
dataNode:
replicas: 1
resources:
limits:
cpu: 1
memory: 4Gi
indexNode:
replicas: 1
resources:
limits:
cpu: 4
memory: 8Gi
Il codice è suddiviso in sei sezioni. Segui le seguenti istruzioni per modificare le configurazioni corrispondenti.
Sezione 1: Configura S3 come Object Storage. serviceAccount concede a Milvus l'accesso a S3 (qui è milvus-s3-access-sa, che era già stato creato durante la creazione del cluster EKS).
Sostituisci <region-code> con la regione AWS in cui hai creato il cluster.
Sostituisci <bucket-name> con il nome del bucket S3 e <root-path> con il prefisso del bucket S3 (può essere vuoto).
Sezione 2: Configura MSK come Message Storage.
- Sostituisci <broker-list> con l'endpoint MSK per il tipo di autenticazione SASL/SCRAM,
e con il nome utente e la password MSK. Puoi ottenere <broker-list> dalle informazioni del client MSK, come mostrato nell'immagine.
- Sostituisci <broker-list> con l'endpoint MSK per il tipo di autenticazione SASL/SCRAM,
view client information.jpg
Sezione 3: Questa sezione espone l'endpoint del servizio Milvus affinché sia accessibile dall'esterno del cluster. Per impostazione predefinita, l'endpoint Milvus utilizza il servizio di tipo ClusterIP, accessibile solo all'interno del cluster EKS. Puoi modificarlo nel tipo LoadBalancer, se necessario, per consentire l'accesso dall'esterno del cluster EKS. Il Service di tipo LoadBalancer utilizza Amazon NLB come load balancer.
Secondo le best practice di sicurezza, aws-load-balancer-scheme è configurato qui per impostazione predefinita in modalità internal, il che significa che è consentito solo l'accesso intranet a Milvus. Se hai effettivamente bisogno dell'accesso Internet a Milvus, devi cambiare internal in internet-facing. Fai clic per visualizzare le istruzioni di configurazione NLB.
- Modifica la riga in:
aws-load-balancer-scheme: internet-facing
- Modifica la riga in:
# service.beta.kubernetes.io/aws-load-balancer-scheme: internal
service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
Sezione 4: Installa e configura Attu, che è uno strumento open-source di amministrazione Milvus. Ha una GUI intuitiva che consente di interagire facilmente con il database. Abilitiamo Attu, configuriamo l'ingress utilizzando AWS ALB e lo impostiamo sul tipo internet-facing in modo che Attu possa essere accessibile tramite Internet.
- Fai clic qui per la guida alla configurazione di ALB.
Sezione 5: Abilita il deployment HA dei componenti Core di Milvus. In base all'architettura, sappiamo già che Milvus contiene più componenti indipendenti e disaccoppiati. Ad esempio, il servizio coordinator agisce come livello di controllo, gestendo il coordinamento per i componenti Root, Query, Data e Index. Il Proxy nel livello di accesso funge da endpoint di accesso al database. Questi componenti hanno per impostazione predefinita solo 1 replica del pod. Per migliorare la disponibilità di Milvus, il deployment di più repliche di questi componenti di servizio è particolarmente necessario.
- Nota che i componenti coordinator Root, Query, Data e Index devono essere distribuiti in multi-replica con l'opzione activeStandby abilitata.
Sezione 6: Regola l'allocazione delle risorse per i componenti Milvus per soddisfare i requisiti dei tuoi workload. Il sito web di Milvus fornisce anche uno strumento di dimensionamento per generare suggerimenti di configurazione basati su volume dei dati, dimensioni dei vettori, tipi di indice, ecc. Può anche generare un file di configurazione Helm con un clic.
- La seguente configurazione è il suggerimento fornito dallo strumento per 1 milione di vettori a 1024 dimensioni e tipo di indice HNSW.
Usa Helm per creare Milvus (distribuito nel namespace milvus).
- Nota che puoi sostituire demo-milvus con un nome personalizzato.
% helm install demo-milvus milvus/milvus -n milvus -f milvus_cluster.yaml
W0710 19:35:08.789610 64030 warnings.go:70] annotation "kubernetes.io/ingress.class" is deprecated, please use 'spec.ingressClassName' instead
NAME: demo-milvus
LAST DEPLOYED: Wed Jul 10 19:35:06 2024
NAMESPACE: milvus
STATUS: deployed
REVISION: 1
TEST SUITE: None
Esegui il seguente comando per controllare lo stato del deployment.
% kubectl get deployment -n milvus
NAME READY UP-TO-DATE AVAILABLE AGE
demo-milvus-attu 1/1 1 1 5m27s
demo-milvus-datacoord 2/2 2 2 5m27s
demo-milvus-datanode 1/1 1 1 5m27s
demo-milvus-indexcoord 2/2 2 2 5m27s
demo-milvus-indexnode 1/1 1 1 5m27s
demo-milvus-proxy 2/2 2 2 5m27s
demo-milvus-querycoord 2/2 2 2 5m27s
demo-milvus-querynode 1/1 1 1 5m27s
demo-milvus-rootcoord 2/2 2 2 5m27s
L'output sopra mostra che i componenti Milvus sono tutti AVAILABLE e che i componenti di coordinamento hanno più repliche abilitate.
Accesso e gestione degli endpoint Milvus
Finora abbiamo distribuito con successo il database Milvus. Ora possiamo accedere a Milvus tramite endpoint. Milvus espone endpoint tramite i servizi Kubernetes. Attu espone endpoint tramite Kubernetes Ingress.
Accesso agli endpoint Milvus usando i servizi Kubernetes
Esegui il seguente comando per ottenere gli endpoint del servizio:
% kubectl get svc -n milvus
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
demo-etcd ClusterIP 172.20.103.138 <none> 2379/TCP,2380/TCP 62m
demo-etcd-headless ClusterIP None <none> 2379/TCP,2380/TCP 62m
demo-milvus LoadBalancer 172.20.219.33 milvus-nlb-xxxx.elb.us-west-2.amazonaws.com 19530:31201/TCP,9091:31088/TCP 62m
demo-milvus-datacoord ClusterIP 172.20.214.106 <none> 13333/TCP,9091/TCP 62m
demo-milvus-datanode ClusterIP None <none> 9091/TCP 62m
demo-milvus-indexcoord ClusterIP 172.20.106.51 <none> 31000/TCP,9091/TCP 62m
demo-milvus-indexnode ClusterIP None <none> 9091/TCP 62m
demo-milvus-querycoord ClusterIP 172.20.136.213 <none> 19531/TCP,9091/TCP 62m
demo-milvus-querynode ClusterIP None <none> 9091/TCP 62m
demo-milvus-rootcoord ClusterIP 172.20.173.98 <none> 53100/TCP,9091/TCP 62m
Puoi vedere diversi servizi. Milvus supporta due porte, la porta 19530 e la porta 9091:
La porta 19530 è per gRPC e l'API RESTful. È la porta predefinita quando ti connetti a un server Milvus con diversi SDK Milvus o client HTTP.
La porta 9091 è una porta di gestione per la raccolta di metriche, il profiling pprof e i probe di integrità all'interno di Kubernetes.
Tra questi, il servizio demo-milvus fornisce un endpoint di accesso al database, che viene utilizzato per stabilire una connessione con i client. L'endpoint del database è accessibile tramite l'NLB come bilanciatore del carico del servizio. Puoi ottenere l'endpoint del servizio NLB dalla colonna EXTERNAL-IP.
Prendi nota della colonna EXTERNAL-IP dell'NLB, che in questo caso è:
milvus-nlb-xxxx.elb.us-west-2.amazonaws.com 19530:31201/TCP,9091:31088/TCP
Accesso agli endpoint Milvus usando Attu
Quando abbiamo installato Milvus, abbiamo installato anche Attu, uno strumento di amministrazione per gestire Milvus. Esegui il seguente comando per ottenere l'endpoint:
% kubectl get ingress -n milvus
NAME CLASS HOSTS ADDRESS PORTS AGE
demo-milvus-attu <none> * k8s-attu-xxxx.us-west-2.elb.amazonaws.com 80 27s
Dovresti vedere un ingress chiamato demo-milvus-attu, in cui la colonna ADDRESS è l'URL esterno.
Apri l’indirizzo Ingress in un browser e visualizza la seguente pagina.
Fai clic su Connect per accedere.
interfaccia attu
Dopo l’accesso, puoi gestire i database Milvus tramite:
gestire Milvus usando Attu
Testare il database vettoriale Milvus
Puoi usare il codice di esempio ufficiale di Milvus per verificare se il database Milvus funziona correttamente.
- Passaggio 1: Scarica direttamente il codice di esempio hello_milvus.py.
% wget https://raw.githubusercontent.com/milvus-io/pymilvus/master/examples/hello_milvus.py
- Passaggio 2: Modifica l’host nel codice di esempio con l’endpoint Kubernetes di Milvus ottenuto in precedenza.
print(fmt.format("start connecting to Milvus"))
connections.connect(
"default",
host="milvus-nlb-xxx.elb.us-west-2.amazonaws.com",
port="19530")
- Passaggio 3: Esegui il codice. Se viene restituito il seguente risultato, Milvus è in esecuzione normalmente.
% python3 hello_milvus.py
=== start connecting to Milvus ===
Does collection hello_milvus exist in Milvus: False
=== Create collection `hello_milvus` ===
=== Start inserting entities ===
Number of entities in Milvus: 3000
=== Start Creating index IVF_FLAT ===
=== Start loading ===
Ora hai configurato con successo Milvus su EKS! CONGRATULAZIONI!!!
Conclusione
Questo post ha presentato il database vettoriale open-source Milvus e ha spiegato come distribuirlo su AWS utilizzando servizi gestiti come Amazon EKS, S3, MSK ed ELB per ottenere maggiore elasticità e affidabilità.
Risorse
Blog AWS Milvus EKS: https://aws.amazon.com/cn/blogs/china/build-open-source-vector-database-milvus-based-on-amazon-eks/
Guida Milvus EKS: https://milvus.io/docs/eks.md
Guida alla configurazione di Amazon EKS: https://docs.aws.amazon.com/eks/latest/userguide/setting-up.html
Guida utente Amazon EKS: https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html
Sito web ufficiale Milvus: https://milvus.io/
Github Milvus: https://github.com/milvus-io/milvus
Sito web ufficiale eksctl: https://eksctl.io/
File YAML necessari per l’installazione:
File eks_cluster.yaml: https://aws.amazon.com/cn/blogs/china/build-open-source-vector-database-milvus-based-on-amazon-eks/
File milvus_helm.yaml: https://raw.githubusercontent.com/milvus-io/milvus-helm/master/charts/milvus/values.yaml
File milvus_cluster.yaml: Copia/incolla dall’interno di questo blog.
Continua a leggere
What Exactly Are AI Agents? Why OpenAI and LangChain Are Fighting Over Their Definition?
AI agents are software programs powered by AI that can perceive their environment, make decisions, and take actions to achieve a goal—often autonomously.
What is the K-Nearest Neighbors (KNN) Algorithm in Machine Learning?
KNN is a supervised machine learning technique and algorithm for classification and regression. This post is the ultimate guide to KNN.
DeepRAG: Thinking to Retrieval Step by Step for Large Language Models
Discover DeepRAG, an advanced retrieval-augmented generation (RAG) model that improves LLM accuracy by retrieving only essential data through step-by-step reasoning.