Blog
Configurare Milvus su Amazon EKS

Configurare Milvus su Amazon EKS

Jul 16, 202415 min read

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.

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

# 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:
1. File eks_cluster.yaml: https://aws.amazon.com/cn/blogs/china/build-open-source-vector-database-milvus-based-on-amazon-eks/
2. File milvus_helm.yaml: https://raw.githubusercontent.com/milvus-io/milvus-helm/master/charts/milvus/values.yaml
3. File milvus_cluster.yaml: Copia/incolla dall’interno di questo blog.

Aggiornato il Jul 09, 2026

Christy Bergman
Christy Bergman is a passionate Developer Advocate at Zilliz. She previously worked in distributed computing at Anyscale and as a Specialist AI/ML Solutions Architect at AWS. Christy studied applied math, is a self-taught coder, and has published papers, including one with ACM Recsys. She enjoys hiking and bird watching.

Continua a leggere

Why Not All VectorDBs Are Agent-Ready

Explore why choosing the right vector database is critical for scaling AI agents, and why traditional solutions fall short in production.

Milvus/Zilliz + Surveillance: How Vector Databases Transform Multi-Camera Tracking

See how Milvus vector database enhances multi-camera tracking with similarity-based matching for better surveillance in retail, warehouses and transport hubs.

Legal Document Analysis: Harnessing Zilliz Cloud's Semantic Search and RAG for Legal Insights

Enhance legal document analysis with Zilliz Cloud’s Semantic Search and RAG. Improve accuracy, efficiency, and scalability for contracts, case law, and compliance.