Voraussetzungen - ABBYY Documentation

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.

Komponente	Version	Getestete Version	Hinweise
Kubernetes	Siehe die Matrix der unterstützten Versionen	AKS 1.33.6; selbstverwaltetes Kubernetes 1.36.1	Die vollständige Liste finden Sie unter Kompatibilität.
ArgoCD	`>= 2.6.0`	v3.3.2 auf AKS; v3.4.3 auf selbstverwaltetem Kubernetes	Die Funktion ApplicationSet Progressive Syncs muss aktiviert sein. ArgoCD benötigt außerdem eine Repository-Verbindung zu Ihrer OCI-Registry, damit es die Charts für Vantage-Komponenten abrufen kann.
Helm	`>= 3.0.0`	v4.2.0 auf AKS; v3.21.1 auf selbstverwaltetem Kubernetes	Wird verwendet, um den Operator und die Vantage-Charts zu installieren.

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.

Komponente	Hinweise
Service-Mesh	Istio auf AKS oder Linkerd auf selbstverwaltetem Kubernetes. Das Mesh muss mTLS zwischen Workloads im Vantage-Namespace bereitstellen. Aktivieren Sie vor der Installation von Vantage die entsprechende Namespace-Injektion.
Ingress-Controller	Das Chart enthält einen Istio-Ingress-Pfad. Wenn Sie einen anderen Controller verwenden, deaktivieren Sie den integrierten Ingress und setzen Sie die für Vantage erforderlichen Routing-, Rewrite-, TLS- und Forwarded-Scheme-Anforderungen um, die unter selbstverwaltetes Kubernetes dokumentiert sind.
Secrets Store CSI driver¶	Der Treiber selbst plus das Azure Key Vault Provider-Plugin. Erforderlich, wenn der Azure-Secrets-Provider verwendet wird. Stellt Secrets und Zertifikate aus Ihrem Cloud-Key-Vault zur Laufzeit in Pods bereit.
TLS-Zertifikate	Müssen von einer öffentlichen CA signiert sein. Ein Secret vom Typ `kubernetes.io/tls`, das für Ihren `dnsRecord`-Wert gültig ist und sich im selben Namespace wie das externe Istio-Ingress-Gateway befindet.
OCI-Registry	Ziel-Registry für Vantage-Artefakte. Der Migrationsjob des Operators kopiert Artefakte aus der von ABBYY bereitgestellten Quell-Registry dorthin; den Registry-Host und das Repository erhalten Sie von Ihrem ABBYY Account-Team. Ihre Workloads beziehen Vantage-Images aus dieser Registry: Konfigurieren Sie den Pull-Zugriff mit Kubernetes-Image-Pull-Secrets oder in Azure, indem Sie der von AKS verwalteten Identität `AcrPull` zuweisen. Siehe Image pull access.
KEDA 2.17.3 (optional, empfohlen)	Eine Autoscaling-Komponente. Wenn die KEDA-Unterstützung aktiviert ist, werden die Replikate von Workloads anhand der Systemauslastung automatisch hoch- und herunterskaliert. Die aktuellen Vantage-Workload-Charts erfordern KEDA 2.17.x; verwenden Sie nicht 2.18 oder höher. Siehe Autoscaling with KEDA.

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

Vantage verteilt seine Workloads auf drei Knotenpools: einen Default-Pool für UI-, API- und Platform-Services, einen TechCore-Pool für Worker der Dokumentenverarbeitung und einen Training-Pool für trainingsbezogene Worker. Versehen Sie den TechCore- und den Training-Pool wie unten beschrieben mit Labels und Taints, damit die Verarbeitungsaufgaben vom Rest der Anwendung isoliert sind.

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 und versehen Sie diese Knoten mit folgendem Taint:

- key: k8s.abbyy.com/techcore
  value: "true"
  effect: NoSchedule

Training-Worker-Knoten

Segmentieren Sie die TechCore-Worker-Knoten weiter, indem Sie bestimmte Knoten festlegen, auf denen trainingsbezogene Aufgaben ausgeführt werden sollen. Trainingsbezogene Workloads verfügen über die folgende Toleration:

- key: k8s.abbyy.com/techcore
  operator: Equal
  value: training
  effect: NoSchedule

Versehen Sie die Knoten, auf denen Training-Workloads ausgeführt werden sollen, mit dem Taint k8s.abbyy.com/techcore=training:NoSchedule. Nur trainingsbezogene Workloads tolerieren diesen Taint, sodass keine anderen Vantage-Workloads auf diesen Knoten geplant werden. Weitere Details zu Taints und Tolerations finden Sie in der offiziellen Kubernetes-Dokumentation.

Größen und Anzahl der Kubernetes-Knoten

Anzahl und Größe der Knoten hängen vom Installationsprofil sowie davon ab, welche optionalen Komponenten Sie aktivieren. Im Leitfaden Dimensionierung finden Sie die Anforderungen an CPU, Arbeitsspeicher und Pod-Anzahl pro Knotenpool für minimale und produktive Installationen.

Externe Dienste

Stellen Sie diese vor der Installation bereit. Konkrete getestete Produkte sind unter Kompatibilität aufgeführt.

Service	Hinweise
Datenbankserver	SQL Server oder PostgreSQL. Vantage benötigt pro Connection-String-Alias, der unter Secrets and Key Vault aufgeführt ist, eine eigene logische Datenbank. Die Datenbanken müssen nicht im Voraus vorhanden sein: Der Migrator jedes Service erstellt seine Datenbank beim ersten Start. Die SQL-Server-Datenbank `reporting` muss Columnstore Indexing unterstützen. Reporting ist mit PostgreSQL nicht verfügbar.
Redis	Wird für Cache, Sperren und den Client-Cache verwendet.
SendGrid†	Standard-Mail-Provider. Erforderlich, sofern Sie nicht stattdessen SMTP (`spec.smtp`) konfigurieren. Stellen Sie über Ihren Secrets-Provider einen `sendgridApiKey` bereit.
SMTP-Server†	Optionale Alternative zu SendGrid; wird nur verwendet, wenn `spec.smtp` konfiguriert ist. Unterstützt werden nur Basic Auth oder keine Authentifizierung. Siehe Bekannte Einschränkungen.
Objektspeicher	Die Connection Strings stammen von Ihrem Secrets-Provider. Siehe Secrets and Key Vault. Wenn Sie statt des standardmäßigen Azure Blob ein benutzerdefiniertes Storage-Backend (`spec.storage.custom`) verwenden, muss die referenzierte Kubernetes-`StorageClass` im Cluster konfiguriert sein, bevor Sie Vantage installieren, und die bereitgestellten Volumes müssen für einen Benutzer ohne Root-Rechte beschreibbar sein. Siehe Persistenten Speicher konfigurieren.
Secret-Backend¶	Azure Key Vault bei Verwendung des Azure-Providers. Beim Kubernetes-Provider erstellen Sie native Kubernetes Secrets entweder vorab direkt oder materialisieren sie mit einem Tool wie External Secrets Operator aus Ihrem vorhandenen Secret Store. Siehe Secrets and Key Vault.

† 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.

Dimensionierung

Anforderungen an CPU, Arbeitsspeicher und Pod-Anzahl je Knotenpool.

​Anforderungen an den Operator

​Anforderungen auf Cluster-Ebene

​KEDA-Unterstützung

​Anforderungen an Kubernetes-Knoten

​TechCore-Worker-Knoten

​Training-Worker-Knoten

​Größen und Anzahl der Kubernetes-Knoten

​Externe Dienste

​Wie geht es weiter