Blog
Configuration de Milvus sur Amazon EKS

Configuration de Milvus sur Amazon EKS

Jul 16, 202415 min read

Milvus est conçu dès le départ pour prendre en charge Kubernetes et peut être facilement déployé sur AWS. Pour créer un cluster de base de données vectorielle Milvus fiable et élastique, nous pouvons utiliser Amazon Elastic Kubernetes Service (Amazon EKS) comme Kubernetes géré, Amazon S3 comme Object Storage, Amazon Managed Streaming for Apache Kafka (Amazon MSK) comme Message Storage, et Amazon Elastic Load Balancing (Amazon ELB) comme Load Balancer.

Présentation de l’architecture Milvus

Architecture Milvus

EKS est le service Kubernetes géré d’Amazon qui s’exécute sur EC2 ou en mode serverless sur Fargate. Il est idéal pour les organisations qui utilisent déjà Kubernetes sur site, leur permettant de migrer leurs déploiements vers AWS avec des modifications minimales.

Ce blog utilise EC2 pour le déploiement, car Fargate ne peut pas gérer les revendications de volumes persistants (PVC) nécessaires aux dépendances de Milvus telles qu’etcd.

Nous fournirons des conseils étape par étape sur le déploiement d’un cluster Milvus à l’aide d’EKS et d’autres services. Une version plus détaillée de ce blog est disponible ici.

Prérequis

AWS CLI

Installez AWS CLI sur votre PC/Mac local ou votre instance Amazon EC2, qui servira de point de terminaison pour les opérations couvertes dans ce document. Si vous utilisez Amazon Linux 2 ou Amazon Linux 2023, les outils AWS CLI sont installés par défaut. Consultez Comment installer AWS CLI.

Vous trouverez ci-dessous une capture d’écran vérifiant qu’AWS CLI est installé.

% 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

Outils EKS : Kubectl, eksctl, helm

Installez les outils EKS sur le périphérique de point de terminaison préféré, notamment :

Consultez Bien démarrer avec EKS pour connaître les étapes d’installation détaillées. Vous trouverez ci-dessous une capture d’écran vérifiant les installations et les versions sur un ordinateur portable Mac M2 utilisant 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

Créer un compartiment Amazon S3

Lisez les règles de nommage des compartiments et respectez-les lorsque vous nommez votre compartiment AWS S3 à l’aide de la console AWS.

Créer un compartiment Amazon S3

Créer une clé KMS, Customer managed key.

La clé KMS ne peut pas être une clé gérée par AWS. Il doit s’agir d’une Customer-managed key. Après l’avoir créée, vous devrez attendre environ 10 minutes que la clé devienne active avant de pouvoir l’utiliser dans AWS Secrets Manager. À l’aide de la console AWS, accédez à KMS > Customer managed keys.

Créer une clé KMS, Customer managed key. .png

Créer un secret personnalisé dans AWS Secrets Manager.

Assurez-vous d’avoir attendu environ 10 minutes après avoir créé votre KMS Customer managed key. Créez maintenant un nouveau secret AWS Secrets Manager. À l’aide de la console AWS.

Choisissez un autre type de secret pour le type de secret.
Basculez l’éditeur de paires clé/valeur vers Plaintext. Saisissez du JSON avec des clés correspondant exactement à « username » et « password ».
Le nom du secret doit commencer par AmazonMSK_.
La clé de chiffrement doit être une clé gérée par le client KMS, et non une clé gérée par AWS.

Créer un secret personnalisé dans AWS Secrets Manager. .png

Créer une instance MSK

Ensuite, utilisez la console AWS pour créer un cluster Amazon MSK avec la fonctionnalité Kafka autoCreateTopics et la sécurité SASL/SCRAM activées.

Considérations lors de la création de MSK :

La dernière version stable de Milvus (v2.4.x) dépend de la fonctionnalité autoCreateTopics de Kafka. Ainsi, lors de la création de MSK, une configuration personnalisée doit être utilisée, et la propriété auto.create.topics.enable doit être modifiée de sa valeur par défaut false à true.

De plus, pour augmenter le débit des messages de MSK, il est recommandé d’augmenter les valeurs de message.max.bytes et replica.fetch.max.bytes.

auto.create.topics.enable=true

message.max.bytes=10485880

replica.fetch.max.bytes=20971760

Consultez les configurations MSK personnalisées pour plus de détails.

Créer une instance MSK.png

Milvus ne prend pas en charge l’authentification basée sur les rôles IAM pour MSK. Ainsi, lors de la création de MSK, activez l’option d’authentification SASL/SCRAM dans la configuration de sécurité et configurez le nom d’utilisateur et le mot de passe dans AWS Secrets Manager. Consultez Authentification par identifiants de connexion avec AWS Secrets Manager pour plus de détails.
Le groupe de sécurité pour MSK doit autoriser l’accès depuis le groupe de sécurité ou la plage d’adresses IP du cluster EKS.

paramètres de sécurité

Attendez environ 15 minutes que l’instance MSK soit provisionnée. Une fois prête, cliquez dessus et vous pourrez associer le secret personnalisé AWS Secrets Manager que vous avez créé précédemment.

AWS Secrets Manager

Créer un cluster Amazon EKS

Il existe de nombreuses façons de créer un cluster EKS, par exemple via la console, CloudFormation ou eksctl. Consultez le document Configurer l’utilisation d’Amazon EKS.

Cet article utilisera eksctl. eksctl est un outil de ligne de commande simple pour créer et gérer des clusters Kubernetes sur Amazon EKS. eksctl offre le moyen le plus rapide et le plus simple de créer un nouveau cluster avec des nœuds pour Amazon EKS. Pour plus d’informations, consultez la documentation officielle d’eksctl.

Étape 1 : Créez un fichier eks_cluster.yaml.

Consultez la documentation Milvus pour un exemple de fichier .yaml.

Remplacez le nom du cluster par le nom de votre cluster,
Remplacez region-code par la région AWS dans laquelle vous souhaitez créer le cluster.
Remplacez private-subnet-idx par vos sous-réseaux privés. Remarque : ce fichier de configuration crée un cluster EKS dans un VPC existant en spécifiant des sous-réseaux privés. Vous pouvez également supprimer la configuration du VPC et des sous-réseaux afin qu’eksctl crée automatiquement un nouveau VPC.

**Étape 2 : Exécutez la commande eksctl create cluster -f eks_cluster.yaml pour créer le cluster EKS. **

create cluster -f eks_cluster.yaml

Consultez le démarrage rapide d’Amazon EKS. Cette commande créera les ressources suivantes :

Un cluster EKS avec la version spécifiée.
Un groupe de nœuds géré avec 3 instances EC2 m6i.2xlarge.
Un fournisseur d’identité IAM OIDC et un ServiceAccount appelé aws-load-balancer-controller seront utilisés ultérieurement lors de l’installation de l’AWS Load Balancer Controller.
Un namespace milvus et un ServiceAccount milvus-s3-access-sa au sein de ce namespace. Cela sera utilisé ultérieurement lors de la configuration de S3 comme stockage d’objets pour Milvus.
Remarque : Par souci de simplicité, milvus-s3-access-sa reçoit des autorisations d’accès complètes à S3. Dans les déploiements de production, il est recommandé de suivre le principe du moindre privilège et de n’accorder l’accès qu’au bucket S3 spécifique utilisé pour Milvus.

Plusieurs add-ons, où vpc-cni, coredns, kube-proxy sont des add-ons principaux requis par EKS. aws-ebs-csi-driver est le pilote AWS EBS CSI qui permet aux clusters EKS de gérer le cycle de vie des volumes 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
…

Attendez que la création du cluster soit terminée. Une fois terminée, vous devriez voir une réponse semblable à la sortie suivante :

% EKS cluster "MilvusEKSTest" in "us-west-2" region is ready

Une fois le cluster créé, vous pouvez afficher les nœuds en exécutant :

% 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

Étape 3 : Créez une ebs-sc StorageClass configurée avec GP3 comme type de stockage, et définissez-la comme StorageClass par défaut.

Milvus utilise etcd comme Meta Storage et a besoin de cette StorageClass pour créer et gérer les PVC.

Exécutez cette commande 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

Exécutez une commande patch après la création pour faire de cette StorageClass la valeur par défaut.

% kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
storageclass.storage.k8s.io/gp2 patched

Vérifiez que la classe de stockage a été configurée correctement.

% 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

Étape 4 : Installez l’AWS Load Balancer Controller

Cela sera utilisé ultérieurement pour le Milvus Service et l’Attu Ingress. Consultez les instructions officielles de l’EKS Load Balancer Controller.

Ajoutez le dépôt eks-charts et mettez-le à jour.

% 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!⎈

Installez l’AWS Load Balancer Controller. Remplacez cluster-name par le nom de votre cluster. Le ServiceAccount nommé aws-load-balancer-controller a déjà été créé lors de la création du 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 installed!

Vérifiez si le contrôleur a été installé avec succès. La sortie devrait ressembler à ceci :

% 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

Déployer un cluster Milvus sur Amazon EKS

Milvus prend en charge plusieurs méthodes de déploiement, comme Operator et Helm. L’utilisation d’Operator est plus simple, mais Helm est plus direct et flexible. Nous utilisons donc Helm pour le déploiement.

Vous pouvez personnaliser la configuration via les valeurs lors du déploiement de Milvus avec le fichier milvus_helm.yaml.

Par défaut, Milvus crée minio et pulsar dans le cluster comme stockage d’objets et stockage de messages, respectivement. Nous allons apporter quelques modifications de configuration pour le rendre plus adapté à la production.

Étape 1 : Ajoutez le dépôt Helm de Milvus et mettez-le à jour.

% helm repo add milvus https://zilliztech.github.io/milvus-helm/
helm repo update
"milvus" already exists with the same configuration, skipping
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!⎈

Étape 2 : Créez un fichier milvus_cluster.yaml.

Le code suivant personnalise l’installation de Milvus, par exemple en configurant Amazon S3 comme stockage d’objets, Amazon MSK comme file d’attente de messages, etc. Nous fournirons des explications détaillées et des conseils de configuration après le bloc de code.

#####################################
# Section 1
# 
# Configure S3 as the Object Storage
#####################################

# Service account
# - this service account are used by External S3 access
serviceAccount:
  create: false
  name: milvus-s3-access-sa

# Close in-cluster minio
minio:
  enabled: false

# External S3
# - these configs are only used when `externalS3.enabled` is 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: ""

#####################################
# Section 2
# 
# Configure MSK as the Message Storage
#####################################

# Close in-cluster pulsar
pulsar:
  enabled: false

# Kafka externe
# - ces configurations ne sont utilisées que lorsque `externalKafka.enabled` est true
externalKafka:
  enabled: true
  brokerList: "<broker-list>"
  securityProtocol: SASL_SSL
  sasl:
    mechanisms: SCRAM-SHA-512
    username: "<username>"
    password: "<password>"
    
#####################################
# Section 3
# 
# Exposer le service Milvus pour qu’il soit accessible depuis l’extérieur du cluster (service LoadBalancer).
# ou y accéder depuis l’intérieur du cluster (service ClusterIP). Définissez le type de service et le port pour le servir.
#####################################
service:
  type: LoadBalancer
  port: 19530
  annotations: 
    service.beta.kubernetes.io/aws-load-balancer-type: external #AWS Load Balancer Controller prend en charge les services qui ont cette annotation 
    service.beta.kubernetes.io/aws-load-balancer-name : milvus-service #Nom défini par l’utilisateur donné à AWS Network Load Balancer
    #service.beta.kubernetes.io/aws-load-balancer-scheme: internal # interne ou accessible via Internet, permettant ensuite un accès public via Internet
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing" #Place l’équilibreur de charge sur des sous-réseaux publics
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip #Les IP des pods doivent être utilisées comme IP cibles (plutôt que les IP des nœuds)

#####################################
# Section 4
# 
# Installation d’Attu, l’interface graphique de gestion de 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
      
#####################################
# Section 5
# 
# Déploiement HA des composants principaux de Milvus
#####################################
rootCoordinator:
  replicas: 2
  activeStandby:
    enabled: true  # Activer active-standby lorsque vous définissez plusieurs réplicas pour le coordinateur racine
  resources: 
    limits:
      cpu: 1
      memory: 2Gi
indexCoordinator:
  replicas: 2
  activeStandby:
    enabled: true  # Activer active-standby lorsque vous définissez plusieurs réplicas pour le coordinateur d’index
  resources: 
    limits:
      cpu: "0.5"
      memory: 0.5Gi
queryCoordinator:
  replicas: 2
  activeStandby:
    enabled: true  # Activer active-standby lorsque vous définissez plusieurs réplicas pour le coordinateur de requêtes
  resources: 
    limits:
      cpu: "0.5"
      memory: 0.5Gi
dataCoordinator:
  replicas: 2
  activeStandby:
    enabled: true  # Activer active-standby lorsque vous définissez plusieurs réplicas pour le coordinateur de données
  resources: 
    limits:
      cpu: "0.5"
      memory: 0.5Gi
proxy:
  replicas: 2
  resources: 
    limits:
      cpu: 1
      memory: 4Gi

#####################################
# Section 6
# 
# Allocation des ressources 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

Le code est divisé en six sections. Suivez les instructions suivantes pour modifier les configurations correspondantes.

Section 1 : Configurez S3 comme stockage d’objets. serviceAccount accorde à Milvus l’accès à S3 (ici, il s’agit de milvus-s3-access-sa, qui a déjà été créé lors de la création du cluster EKS).
- Remplacez <region-code> par la région AWS dans laquelle vous avez créé le cluster.
- Remplacez <bucket-name> par le nom du bucket S3 et <root-path> par le préfixe du bucket S3 (peut être vide).
Section 2 : Configurez MSK comme stockage des messages.
- Remplacez <broker-list> par le point de terminaison MSK pour le type d’authentification SASL/SCRAM, et par le nom d’utilisateur et le mot de passe MSK. Vous pouvez obtenir <broker-list> à partir des informations client MSK, comme illustré dans l’image.

view client information.jpg

Section 3 : Cette section expose le point de terminaison du service Milvus afin qu’il soit accessible depuis l’extérieur du cluster. Par défaut, le point de terminaison Milvus utilise le service de type ClusterIP, qui n’est accessible qu’au sein du cluster EKS. Vous pouvez le remplacer par le type LoadBalancer si nécessaire pour autoriser l’accès depuis l’extérieur du cluster EKS. Le Service de type LoadBalancer utilise Amazon NLB comme équilibreur de charge.
- Conformément aux bonnes pratiques de sécurité, aws-load-balancer-scheme est configuré ici par défaut en mode internal, ce qui signifie que seul l’accès intranet à Milvus est autorisé. Si vous avez réellement besoin d’un accès Internet à Milvus, vous devez remplacer internal par internet-facing. Cliquez pour consulter les instructions de configuration du NLB.
  - Remplacez la ligne par : 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"

Section 4 : Installez et configurez Attu, un outil open-source d’administration de Milvus. Il dispose d’une interface graphique intuitive qui vous permet d’interagir facilement avec la base de données. Nous activons Attu, configurons l’ingress à l’aide d’AWS ALB et le définissons sur le type internet-facing afin qu’Attu soit accessible via Internet.
- Cliquez ici pour consulter le guide de configuration d’ALB.
Section 5 : Activez le déploiement HA des composants principaux de Milvus. D’après l’architecture, nous savons déjà que Milvus contient plusieurs composants indépendants et découplés. Par exemple, le service coordinateur agit comme couche de contrôle, en gérant la coordination des composants Root, Query, Data et Index. Le Proxy dans la couche d’accès sert de point de terminaison d’accès à la base de données. Ces composants n’ont par défaut qu’une seule réplique de pod. Pour améliorer la disponibilité de Milvus, il est particulièrement nécessaire de déployer plusieurs répliques de ces composants de service.
- Notez que les composants coordinateurs Root, Query, Data et Index doivent être déployés en plusieurs répliques avec l’option activeStandby activée.
Section 6 : Ajustez l’allocation des ressources pour les composants Milvus afin de répondre aux exigences de vos charges de travail. Le site Web de Milvus fournit également un outil de dimensionnement permettant de générer des suggestions de configuration en fonction du volume de données, des dimensions des vecteurs, des types d’index, etc. Il peut également générer un fichier de configuration Helm en un clic.
- La configuration suivante est la suggestion fournie par l’outil pour 1 million de vecteurs de 1024 dimensions et le type d’index HNSW.

Utilisez Helm pour créer Milvus (déployé dans l’espace de noms milvus).

Notez que vous pouvez remplacer demo-milvus par un nom personnalisé.

% 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

Exécutez la commande suivante pour vérifier l’état du déploiement.

% 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

La sortie ci-dessus montre que les composants Milvus sont tous AVAILABLE, et que plusieurs réplicas sont activés pour les composants de coordination.

Accéder aux points de terminaison Milvus et les gérer

Jusqu’à présent, nous avons déployé avec succès la base de données Milvus. Nous pouvons maintenant accéder à Milvus via des points de terminaison. Milvus expose des points de terminaison via des services Kubernetes. Attu expose des points de terminaison via Kubernetes Ingress.

Accéder aux points de terminaison Milvus à l’aide des services Kubernetes

Exécutez la commande suivante pour obtenir les points de terminaison des services :

% 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

Vous pouvez voir plusieurs services. Milvus prend en charge deux ports, le port 19530 et le port 9091 :

Le port 19530 est destiné à l’API gRPC et RESTful. C’est le port par défaut lorsque vous vous connectez à un serveur Milvus avec différents SDK Milvus ou clients HTTP.
Le port 9091 est un port de gestion pour la collecte de métriques, le profilage pprof et les sondes d’intégrité au sein de Kubernetes.

Parmi eux, le service demo-milvus fournit un point de terminaison d’accès à la base de données, utilisé pour établir une connexion avec les clients. Le point de terminaison de base de données est accessible au NLB en tant qu’équilibreur de charge du service. Vous pouvez obtenir le point de terminaison du service NLB dans la colonne EXTERNAL-IP.

Notez la colonne EXTERNAL-IP du NLB, qui dans ce cas est :

milvus-nlb-xxxx.elb.us-west-2.amazonaws.com   19530:31201/TCP,9091:31088/TCP

Accéder aux points de terminaison Milvus à l’aide d’Attu

Lorsque nous avons installé Milvus, nous avons également installé Attu, un outil d’administration pour gérer Milvus. Exécutez la commande suivante pour obtenir le point de terminaison :

% 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

Vous devriez voir un ingress appelé demo-milvus-attu, où la colonne ADDRESS est l’URL externe.

Ouvrez l’adresse Ingress dans un navigateur et vous verrez la page suivante.
Cliquez sur Connect pour vous connecter.

interface attu

Après vous être connecté, vous pouvez gérer les bases de données Milvus via :

gérer Milvus avec Attu

Tester la base de données vectorielle Milvus

Vous pouvez utiliser le code d’exemple officiel de Milvus pour tester si la base de données Milvus fonctionne correctement.

Étape 1 : Téléchargez directement le code d’exemple hello_milvus.py.

% wget https://raw.githubusercontent.com/milvus-io/pymilvus/master/examples/hello_milvus.py

Étape 2 : Modifiez l’hôte dans le code d’exemple pour utiliser le point de terminaison Kubernetes Milvus que nous avons obtenu précédemment.

print(fmt.format("start connecting to Milvus"))
connections.connect(
"default", 
host="milvus-nlb-xxx.elb.us-west-2.amazonaws.com", 
port="19530")

Étape 3 : Exécutez le code. Si le résultat suivant est renvoyé, Milvus fonctionne normalement.

% 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                  ===

Vous avez maintenant configuré Milvus avec succès sur EKS ! FÉLICITATIONS !!!

Conclusion

Cet article a présenté la base de données vectorielle open-source Milvus et expliqué comment la déployer sur AWS en utilisant des services gérés tels qu’Amazon EKS, S3, MSK et ELB afin d’obtenir une élasticité et une fiabilité supérieures.

Ressources

Blog AWS Milvus EKS : https://aws.amazon.com/cn/blogs/china/build-open-source-vector-database-milvus-based-on-amazon-eks/
Guide Milvus EKS : https://milvus.io/docs/eks.md
Guide de configuration Amazon EKS : https://docs.aws.amazon.com/eks/latest/userguide/setting-up.html
Guide de l’utilisateur Amazon EKS : https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html
Site Web officiel de Milvus : https://milvus.io/
Github Milvus : https://github.com/milvus-io/milvus
Site Web officiel d’eksctl : https://eksctl.io/
Fichiers YAML dont vous aurez besoin pour l’installation :
1. Fichier eks_cluster.yaml : https://aws.amazon.com/cn/blogs/china/build-open-source-vector-database-milvus-based-on-amazon-eks/
2. Fichier milvus_helm.yaml : https://raw.githubusercontent.com/milvus-io/milvus-helm/master/charts/milvus/values.yaml
3. Fichier milvus_cluster.yaml : copiez/collez depuis l’intérieur de ce blog.

Mis à jour le 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.

Continuer à lire

Top 10 Context Engineering Techniques You Should Know for Production RAG

A practical guide to context engineering for production LLM systems, covering RAG, context processing, memory, agents, and multimodal context.

Will Amazon S3 Vectors Kill Vector Databases—or Save Them?

AWS S3 Vectors aims for 90% cost savings for vector storage. But will it kill vectordbs like Milvus? A deep dive into costs, limits, and the future of tiered storage.

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.