Milvus auf Amazon EKS einrichten
Milvus wurde von Anfang an für die Unterstützung von Kubernetes entwickelt und kann problemlos auf AWS bereitgestellt werden. Um einen zuverlässigen, elastischen Milvus-Vektordatenbank-Cluster aufzubauen, können wir Amazon Elastic Kubernetes Service (Amazon EKS) als verwaltetes Kubernetes, Amazon S3 als Object Storage, Amazon Managed Streaming for Apache Kafka (Amazon MSK) als Message Storage und Amazon Elastic Load Balancing (Amazon ELB) als Load Balancer verwenden.
Milvus-Architekturübersicht
Milvus-Architektur
EKS ist Amazons verwalteter Kubernetes-Service, der auf EC2 oder serverlos auf Fargate läuft. Er ist ideal für Organisationen, die Kubernetes bereits lokal verwenden, da sie ihre Bereitstellungen mit minimalen Änderungen zu AWS migrieren können.
Dieser Blog verwendet EC2 für die Bereitstellung, da Fargate keine Persistent Volume Claims (PVCs) verarbeiten kann, die für Milvus-Abhängigkeiten wie etcd benötigt werden.
Wir bieten eine Schritt-für-Schritt-Anleitung zur Bereitstellung eines Milvus-Clusters mit EKS und anderen Services. Eine ausführlichere Version dieses Blogs ist hier verfügbar.
Voraussetzungen
AWS CLI
Installieren Sie AWS CLI auf Ihrem lokalen PC/Mac oder Ihrer Amazon EC2-Instanz, die als Ihr Endpunkt für die in diesem Dokument behandelten Vorgänge dient. Wenn Sie Amazon Linux 2 oder Amazon Linux 2023 verwenden, sind die AWS CLI-Tools standardmäßig installiert. Siehe So installieren Sie AWS CLI.
Unten sehen Sie einen Screenshot, der bestätigt, dass AWS CLI installiert ist.
% 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
EKS-Tools: Kubectl, eksctl, helm
Installieren Sie die EKS-Tools auf dem bevorzugten Endpunktgerät, darunter:
Siehe EKS-Erste Schritte für detaillierte Installationsschritte. Unten sehen Sie einen Screenshot, der die Installationen und Versionen auf einem Mac M2-Laptop mit z shell bestätigt:
% 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
Erstellen eines Amazon S3-Buckets
Lesen Sie die Regeln zur Bucket-Benennung und beachten Sie diese, wenn Sie Ihren AWS S3-Bucket über die AWS console benennen.
Erstellen eines Amazon S3-Buckets
Erstellen eines KMS, Customer managed key.
Der KMS-Schlüssel kann kein AWS-managed key sein. Es muss ein Customer-managed key sein. Nachdem Sie ihn erstellt haben, müssen Sie etwa 10 Minuten warten, bis der Schlüssel aktiv wird, bevor Sie ihn in AWS Secrets Manager verwenden können. Gehen Sie über die AWS console zu KMS > Customer managed keys.
Erstellen eines KMS, Customer managed key. .png
Erstellen eines benutzerdefinierten Secrets in AWS Secrets Manager.
Stellen Sie sicher, dass Sie nach dem Erstellen Ihres KMS Customer managed key etwa 10 Minuten gewartet haben. Erstellen Sie nun ein neues AWS Secrets Manager-Secret. Über die AWS console.
Wählen Sie einen anderen Secret-Typ für den Secret-Typ.
Schalten Sie den Key/value pairs-Editor auf Plaintext um. Geben Sie JSON mit Schlüsseln ein, die exakt „username“ und „password“ entsprechen.
Der Name des Secrets muss mit AmazonMSK_ beginnen.
Der Verschlüsselungsschlüssel muss ein KMS customer-managed key sein, kein AWS-managed key.
Ein benutzerdefiniertes Secret im AWS Secrets Manager erstellen. .png
Eine MSK-Instanz erstellen
Verwenden Sie als Nächstes die AWS-Konsole, um einen Amazon MSK-Cluster mit aktivierter Kafka-autoCreateTopics-Funktion und SASL/SCRAM-Sicherheit zu erstellen.
Überlegungen beim Erstellen von MSK:
Die neueste stabile Version von Milvus (v2.4.x) hängt von der autoCreateTopics-Funktion von Kafka ab. Daher muss beim Erstellen von MSK eine benutzerdefinierte Konfiguration verwendet werden, und die Eigenschaft auto.create.topics.enable muss vom Standardwert false auf true geändert werden.
Darüber hinaus wird empfohlen, die Werte von message.max.bytes und replica.fetch.max.bytes zu erhöhen, um den Nachrichtendurchsatz von MSK zu steigern.
auto.create.topics.enable=true
message.max.bytes=10485880
replica.fetch.max.bytes=20971760
Weitere Details finden Sie unter Benutzerdefinierte MSK-Konfigurationen.
Eine MSK-Instanz erstellen.png
Milvus unterstützt keine IAM-Rollen-basierte Authentifizierung für MSK. Aktivieren Sie daher beim Erstellen von MSK die SASL/SCRAM-Authentifizierungsoption in der Sicherheitskonfiguration und konfigurieren Sie den Benutzernamen und das Passwort in AWS Secrets Manager. Weitere Details finden Sie unter Authentifizierung mit Anmeldeinformationen über AWS Secrets Manager.
Die Sicherheitsgruppe für MSK muss den Zugriff von der Sicherheitsgruppe oder dem IP-Adressbereich des EKS-Clusters erlauben.
Sicherheitseinstellungen
Warten Sie ca. 15 Minuten, bis die MSK-Instanz bereitgestellt ist. Sobald sie bereit ist, klicken Sie darauf, und Sie können das zuvor erstellte benutzerdefinierte AWS Secrets Manager-Secret zuordnen.
AWS Secrets Manager
Einen Amazon EKS-Cluster erstellen
Es gibt viele Möglichkeiten, einen EKS-Cluster zu erstellen, z. B. über die Konsole, CloudFormation oder eksctl. Lesen Sie das Dokument Einrichten der Verwendung von Amazon EKS.
Dieser Beitrag verwendet eksctl. eksctl ist ein einfaches Befehlszeilentool zum Erstellen und Verwalten von Kubernetes-Clustern auf Amazon EKS. eksctl bietet die schnellste und einfachste Möglichkeit, einen neuen Cluster mit Knoten für Amazon EKS zu erstellen. Weitere Informationen finden Sie in der offiziellen Dokumentation von eksctl.
Schritt 1: Erstellen Sie eine eks_cluster.yaml-Datei.
Ein Beispiel für eine .yaml-Datei finden Sie in der Milvus-Dokumentation.
Ersetzen Sie den Clusternamen durch Ihren Clusternamen,
Ersetzen Sie region-code durch die AWS-Region, in der Sie den Cluster erstellen möchten.
Ersetzen Sie private-subnet-idx durch Ihre privaten Subnetze. Hinweis: Diese Konfigurationsdatei erstellt einen EKS-Cluster in einer bestehenden VPC, indem private Subnetze angegeben werden. Sie können auch die VPC- und Subnetz-Konfiguration entfernen, sodass eksctl automatisch eine neue VPC erstellt.
**Schritt 2: Führen Sie den eksctl-Befehl create cluster -f eks_cluster.yaml aus, um den EKS-Cluster zu erstellen. **
create cluster -f eks_cluster.yaml
Siehe Amazon EKS Quickstart. Dieser Befehl erstellt die folgenden Ressourcen:
Einen EKS-Cluster mit der angegebenen Version.
Eine verwaltete Knotengruppe mit 3 m6i.2xlarge EC2-Instanzen.
Ein IAM OIDC-Identitätsanbieter und ein ServiceAccount namens aws-load-balancer-controller werden später bei der Installation des AWS Load Balancer Controller verwendet.
Ein Namespace milvus und ein ServiceAccount milvus-s3-access-sa innerhalb dieses Namespace. Dies wird später verwendet, wenn S3 als Objektspeicher für Milvus konfiguriert wird.
Hinweis: Der Einfachheit halber erhält milvus-s3-access-sa vollständige S3-Zugriffsberechtigungen. In Produktionsbereitstellungen wird empfohlen, dem Prinzip der geringsten Rechte zu folgen und nur Zugriff auf den spezifischen S3-Bucket zu gewähren, der für Milvus verwendet wird.
- Mehrere Add-ons, wobei vpc-cni, coredns, kube-proxy Kern-Add-ons sind, die von EKS benötigt werden. aws-ebs-csi-driver ist der AWS EBS CSI-Treiber, der EKS-Clustern ermöglicht, den Lebenszyklus von Amazon EBS-Volumes zu verwalten.
% 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
…
Warten Sie, bis die Cluster-Erstellung abgeschlossen ist. Nach Abschluss sollten Sie eine Antwort wie die folgende Ausgabe sehen:
% EKS cluster "MilvusEKSTest" in "us-west-2" region is ready
Sobald der Cluster erstellt wurde, können Sie die Knoten anzeigen, indem Sie Folgendes ausführen:
% 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
Schritt 3: Erstellen Sie eine ebs-sc StorageClass, die mit GP3 als Speichertyp konfiguriert ist, und legen Sie sie als standardmäßige StorageClass fest.
Milvus verwendet etcd als Meta Storage und benötigt diese StorageClass, um PVCs zu erstellen und zu verwalten.
- Führen Sie diesen cat-Befehl aus.
% 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
- Führen Sie nach der Erstellung einen Patch-Befehl aus, um diese StorageClass zur Standardklasse zu machen.
% kubectl patch storageclass gp2 -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
storageclass.storage.k8s.io/gp2 patched
- Überprüfen Sie, ob die StorageClass korrekt konfiguriert wurde.
% 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
Schritt 4: Installieren Sie den AWS Load Balancer Controller
Dies wird später für den Milvus Service und Attu Ingress verwendet. Siehe die offiziellen EKS Load Balancer Controller-Anweisungen.
Fügen Sie das eks-charts-Repo hinzu und aktualisieren Sie es.
% 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!⎈
Installieren Sie den AWS Load Balancer Controller. Ersetzen Sie cluster-name durch Ihren Clusternamen. Das ServiceAccount namens aws-load-balancer-controller wurde bereits erstellt, als der EKS-Cluster erstellt wurde.
% 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!
Überprüfen Sie, ob der Controller erfolgreich installiert wurde. Die Ausgabe sollte wie folgt aussehen:
% 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
Bereitstellen eines Milvus-Clusters auf Amazon EKS
Milvus unterstützt mehrere Bereitstellungsmethoden wie Operator und Helm. Die Verwendung von Operator ist einfacher, aber Helm ist direkter und flexibler. Daher verwenden wir Helm für die Bereitstellung.
Sie können die Konfiguration über die Werte anpassen, wenn Sie Milvus mit der Datei milvus_helm.yaml bereitstellen.
Standardmäßig erstellt Milvus in-cluster minio und pulsar als Object Storage bzw. Message Storage. Wir werden einige Konfigurationsänderungen vornehmen, um es besser für die Produktion geeignet zu machen.
Schritt 1: Fügen Sie das Milvus-Helm-Repo hinzu und aktualisieren Sie es.
% 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!⎈
Schritt 2: Erstellen Sie eine milvus_cluster.yaml-Datei.
Der folgende Code passt die Installation von Milvus an, z. B. die Konfiguration von Amazon S3 als Objektspeicher, Amazon MSK als Nachrichtenwarteschlange usw. Wir stellen nach dem Codeblock detaillierte Erklärungen und Konfigurationsanleitungen bereit.
#####################################
# 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
# Externes kafka
# - diese Konfigurationen werden nur verwendet, wenn `externalKafka.enabled` true ist
externalKafka:
enabled: true
brokerList: "<broker-list>"
securityProtocol: SASL_SSL
sasl:
mechanisms: SCRAM-SHA-512
username: "<username>"
password: "<password>"
#####################################
# Abschnitt 3
#
# Den Milvus-Dienst verfügbar machen, damit von außerhalb des Clusters darauf zugegriffen werden kann (LoadBalancer-Dienst).
# oder innerhalb des Clusters darauf zugreifen (ClusterIP-Dienst). Legen Sie den Diensttyp und den Port fest, über den er bereitgestellt werden soll.
#####################################
service:
type: LoadBalancer
port: 19530
annotations:
service.beta.kubernetes.io/aws-load-balancer-type: external #AWS Load Balancer Controller erfüllt Dienste, die diese Annotation haben
service.beta.kubernetes.io/aws-load-balancer-name : milvus-service #Benutzerdefinierter Name, der dem AWS Network Load Balancer gegeben wird
#service.beta.kubernetes.io/aws-load-balancer-scheme: internal # intern oder internet-facing, was später öffentlichen Zugriff über das Internet ermöglicht
service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing" #Platziert den Load Balancer in öffentlichen Subnetzen
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip #Die Pod-IPs sollten als Ziel-IPs verwendet werden (anstatt der Node-IPs)
#####################################
# Abschnitt 4
#
# Installation von Attu, der Milvus-Verwaltungs-GUI
#####################################
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
#####################################
# Abschnitt 5
#
# HA-Bereitstellung der Milvus-Kernkomponenten
#####################################
rootCoordinator:
replicas: 2
activeStandby:
enabled: true # Aktiv-Passiv aktivieren, wenn Sie mehrere Replikate für den Root-Koordinator festlegen
resources:
limits:
cpu: 1
memory: 2Gi
indexCoordinator:
replicas: 2
activeStandby:
enabled: true # Aktiv-Passiv aktivieren, wenn Sie mehrere Replikate für den Index-Koordinator festlegen
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
queryCoordinator:
replicas: 2
activeStandby:
enabled: true # Aktiv-Passiv aktivieren, wenn Sie mehrere Replikate für den Query-Koordinator festlegen
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
dataCoordinator:
replicas: 2
activeStandby:
enabled: true # Aktiv-Passiv aktivieren, wenn Sie mehrere Replikate für den Data-Koordinator festlegen
resources:
limits:
cpu: "0.5"
memory: 0.5Gi
proxy:
replicas: 2
resources:
limits:
cpu: 1
memory: 4Gi
#####################################
# Abschnitt 6
#
# Milvus-Ressourcenzuweisung
#####################################
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
Der Code ist in sechs Abschnitte unterteilt. Befolgen Sie die folgenden Anweisungen, um die entsprechenden Konfigurationen zu ändern.
Abschnitt 1: Konfigurieren Sie S3 als Objektspeicher. serviceAccount gewährt Milvus Zugriff auf S3 (hier ist es milvus-s3-access-sa, das bereits beim Erstellen des EKS-Clusters erstellt wurde).
Ersetzen Sie <region-code> durch die AWS-Region, in der Sie den Cluster erstellt haben.
Ersetzen Sie <bucket-name> durch den Namen des S3-Buckets und <root-path> durch das Präfix des S3-Buckets (kann leer sein).
Abschnitt 2: Konfigurieren Sie MSK als Nachrichtenspeicher.
- Ersetzen Sie <broker-list> durch den MSK-Endpunkt für den Authentifizierungstyp SASL/SCRAM,
und durch den MSK-Benutzernamen und das MSK-Passwort. Sie können <broker-list> aus den MSK-Clientinformationen erhalten, wie im Bild gezeigt.
- Ersetzen Sie <broker-list> durch den MSK-Endpunkt für den Authentifizierungstyp SASL/SCRAM,
view client information.jpg
Abschnitt 3: Dieser Abschnitt stellt den Milvus-Service-Endpunkt bereit, damit von außerhalb des Clusters darauf zugegriffen werden kann. Standardmäßig verwendet der Milvus-Endpunkt den Servicetyp ClusterIP, der nur innerhalb des EKS-Clusters zugänglich ist. Sie können ihn bei Bedarf in den Typ LoadBalancer ändern, um den Zugriff von außerhalb des EKS-Clusters zu ermöglichen. Der Service vom Typ LoadBalancer verwendet Amazon NLB als Load Balancer.
Gemäß den Best Practices für Sicherheit ist aws-load-balancer-scheme hier standardmäßig als interner Modus konfiguriert, was bedeutet, dass nur Intranet-Zugriff auf Milvus erlaubt ist. Wenn Sie Internetzugriff auf Milvus benötigen, müssen Sie internal in internet-facing ändern. Klicken Sie hier, um die NLB-Konfigurationsanweisungen anzuzeigen.
- Ändern Sie die Zeile in:
aws-load-balancer-scheme: internet-facing
- Ändern Sie die Zeile in:
# service.beta.kubernetes.io/aws-load-balancer-scheme: internal
service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
Abschnitt 4: Installieren und konfigurieren Sie Attu, ein Open-Source-Tool zur Milvus-Administration. Es verfügt über eine intuitive GUI, mit der Sie einfach mit der Datenbank interagieren können. Wir aktivieren Attu, konfigurieren Ingress mit AWS ALB und setzen es auf den Typ internet-facing, damit über das Internet auf Attu zugegriffen werden kann.
- Klicken Sie hier für die Anleitung zur ALB-Konfiguration.
Abschnitt 5: Aktivieren Sie die HA-Bereitstellung der Milvus-Kernkomponenten. Gemäß der Architektur wissen wir bereits, dass Milvus mehrere unabhängige und entkoppelte Komponenten enthält. Beispielsweise fungiert der Koordinator-Service als Steuerungsebene und übernimmt die Koordination für Root-, Query-, Data- und Index-Komponenten. Der Proxy in der Zugriffsebene dient als Datenbankzugriffs-Endpunkt. Diese Komponenten haben standardmäßig nur 1 Pod-Replikat. Um die Verfügbarkeit von Milvus zu verbessern, ist die Bereitstellung mehrerer Replikate dieser Servicekomponenten besonders notwendig.
- Beachten Sie, dass die Root-, Query-, Data- und Index-Koordinator-Komponenten mit mehreren Replikaten und aktivierter activeStandby-Option bereitgestellt werden müssen.
Abschnitt 6: Passen Sie die Ressourcenzuweisung für Milvus-Komponenten an, um die Anforderungen Ihrer Workloads zu erfüllen. Die Milvus-Website stellt außerdem ein Sizing-Tool bereit, um Konfigurationsvorschläge basierend auf Datenvolumen, Vektordimensionen, Indextypen usw. zu generieren. Es kann auch mit einem Klick eine Helm-Konfigurationsdatei generieren.
- Die folgende Konfiguration ist der vom Tool gegebene Vorschlag für 1 Million Vektoren mit 1024 Dimensionen und den HNSW-Indextyp.
Verwenden Sie Helm, um Milvus zu erstellen (bereitgestellt im Namespace milvus).
- Beachten Sie, dass Sie demo-milvus durch einen benutzerdefinierten Namen ersetzen können.
% 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
Führen Sie den folgenden Befehl aus, um den Bereitstellungsstatus zu überprüfen.
% 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
Die obige Ausgabe zeigt, dass alle Milvus-Komponenten AVAILABLE sind und für Koordinationskomponenten mehrere Replikate aktiviert sind.
Zugriff auf und Verwaltung von Milvus-Endpunkten
Bisher haben wir die Milvus-Datenbank erfolgreich bereitgestellt. Jetzt können wir über Endpunkte auf Milvus zugreifen. Milvus stellt Endpunkte über Kubernetes-Services bereit. Attu stellt Endpunkte über Kubernetes Ingress bereit.
Zugriff auf Milvus-Endpunkte über Kubernetes-Services
Führen Sie den folgenden Befehl aus, um Service-Endpunkte abzurufen:
% 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
Sie können mehrere Services sehen. Milvus unterstützt zwei Ports, Port 19530 und Port 9091:
Port 19530 ist für gRPC und die RESTful API vorgesehen. Er ist der Standardport, wenn Sie mit verschiedenen Milvus SDKs oder HTTP-Clients eine Verbindung zu einem Milvus-Server herstellen.
Port 9091 ist ein Verwaltungsport für die Erfassung von Metriken, pprof-Profiling und Health Probes innerhalb von Kubernetes.
Darunter stellt der Service demo-milvus einen Datenbankzugriffs-Endpunkt bereit, der zum Herstellen einer Verbindung mit Clients verwendet wird. Auf den Datenbank-Endpunkt wird über den NLB als Service-Load-Balancer zugegriffen. Sie können den NLB-Service-Endpunkt aus der Spalte EXTERNAL-IP abrufen.
Notieren Sie sich die Spalte NLB EXTERNAL-IP, die in diesem Fall lautet:
milvus-nlb-xxxx.elb.us-west-2.amazonaws.com 19530:31201/TCP,9091:31088/TCP
Zugriff auf Milvus-Endpunkte mit Attu
Als wir Milvus installiert haben, haben wir auch Attu installiert, ein Admin-Tool zur Verwaltung von Milvus. Führen Sie den folgenden Befehl aus, um den Endpunkt abzurufen:
% 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
Sie sollten einen Ingress namens demo-milvus-attu sehen, wobei die Spalte ADDRESS die externe URL ist.
Öffnen Sie die Ingress-Adresse in einem Browser und sehen Sie die folgende Seite.
Klicken Sie auf Connect, um sich anzumelden.
attu-Oberfläche
Nach der Anmeldung können Sie Milvus-Datenbanken verwalten über:
Milvus mit Attu verwalten
Testen der Milvus-Vektordatenbank
Sie können den offiziellen Beispielcode von Milvus verwenden, um zu testen, ob die Milvus-Datenbank ordnungsgemäß funktioniert.
- Schritt 1: Laden Sie den Beispielcode hello_milvus.py direkt herunter.
% wget https://raw.githubusercontent.com/milvus-io/pymilvus/master/examples/hello_milvus.py
- Schritt 2: Ändern Sie den host im Beispielcode auf den Milvus-Kubernetes-Endpunkt, den wir zuvor erhalten haben.
print(fmt.format("start connecting to Milvus"))
connections.connect(
"default",
host="milvus-nlb-xxx.elb.us-west-2.amazonaws.com",
port="19530")
- Schritt 3: Führen Sie den Code aus. Wenn das folgende Ergebnis zurückgegeben wird, läuft Milvus normal.
% 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 ===
Sie haben Milvus nun erfolgreich auf EKS eingerichtet! HERZLICHEN GLÜCKWUNSCH!!!
Fazit
Dieser Beitrag stellte die Open-Source-Vektordatenbank Milvus vor und erklärte, wie sie auf AWS mithilfe verwalteter Dienste wie Amazon EKS, S3, MSK und ELB bereitgestellt wird, um höhere Elastizität und Zuverlässigkeit zu erreichen.
Ressourcen
AWS Milvus EKS Blog: https://aws.amazon.com/cn/blogs/china/build-open-source-vector-database-milvus-based-on-amazon-eks/
Milvus EKS Guide: https://milvus.io/docs/eks.md
Amazon EKS Stup Guide: https://docs.aws.amazon.com/eks/latest/userguide/setting-up.html
Amazon EKS User Guide: https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html
Offizielle Milvus-Website: https://milvus.io/
Milvus Github: https://github.com/milvus-io/milvus
Offizielle eksctl-Website: https://eksctl.io/
YAML-Dateien, die Sie für die Installation benötigen:
eks_cluster.yaml-Datei: https://aws.amazon.com/cn/blogs/china/build-open-source-vector-database-milvus-based-on-amazon-eks/
milvus_helm.yaml-Datei: https://raw.githubusercontent.com/milvus-io/milvus-helm/master/charts/milvus/values.yaml
milvus_cluster.yaml-Datei: Aus diesem Blog kopieren/einfügen.
Weiterlesen
Why We Built Vector Lakebase: Rethinking Unstructured Data Architecture for AI
Vector Lakebase: a unified, lake-native data foundation for AI workloads — and an answer to what happens after vector databases succeed.
Zilliz Cloud Update: Smarter Autoscaling for Cost Savings, Stronger Compliance with Audit Logs, and More
What's new in Zilliz Cloud? Smarter autoscaling with scale-down, audit logs GA, enhanced SSO, and Milvus 2.6 in Private Preview.
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.