> ## Documentation Index > Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt > Use this file to discover all available pages before exploring further. # Voraussetzungen > Infrastruktur, die vor der Installation von Vantage 3.0 selbstgehostet eingerichtet sein muss. 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](/de/vantage/self-hosted/v3.0/providers/azure) oder [selbstverwaltetes Kubernetes](/de/vantage/self-hosted/v3.0/providers/self-managed). **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](/de/vantage/self-hosted/v3.0/compatibility#supported-kubernetes-versions). | | ArgoCD | `>= 2.6.0` | v3.3.2 auf AKS; v3.4.3 auf selbstverwaltetem Kubernetes | Die Funktion [ApplicationSet Progressive Syncs](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#enabling-progressive-syncs) muss aktiviert sein. ArgoCD benötigt außerdem eine [Repository-Verbindung](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/) 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](/de/vantage/self-hosted/v3.0/compatibility) 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](/de/vantage/self-hosted/v3.0/providers/self-managed#configure-ingress-and-tls) 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 ABBYY-Quell-Registry (`abbyy.jfrog.io`, Repository `abbyy-docker`) dorthin. 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](/de/vantage/self-hosted/v3.0/providers/azure#image-pull-access). | | [KEDA](https://keda.sh/) 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](/de/vantage/self-hosted/v3.0/performance/autoscaling). |
### KEDA-Unterstützung
Einige Vantage-KEDA-`ScaledObject`-Ressourcen sind auf eine [Prometheus](https://prometheus.io/)-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](/de/vantage/self-hosted/v3.0/performance/autoscaling) und zur Metrik-Verarbeitungspipeline unter [Monitoring](/de/vantage/self-hosted/v3.0/monitoring/overview).
### 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: ```yaml theme={null} - key: k8s.abbyy.com/techcore operator: Equal value: training effect: NoSchedule ``` 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](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/).
## Externe Dienste
Stellen Sie diese vor der Installation bereit. Konkrete getestete Produkte sind unter [Kompatibilität](/de/vantage/self-hosted/v3.0/compatibility) aufgeführt. | Service | Hinweise | | ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Datenbankserver** | SQL Server oder PostgreSQL. Vantage benötigt pro Connection-String-Alias, der unter [Secrets and Key Vault](/de/vantage/self-hosted/v3.0/secrets-and-keyvault) 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](/de/vantage/self-hosted/v3.0/known-limitations#smtp-supports-basic-auth-only). | | **Objektspeicher** | Die Connection Strings stammen von Ihrem Secrets-Provider. Siehe [Secrets and Key Vault](/de/vantage/self-hosted/v3.0/secrets-and-keyvault). 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. | | **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](/de/vantage/self-hosted/v3.0/secrets-and-keyvault). | † 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
AKS-Voraussetzungen, Einrichtung der Identität und das Installationsverfahren. Eigenes Mesh, Ingress, Secrets, Datendienste und Registry. Unterstützte Kubernetes-Versionen, Distributionen und Versionen der Abhängigkeiten.