Configuration de Milvus sur Amazon EKS
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.
- Remplacez <broker-list> par le point de terminaison MSK pour le type d’authentification SASL/SCRAM,
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
- Remplacez la ligne par :
# 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 :
Fichier eks_cluster.yaml : https://aws.amazon.com/cn/blogs/china/build-open-source-vector-database-milvus-based-on-amazon-eks/
Fichier milvus_helm.yaml : https://raw.githubusercontent.com/milvus-io/milvus-helm/master/charts/milvus/values.yaml
Fichier milvus_cluster.yaml : copiez/collez depuis l’intérieur de ce blog.
Continuer à lire
Introducing Business Critical Plan: Enterprise-Grade Security and Compliance for Mission-Critical AI Applications
Discover Zilliz Cloud’s Business Critical Plan—offering advanced security, compliance, and uptime for mission-critical AI and vector database workloads.
AI Agents Are Quietly Transforming E-Commerce — Here’s How
Discover how AI agents transform e-commerce with autonomous decision-making, enhanced product discovery, and vector search capabilities for today's retailers.
Vector Databases vs. Time Series Databases
Use a vector database for similarity search and semantic relationships; use a time series database for tracking value changes over time.