> ## 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.
# Helm-Chart-Werte
> Referenz für die Werte, die von den Helm-Charts `vantage-operator` und `vantage-selfhosted` bereitgestellt werden.
Vantage 3.0 self-hosted wird in Form von zwei Helm-Charts ausgeliefert: `vantage-operator` (der Controller, der die `Vantage` Custom-Resource überwacht) und `vantage-selfhosted` (das Chart, das die `Vantage`-Ressource und die zugehörigen Manifeste im gewählten Installations-Namespace erstellt). Diese Seite enthält die Werte-Referenz für beide.
Weitere CRD-Details auf Feld-Ebene finden Sie in der [API-Referenz](/de/vantage/self-hosted/v3.0/api-reference). Eine Installationsanleitung finden Sie unter [Azure](/de/vantage/self-hosted/v3.0/providers/azure) oder [selbstverwaltetes Kubernetes](/de/vantage/self-hosted/v3.0/providers/self-managed).
Installieren Sie `vantage-operator` und `vantage-selfhosted` in passenden Versionen. Das aktuelle Verfahren für Self-Managed Kubernetes verwendet für beide Charts die Version `0.70.13`.
## `vantage-operator`
Wird einmal pro Cluster in einem Namespace Ihrer Wahl installiert. Der Operator reconciliiert die durch die `Vantage`-Custom-Resource definierte Vantage-Installation.
**Installieren Sie genau eine Instanz pro Cluster.** Das Chart verwendet clusterweite, nicht templatisierte Ressourcennamen (`manager-role` ClusterRole, `manager-rolebinding` ClusterRoleBinding, `controller-manager` ServiceAccount). Eine zweite Installation im selben Cluster (auch in einem anderen Namespace) führt zu Konflikten mit diesen Ressourcen. Siehe [Bekannte Einschränkungen](/de/vantage/self-hosted/v3.0/known-limitations#one-operator-instance-per-cluster).
### Abschnitte der obersten Ebene
* **`nameOverride` / `fullnameOverride`**: überschreiben den generierten Präfix des Ressourcennamens teilweise oder vollständig.
* **`manager`**: das Operator-Deployment: `replicas`, `image`, Container-`args` (Leader Election ist standardmäßig aktiviert), `env` (Pod-Name und Namespace über die Downward API), `imagePullSecrets`, Sicherheitskontexte für Pod und Container (non-root, keine Privilegieneskalation, schreibgeschütztes Root-Dateisystem), `resources` und Scheduling (`affinity`, `nodeSelector`, `tolerations`).
* **`rbacHelpers`**: optionale Administrator-, Editor- und Viewer-ClusterRoles für die Arbeit mit den `vantage.abbyy.com`-CRDs. Standardmäßig deaktiviert.
* **`crd`**: CRD-Lebenszyklus: Installation der CRDs mit dem chart (`enable`) und Beibehaltung bei der Deinstallation (`keep`).
* **`metrics`**: der durch RBAC geschützte `/metrics`-Endpunkt.
* **`certManager`**: cert-manager-Integration für Zertifikate für Webhook und Metrics-Endpunkt. Standardmäßig deaktiviert.
* **`prometheus`**: ein Prometheus-`ServiceMonitor` für den Metrics-Endpunkt. Erfordert den prometheus-operator im Cluster. Standardmäßig deaktiviert.
### Wichtige Werte
Die Standardwerte entsprechen der für dieses Release generierten `values.yaml` des Charts. Maßgeblich ist das Chart selbst; siehe [Verfügbare Werte prüfen](#inspecting-available-values).
| Wert | Zweck |
| ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `manager.replicas` | Anzahl der Operator-Replikas. Standard `1`. |
| `manager.image.repository` / `tag` / `pullPolicy` | Container-Image des Operators. `pullPolicy` ist standardmäßig `IfNotPresent`. |
| `manager.imagePullSecrets` | Pull-Secrets für das Operator-Image, wenn Ihre Registry eine Authentifizierung erfordert, zum Beispiel `--set "manager.imagePullSecrets[0].name=my-pull-secret"`. Standard `[]`. Unter AKS nicht erforderlich, wenn `AcrPull` der kubelet-Identität zugewiesen wurde. Siehe [Image-Pull-Zugriff](/de/vantage/self-hosted/v3.0/providers/azure#image-pull-access). |
| `manager.args` | Container-Argumente. Standard `[--leader-elect]` (Leader Election aktiviert). |
| `manager.resources` | CPU-/Speicher-Requests und -Limits. Standardwerte: Requests `10m` CPU / `64Mi` Speicher, Limits `500m` CPU / `128Mi` Speicher. |
| `manager.affinity` / `manager.nodeSelector` / `manager.tolerations` | Standardmäßige Kubernetes-Steuerungen für das Scheduling des Operator-Pods. Standardmäßig leer. |
| `rbacHelpers.enable` | Installiert praktische Admin-, Editor- und Viewer-Rollen für die `vantage.abbyy.com`-CRDs. Standard `false`. |
| `crd.enable` | Installiert die CRDs mit dem Chart. Standard `true`. |
| `crd.keep` | Behält die CRDs (und die von ihnen definierten `Vantage`-Ressourcen) im Cluster bei, wenn das Chart deinstalliert wird. Standard `true`. |
| `metrics.enable` / `metrics.port` | Stellt den RBAC-geschützten `/metrics`-Endpunkt bereit. Standardwerte `true` / `8443`. |
| `certManager.enable` | Verwendet cert-manager für Zertifikate für den Webhook und den Metrics-Endpunkt. Standard `false`. |
| `prometheus.enable` | Erstellt einen Prometheus-`ServiceMonitor` für den Metrics-Endpunkt. Erfordert den prometheus-operator im Cluster. Standard `false`. |
Das Operator-Chart akzeptiert **keine** Vantage-Anwendungskonfiguration. Die Anwendungskonfiguration befindet sich vollständig in der `Vantage` Custom-Resource, die vom Chart `vantage-selfhosted` erstellt wird.
## `vantage-selfhosted`
Wird einmal pro Vantage-Instanz in einem Namespace Ihrer Wahl installiert. Dieses Chart enthält die `Vantage`-Custom-Resource, eine ConfigMap mit den Vantage-Workload-Daten samt zugehörigem RBAC sowie die Vantage-bezogenen CRDs und Rollen aus ABBYYs Upstream-Infrastruktur-Repository.
Die meisten Werte werden direkt den Feldern der `Vantage`-Custom-Resource zugeordnet. Details zu den einzelnen Feldern finden Sie in der [API-Referenz](/de/vantage/self-hosted/v3.0/api-reference).
### Top-Level-Abschnitte
* **`operator`**: Verweis auf die `operator`-Installation (`namespace` und `controllerManagerServiceAccount`). Das Chart verwendet diese Werte, um die Secret-Reader-ClusterRole des Operators im Namespace des Vantage-Release zu binden.
* **`ingress`**: integrierte Istio-`ingress`-Anbindung. Setzen Sie `enabled: false`, wenn Sie einen anderen `ingress`-Controller verwenden.
* **`vantage`**: die `Vantage.spec`-Payload: `databaseProvider`, `dnsRecord`, `mailFrom`, `platformAdminEmail`, `secrets`, `vantageVersion`, `workloads`, `idReadingEnabled`, `keda`, `ociMigration`, `reportingEnabled`, `serviceAccountName`, `smtp`, `storage`, `techcore`.
* **`observability`**: vom Chart gerenderte Prometheus-`ServiceMonitor`-Konfiguration. Dies ist ein Top-Level-Abschnitt, kein `Vantage.spec`-Feld.
### Erforderliche Werte
| Wert | Zuordnung zu | Hinweise |
| ------------------------------------------------------------------------------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `operator.namespace` | N/A | Namespace, in dem Sie `vantage-operator` installiert haben. |
| `operator.controllerManagerServiceAccount` | N/A | ServiceAccount des Operator-Controllers, der in diesem Vantage-Release-Namespace an die Secret-reader-ClusterRole gebunden wird. Ändern Sie ihn nur, wenn für die Operator-Installation ein vom Standard abweichender Name verwendet wird. |
| `ingress.tls.secretName` | N/A | Erforderlich, wenn das integrierte Istio-Ingress aktiviert ist. Name des vorhandenen `kubernetes.io/tls`-Secrets im Namespace des externen Istio-Ingress-Gateways. Wird nicht verwendet, wenn `ingress.enabled` auf `false` gesetzt ist. |
| `vantage.dnsRecord` | `Vantage.spec.dnsRecord` | DNS-Hostname, unter dem Vantage erreichbar ist. |
| `vantage.mailFrom` | `Vantage.spec.mailFrom` | Absender für ausgehende E-Mails. |
| `vantage.platformAdminEmail` | `Vantage.spec.platformAdminEmail` | Erster Plattformadministrator. |
| `vantage.secrets.azure` oder `vantage.secrets.kubernetes` | `Vantage.spec.secrets` | Genau ein Secrets-Provider ist erforderlich. Siehe [Secrets and Key Vault](/de/vantage/self-hosted/v3.0/secrets-and-keyvault). |
| `vantage.workloads.configMap` / `metadataTemplateKey` / `secretsKey` / `workloadsKey` | `Vantage.spec.workloads` | Verweist auf die `ConfigMap`, die die Workload-Daten enthält. Das Chart selbst liefert und erstellt diese ConfigMap. |
### Optionale Werte
| Wert | Zweck |
| ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ingress.enabled` | Aktiviert den integrierten Ingress des Charts. Setzen Sie den Wert auf `false`, wenn Sie Traefik oder einen anderen kundenseitig verwalteten Ingress-Controller verwenden. Standardwert: `true`. |
| `vantage.databaseProvider` | Datenbank-Engine für Vantage-Services. Zulässige Werte: `SqlServer` (Standard) oder `PostgreSQL`; Groß-/Kleinschreibung wird beachtet. |
| `vantage.secrets.azure.identityMode` | Einer der folgenden Werte: `workloadIdentity` (Standard), `podIdentity`, `vmManagedIdentity`. Siehe [Secrets and Key Vault](/de/vantage/self-hosted/v3.0/secrets-and-keyvault#azure-key-vault-provider). |
| `vantage.secrets.azure.userAssignedIdentityID` | Client ID der UAMI, die verwendet werden soll, wenn `identityMode` auf `vmManagedIdentity` gesetzt ist. |
| `vantage.secrets.azure.objects` | Zuordnung von Secret-Aliasen zu `{objectName, objectType, objectVersion}` für Key Vault-Objekte, deren Namen nicht mit dem Alias übereinstimmen. |
| `vantage.secrets.kubernetes` | Verwendet vorhandene Kubernetes-`Secret`-Ressourcen anstelle von Azure Key Vault. Eine optionale `objects`-Zuordnung überschreibt die Standardnamen der Secrets. |
| `vantage.smtp.host` / `port` / `login` / `password` | Ausgehendes SMTP. Wird nur verwendet, wenn gesetzt; SendGrid ist der Standard. Entspricht `Vantage.spec.smtp`. |
| `vantage.serviceAccountName` | Standard-`ServiceAccount` für Vantage-Workloads. Entspricht `Vantage.spec.serviceAccountName`. Standardwert: `default`. Um Images mit einem Pull-Secret abzurufen, fügen Sie das Secret zu `imagePullSecrets` dieses `ServiceAccount` hinzu. Siehe [Azure image pull access](/de/vantage/self-hosted/v3.0/providers/azure#image-pull-access) oder [self-managed registry access](/de/vantage/self-hosted/v3.0/providers/self-managed#configure-registry-access). |
| `vantage.storage.custom.storageClass` / `size` | Verwendet ein Kubernetes-`StorageClass`-basiertes Backend anstelle von Azure Blob. Entspricht `Vantage.spec.storage.custom`. |
| `vantage.idReadingEnabled` | Aktiviert oder deaktiviert ID-Erkennungsfunktionen. Standardwert: `false`. |
| `vantage.reportingEnabled` | Aktiviert oder deaktiviert SQL Server-Reporting-Funktionen. Standardwert: `false`. Bei PostgreSQL muss der Wert `false` bleiben. |
| `vantage.ociMigration.enabled` | Führt den OCI-Migrationsjob aus. Standardwert: `true`. |
| `vantage.ociMigration.serviceAccountName` | `ServiceAccount`, unter dem der OCI-Migrationsjob ausgeführt wird. Entspricht `Vantage.spec.ociMigration.serviceAccountName`. Um das Job-Image mit einem Pull-Secret abzurufen, fügen Sie das Secret zu `imagePullSecrets` dieses `ServiceAccount` hinzu. |
| `vantage.ociMigration.sources[]` | Quell-Registries, aus denen Artefakte kopiert werden. Die dokumentierte Quelle ist `sources[0].host=abbyy.jfrog.io` und `sources[0].repository=abbyy-docker`. Setzen Sie `sources[].credentialsRef.name` auf ein Secret mit Registry-Anmeldedaten; dies ist die Alternative zu einem `ServiceAccount` des Migrationsjobs für die Pull-Konfiguration. |
| `vantage.ociMigration.destination.host` / `repository` | Ziel-Registry, in die Artefakte kopiert werden. |
| `vantage.keda.enabled` | Konfiguriert, ob [KEDA](https://keda.sh/) für die automatische Skalierung von Vantage-Workloads verwendet wird. Die aktuellen Vantage-Workload-Charts erfordern KEDA 2.17.x. Siehe [Autoscaling with KEDA](/de/vantage/self-hosted/v3.0/performance/autoscaling). |
| `observability.prometheus.namespace` | Namespace, der Prometheus enthält. Standardwert: `observability`. Einige Vantage-Autoscaler benötigen den `prometheus-operated`-Service in diesem Namespace. |
| `observability.prometheus.serviceMonitor.create` | Erstellt den `ServiceMonitor`, der die Vantage-`/metrics-text`-Endpoints abruft. Standardwert: `false`. |
| `observability.prometheus.serviceMonitor.selectorMatchLabels` | Labels, die erforderlich sind, damit Ihre Prometheus-Instanz den Vantage-`ServiceMonitor` auswählt. Standardwert: `{}`. |
| `vantage.techcore.versions` | Version(en) der TechCore-Engine. |
| `vantage.techcore.nnTrainingWorkers.enabled` / `gpu` | Worker für das Training neuronaler Netze. |
## Verfügbare Werte prüfen
Das `vantage-operator`-Chart einschließlich seiner `values.yaml` wird vom Kubebuilder-Helm-Plugin generiert; die Templates des `vantage-selfhosted`-Charts werden manuell gepflegt. In beiden Fällen ist das veröffentlichte Chart die maßgebliche Referenz dafür, welche Werte eine bestimmte Version akzeptiert. Die Tabellen auf dieser Seite fassen einen getesteten Snapshot zusammen; wenn diese Seite und das Chart einander widersprechen, verlassen Sie sich auf das Chart:
```bash theme={null}
# vantage-operator
helm show values $charts_uri/vantage-operator --version $operator_version
# vantage-selfhosted
helm show values $chart_uri/vantage-selfhosted --version $selfhosted_version
```
`$charts_uri`, `$chart_uri` und die Versionsvariablen entsprechen den Konventionen unter [Installationsvariablen](/de/vantage/self-hosted/v3.0/providers/azure#install-variables).
So prüfen Sie die gerenderten Manifeste, bevor Sie sie anwenden:
```bash theme={null}
helm template $release_name $chart_uri/vantage-selfhosted \
--version $selfhosted_version \
--namespace $install_namespace \
-f my-values.yaml
```
## Operator vs. Vantage-Konfiguration
Die Konfiguration ist klar aufgeteilt:
| Aspekt | Gehört zu | Begründung |
| ------------------------------------------------------------------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------- |
| Operator-Laufzeit (replicas, image, pull secrets, scheduling, CRD lifecycle, metrics) | `vantage-operator` Helm-Werte | Betriebseinstellungen für Cluster-Administratoren. |
| Vantage-Anwendung (secrets, SMTP, workloads, storage, techcore) | `vantage-selfhosted` Helm-Werte → `Vantage.spec` | Die CRD ist der API-Vertrag; das Chart ist nur die Art und Weise, wie Sie ihn definieren. |
## TechCore-Worker-Bereitstellung
Das `vantage-selfhosted`-Chart wendet eine `Vantage`-Custom-Resource an; der Operator stellt dann anhand von `spec.techcore.*` eine Teilmenge der TechCore-Worker-Charts bereit. Die Auswahl erfolgt im Operator, aber die folgende Matrix ist die verbindliche Grundlage; verwenden Sie sie, um vorherzusagen, welche Worker bei einer bestimmten Konfiguration ausgeführt werden.
### Namenskonvention
Worker-Charts haben das Format `vtc-{version}-worker-{name}`, wobei `{version}` aus `spec.techcore.version` und `{previousVersion}` aus `spec.techcore.previousVersion` stammt. Die Versionsnummern sind reine Namenspräfixe; für den Operator haben sie keine semantische Bedeutung. Die verfügbaren Worker stammen aus der Workloads-ConfigMap, die ABBYY mit jedem Release veröffentlicht.
### Zwei Deployment-Durchläufe
| Durchlauf | Wann er ausgeführt wird | Berücksichtigte Charts |
| ----------------- | ---------------------------------------------- | ------------------------------- |
| Aktuelle Version | Immer | `vtc-{version}-worker*` |
| Vorherige Version | Wenn `spec.techcore.keepPreviousVersion: true` | `vtc-{previousVersion}-worker*` |
Mit `keepPreviousVersion: true` laufen die Worker der vorherigen TechCore-Version parallel zu den neuen weiter, was für gestaffelte TechCore-Upgrades nützlich ist. Die CRD erfordert, dass `previousVersion` gesetzt ist, wenn dieses Flag aktiviert ist.
### Einschlussmatrix: aktueller Versionsdurchlauf
| Chart-Muster | Enthalten, wenn |
| ---------------------------- | -------------------------------------------------------------------- |
| `worker-id-reading` | Nie (in allen Konfigurationen ausgeschlossen) |
| `nn-extraction-training` | `nnTrainingWorkers.enabled: true` und `nnTrainingWorkers.gpu: false` |
| `nn-extraction-training-gpu` | `nnTrainingWorkers.enabled: true` und `nnTrainingWorkers.gpu: true` |
| `nn-nlp-model-train` | `nnTrainingWorkers.enabled: true` und `nnTrainingWorkers.gpu: false` |
| `nn-nlp-model-train-gpu` | `nnTrainingWorkers.enabled: true` und `nnTrainingWorkers.gpu: true` |
| Alle übrigen Worker | Immer |
### Inklusionsmatrix: Durchgang der vorherigen Version
Wird nur ausgeführt, wenn `spec.techcore.keepPreviousVersion: true`.
| Chart-Muster | Enthalten, wenn |
| --------------------------------------- | ----------------------------------------------------- |
| `worker-id-reading` | Nie |
| `nn-extraction-training*` (CPU und GPU) | Nie (NN-Training läuft nur auf der aktuellen Version) |
| `nn-nlp-model-train*` (CPU und GPU) | Nie (NN-Training läuft nur auf der aktuellen Version) |
| Alle anderen Worker | Immer |
Die ID-Erkennung betrifft die Plattformebene, nicht TechCore. Das Flag, das dies steuert, ist `spec.idReadingEnabled` und befindet sich außerhalb von `spec.techcore`. Siehe die [`Vantage.spec`-Referenz](/de/vantage/self-hosted/v3.0/api-reference#vantagespec).
Die Matrix entscheidet nur darüber, was innerhalb der Worker einbezogen wird, die in der Workloads-ConfigMap für die ausgewählte Version vorhanden sind. Charts, die in den Workloads dieser Version nicht enthalten sind, können einfach nicht bereitgestellt werden. Zum Beispiel ist `worker-ocr-join` derzeit nur im Workload-Set von `vtc-2` enthalten, daher wird es selbst mit `keepPreviousVersion: true` und `previousVersion: 2` nur als `vtc-2-worker-ocr-join` bereitgestellt.
## Was kommt als Nächstes
Eine Feld-für-Feld-Referenz für die `Vantage` Custom-Resource.
Die Schritt-für-Schritt-Installation mit diesen Charts.
Installation mit vom Kunden verwaltetem Ingress, Mesh, Secrets, Speicher und Datendiensten.