> ## 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.
# Architektur
> Wie der Vantage-Kubernetes-Operator, die Vantage-Custom-Resource und ArgoCD zusammenarbeiten, um Vantage 3.0 selbstgehostet zu installieren, zu konfigurieren und zu aktualisieren.
Vantage 3.0 selbstgehostet basiert auf drei Komponenten: einem Kubernetes-Operator, einer einzigen benutzerseitigen Custom-Resource (`Vantage`) und ArgoCD. Sie wenden ein `Vantage`-Objekt an, das die gewünschte Installation beschreibt; der Operator reconciliiert den Installationszustand mit der Ressource und delegiert die komponentenspezifische Synchronisierung an ArgoCD. Auf dieser Seite werden die beteiligten Komponenten konzeptionell erläutert. Ausführliche Informationen auf Feldebene finden Sie in der [API-Referenz](/de/vantage/self-hosted/v3.0/api-reference).
## Warum dieses Vorgehen
Vantage 2.7 selbstgehostet basierte auf von ABBYY bereitgestellten Ansible-Playbooks und Azure-CLI-Skripten, die sowohl die Anwendung als auch die zugrunde liegende Infrastruktur in einem Schritt installierten. Dieses Modell wird in 3.0 nicht unterstützt. Der 3.0-Operator trennt die Zuständigkeiten:
* **Infrastruktur**: wird von Ihnen bereitgestellt und liegt außerhalb des Zuständigkeitsbereichs des Operators. ABBYY stellt für 3.0 keine Automatisierung für die Bereitstellung bereit.
* **Anwendung**: wird deklarativ in der Ressource `Vantage` beschrieben. Der Operator übernimmt die Auflösung von Abhängigkeiten für die Vantage-Core-Komponenten, die Artefaktmigration und den Abgleich über ArgoCD.
Drittanbietersoftware, auf die Vantage angewiesen ist, etwa ArgoCD, Ihr Service Mesh und Ingress-Controller, Ihre Secrets-Integration und Ihr Überwachungs-Stack, fällt ebenfalls außerhalb beider Bereiche: Sie installieren sie selbst, bevor Sie Vantage installieren.
Das Ergebnis: Upgrades werden durchgeführt, indem passende neue Versionen der Helm-Charts `vantage-operator` und `vantage-selfhosted` installiert werden.
## Die `Vantage`-Custom-Resource
Die CRD ist unter `vantage.abbyy.com/v1alpha1` registriert. Eine minimale Ressource sieht folgendermaßen aus (zur Veranschaulichung; siehe die [API-Referenz](/de/vantage/self-hosted/v3.0/api-reference) für die vollständige Spezifikation):
```yaml theme={null}
apiVersion: vantage.abbyy.com/v1alpha1
kind: Vantage
metadata:
name: vantage
namespace: vantage
spec:
dnsRecord: vantage.example.com
mailFrom: noreply@example.com
platformAdminEmail: admin@example.com
vantageVersion: "3.0.x"
secrets:
azure:
keyVaultName: mykeyvault
tenantId: 00000000-...
clientId: 00000000-... # Client-ID der UAMI mit Key Vault-Lesezugriff
identityMode: workloadIdentity # workloadIdentity (Standard) | podIdentity | vmManagedIdentity
smtp:
host: smtp.example.com
port: 587
workloads:
configMap: vantage-workloads
metadataTemplateKey: metadata
secretsKey: secrets
workloadsKey: workloads
```
`spec.secrets` ist erforderlich, und es muss genau ein Provider (`azure` oder `kubernetes`) angegeben werden. `spec.smtp` ist optional; lassen Sie es aus, um den standardmäßigen SendGrid-Mail-Provider zu verwenden (geben Sie einen `sendgridApiKey` über Ihren Secrets-Provider an). Siehe [Secrets und Key Vault](/de/vantage/self-hosted/v3.0/secrets-and-keyvault) für die unterstützten Provider.
In der Praxis konfigurieren Sie das meiste davon über das `vantage-selfhosted` Helm-Chart. Siehe [Azure](/de/vantage/self-hosted/v3.0/providers/azure) oder [selbstverwaltetes Kubernetes](/de/vantage/self-hosted/v3.0/providers/self-managed).
## Grundlegende Konzepte
### Workloads ConfigMap
`spec.workloads` verweist auf eine `ConfigMap`, die das Manifest der Charts und Images enthält, aus denen sich eine Vantage-Version zusammensetzt. Der Operator liest dieses Manifest, führt eine OCI-Migration aus, um Artefakte in Ihre Registry zu kopieren, und generiert anschließend ArgoCD-`Application`-Manifeste für jede Komponente. Die ConfigMap wird von ABBYY im Rahmen jedes Vantage-Release erstellt und veröffentlicht.
### Secrets und Zertifikate
Der Operator speichert Secrets nicht direkt. Es werden zwei Secrets-Provider unterstützt (Azure Key Vault über den Secrets Store CSI driver sowie bereits vorhandene Kubernetes-`Secret`-Ressourcen), und pro Installation ist genau einer konfiguriert. Siehe [Secrets und Key Vault](/de/vantage/self-hosted/v3.0/secrets-and-keyvault) für die unterstützten Provider, Identitätsmodi und die vollständige Alias-Übersicht.
### OCI-Migration
`spec.ociMigration` definiert einen einmaligen Job, der vor der Installation Artefakte aus einer oder mehreren konfigurierten Quell-Registries in Ihre Ziel-Registry kopiert. Sobald die Migration abgeschlossen ist, erfolgt jeder weitere Pull von Komponenten aus Ihrer eigenen Registry. ArgoCD ruft die Komponenten-Charts aus dieser Registry über eine Repository-Verbindung ab, die Sie selbst konfigurieren. Für die Authentifizierung an der Ziel-Registry werden keine Authentifizierung, Basisauthentifizierung oder Azure Workload Identity mit Azure RBAC unterstützt. Workloads benötigen außerdem Pull-Zugriff über Kubernetes-Image-Pull-Secrets oder unter Azure über `AcrPull`, das der verwalteten AKS-Identität zugewiesen ist. Siehe [Azure-Image-Pull-Zugriff](/de/vantage/self-hosted/v3.0/providers/azure#image-pull-access) oder [Zugriff auf die selbstverwaltete Registry](/de/vantage/self-hosted/v3.0/providers/self-managed#configure-registry-access).
### Skill-Installation
Skills werden durch einen separaten Kubernetes-Job im Installations-Namespace installiert, nicht durch eine der vom Operator generierten ArgoCD-Anwendungen. Daher zeigt ArgoCD den Installationsfortschritt der Skills nicht an. Die `Vantage`-Ressource kann den Status `Ready` melden, während der Job noch läuft, und Vantage ist in dieser Zeit bereits nutzbar. Befehle zur Überwachung finden Sie unter [Lebenszyklus](/de/vantage/self-hosted/v3.0/lifecycle#skill-installation-runs-separately).
## Runtime-Vertrag
Der Runtime-Vertrag des Operators (wie er die `Vantage`-Ressource verarbeitet, welche Statusbedingungen er zurückgibt und wie sich ein Retry erzwingen lässt) wird separat von dieser konzeptionellen Übersicht dokumentiert. Siehe [Lebenszyklus](/de/vantage/self-hosted/v3.0/lifecycle).
## Wie geht es weiter
Referenz zu jeder einzelnen Spezifikations- und Statuseigenschaft.
Reconciliierungsphasen, Statusbedingungen und das Erzwingen eines erneuten Versuchs.
Referenz für alle Helm-Werte, die der Operator und die Vantage-Charts akzeptieren.
Häufige Probleme mit Operator, ArgoCD, Secrets, Datenbank, Ingress und Mesh diagnostizieren.