Zum Hauptinhalt springen
Auf dieser Seite werden die Voraussetzungen für eine Installation von Vantage 3.0 self-hosted beschrieben. Alles, was auf dieser Seite aufgeführt ist, stellen Sie in Ihrer eigenen Subscription und Ihrem eigenen Cluster bereit; diese Seite beschreibt, was erstellt werden muss, nicht die Tools, mit denen es erstellt wird. Eine vollständige Anleitung finden Sie unter Azure oder selbstverwaltetes Kubernetes.
Vantage 3.0 verwendet ein anderes Bereitstellungsmodell als 2.7 und frühere Versionen. Frühere Releases erforderten die von ABBYY exakt spezifizierte Infrastruktur, die mit von ABBYY bereitgestellten Ansible- und Azure-CLI-Skripten erstellt und konfiguriert wurde. Dieses Modell wird in 3.0 nicht unterstützt:
  • Sie stellen Ihre eigene Infrastruktur bereit: den Kubernetes-Cluster, die Datenbanken, die Speicherkonten und den Key Vault. ABBYY stellt für 3.0 keine Bereitstellungsskripte, Vorlagen oder andere Infrastrukturautomatisierung bereit.
  • Das Installationsprogramm stellt nur Vantage Core bereit. Drittanbietersoftware, auf die Vantage angewiesen ist, wie ArgoCD, Ihr Service Mesh und Ihr Ingress-Controller, Ihre Secrets-Integration und Ihr Überwachungs-Stack, wird von Ihnen installiert und gewartet, in der Regel über Helm.
  • Die dokumentierten Konfigurationen sind von ABBYY getestete Szenarien. Sie können Ihre Installation anhand der dokumentierten Beispiele anpassen; die Validierung einer solchen Anpassung liegt in Ihrer Verantwortung.

​
Anforderungen an den Operator

Der Vantage Operator läuft auf Kubernetes und ArgoCD.

​
Anforderungen auf Cluster-Ebene

Diese Services und Komponenten müssen im Cluster vorhanden sein, bevor Sie Vantage installieren. Konkrete getestete Versionen sind unter Kompatibilität aufgeführt.

​
KEDA-Unterstützung

Einige Vantage-KEDA-ScaledObject-Ressourcen sind auf eine Prometheus-Instanz im observability-Namespace angewiesen. Der Prometheus-Service muss unter http://prometheus-operated.observability.svc.cluster.local:9090 erreichbar sein und Vantage-Anwendungsmetriken über den vom Chart erstellten ServiceMonitor abrufen. Informationen zum Trigger-Verhalten und zur Verifizierung finden Sie unter Autoscaling with KEDA und zur Metrik-Verarbeitungspipeline unter Monitoring.

​
Anforderungen an Kubernetes-Knoten

Eine Basisinstallation von Vantage umfasst etwa 100 Pods (bzw. rund 140 als Ausgangsbasis, wenn die KEDA-Unterstützung aktiviert ist). Die AKS-Validierungsumgebung verwendet 12 Standard-8-vCPU-Knoten der B-Familie. Betrachten Sie dies als getestete Installationsbasis, nicht als allgemeingültige Produktionsgröße: Stellen Sie auf selbstverwaltetem Kubernetes eine gleichwertige oder höhere planbare Kapazität bereit und dimensionieren Sie anschließend nach Dokumentvolumen, Parallelität, Verfügbarkeit, Überwachung und Fehlertoleranz.

​
TechCore-Worker-Knoten

Vantage umfasst mehrere Workloads, die als “TechCore-Worker” bezeichnet werden. Diese Workloads übernehmen einen Großteil der eigentlichen Verarbeitung der Anwendung (im Gegensatz zu den Workloads, auf denen UI- und API-Anwendungen ausgeführt werden). Es wird empfohlen, einen Pool von Kubernetes-Knoten speziell für diese Workloads vorzusehen. Fügen Sie dazu der Gruppe von Knoten, auf denen TechCore-Worker-Workloads geplant werden sollen, das Label k8s.abbyy.com/techcore=true hinzu. Segmentieren Sie die TechCore-Worker-Knoten weiter, indem Sie bestimmte Knoten festlegen, auf denen keine trainingsbezogenen Aufgaben ausgeführt werden sollen. Trainingsbezogene Workloads verfügen über die folgende Toleration:
Sie können Knoten, auf denen keine Training-Workloads ausgeführt werden sollen, mit dem Taint k8s.abbyy.com/techcore=training:NoSchedule versehen. Weitere Details zu Taints und Tolerations finden Sie in der offiziellen Kubernetes-Dokumentation.

​
Externe Dienste

Stellen Sie diese vor der Installation bereit. Konkrete getestete Produkte sind unter Kompatibilität aufgeführt. † SendGrid und SMTP schließen sich gegenseitig aus; nur eines von beiden ist erforderlich. ¶ Nur erforderlich, wenn der Azure-Secrets-Provider (vantage.secrets.azure) verwendet wird. Der Kubernetes-Secrets-Provider (vantage.secrets.kubernetes) liest aus bereits vorhandenen Secret-Ressourcen im Installations-Namespace und benötigt weder den CSI-Treiber noch einen Cloud-Key-Vault.

​
Wie geht es weiter

Auf Azure installieren

AKS-Voraussetzungen, Einrichtung der Identität und das Installationsverfahren.

Selbstverwaltetes Kubernetes

Eigenes Mesh, Ingress, Secrets, Datendienste und Registry.

Kompatibilität

Unterstützte Kubernetes-Versionen, Distributionen und Versionen der Abhängigkeiten.