> ## 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-Charts

> Wie die Helm-Charts vantage-operator und vantage-selfhosted zusammenwirken, welche Werte Sie am häufigsten festlegen und wie der Bediener TechCore-Worker bereitstellt.

Vantage 3.0 selbst gehostet 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 zugehörige Manifeste im von Ihnen gewählten Install-Namespace erstellt). Auf dieser Seite werden beide Charts sowie die Werte erläutert, die Sie am häufigsten festlegen.

Details zu den CRD-Feldern finden Sie in der [API-Referenz](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/reference/latest/api-reference.md). Eine Installationsanleitung finden Sie unter [Azure](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/providers/azure.md) oder [Selbstverwaltetes Kubernetes](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/providers/self-managed.md).

> [!NOTE]
>
> Installieren Sie zueinander passende Versionen von `vantage-operator` und `vantage-selfhosted`. Die auf dieser Seite angegebenen Standardwerte beziehen sich auf das neueste Release. Einige Werte sind in früheren Artefaktversionen nicht verfügbar. Alle Werte und Standardwerte eines bestimmten Release finden Sie auf der Seite mit den Helm-Chart-Werten des jeweiligen Release. Ihr Release finden Sie unter [Releases](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/reference/releases.md).

## `vantage-operator`

Wird einmal pro Cluster in einem Namensraum Ihrer Wahl installiert. Der Bediener gleicht die Vantage-Installation ab, die durch die `Vantage`-Custom-Resource definiert ist.

> [!WARNING]
>
> **Installieren Sie pro Cluster nur eine Instanz dieses Charts.** Die ClusterRole und die ClusterRoleBinding des Charts gelten clusterweit und verwenden feste Namen. Siehe [Bekannte Einschränkungen](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/known-limitations.md#one-operator-instance-per-cluster).

### Abschnitte der obersten Ebene

* **`nameOverride` / `fullnameOverride`**: Überschreibt den vollständigen Namen des Charts teilweise (unter Beibehaltung des Release-Namens) oder vollständig. Standardmäßig nicht gesetzt.
* **`manager`**: das Deployment des Bedieners: `image`, Container-`args` (Leader-Wahl ist standardmäßig aktiviert), `env` (Pod-Name und Namensraum über die Downward API), `imagePullSecrets`, Sicherheitskontexte für Pod und Container (non-root, keine Rechteausweitung, schreibgeschütztes Root-Dateisystem), `resources` sowie Scheduling (`affinity`, `nodeSelector`, `tolerations`).
* **`rbacHelpers`**: optionale Admin-, Editor- und Viewer-Rollen zur Verwaltung der Custom-Resources. Standardmäßig deaktiviert.
* **`crd`**: CRD-Lebenszyklus: Installiert die CRDs zusammen mit dem Chart (`enable`) und behält sie bei der Deinstallation des Charts bei (`keep`).
* **`metrics`**: der per RBAC geschützte Endpunkt `/metrics`.
* **`certManager`**: cert-manager-Integration für TLS-Zertifikate; erforderlich für Webhook-Zertifikate und Zertifikate des Metrics-Endpunkts. Standardmäßig deaktiviert.
* **`prometheus`**: ein Prometheus-`ServiceMonitor` zum Abrufen von Metriken. Setzt den prometheus-Bediener im Cluster voraus. Standardmäßig deaktiviert.

### Wichtige Werte

Die Standardwerte beziehen sich auf das neueste Release. Wie Sie die Werte ausgeben, die eine chart-Version akzeptiert, erfahren Sie unter [Verfügbare Werte anzeigen](#inspecting-available-values).

| Wert | Zweck |
| - | - |
| `manager.replicas` | Standard: `1`. |
| `manager.image.repository` / `tag` / `pullPolicy` | Container-Image des Bedieners. `pullPolicy` ist standardmäßig auf `IfNotPresent` gesetzt. |
| `manager.imagePullSecrets` | Pull-Secrets für das Bediener-Image, falls Ihre registry eine Authentifizierung erfordert, zum Beispiel `--set "manager.imagePullSecrets[0].name=my-pull-secret"`. Standard: `[]`. Unter AKS nicht erforderlich, wenn der Kubelet-Identität die Rolle `AcrPull` zugewiesen ist. Siehe [Image-Pull-Zugriff](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/providers/azure.md#image-pull-access). |
| `manager.args` | Container-Argumente. Standard: `[--leader-elect]` (Leader-Wahl aktiviert). |
| `manager.env` | Umgebungsvariablen für den Bediener-Container. Standard: `POD_NAME` aus `metadata.name` und `POD_NAMESPACE` aus `metadata.namespace` (Feldverweise). |
| `manager.podSecurityContext` / `manager.securityContext` | Sicherheitskontexte auf pod- und Container-Ebene für den Bediener. Standardwerte: pod `runAsNonRoot: true` und `seccompProfile.type: RuntimeDefault`; Container `allowPrivilegeEscalation: false`, `capabilities.drop: [ALL]` und `readOnlyRootFilesystem: true`. |
| `manager.resources` | CPU-/Arbeitsspeicher-Anforderungen und -Limits. Standardwerte: Anforderungen `10m` CPU / `64Mi` Arbeitsspeicher, Limits `500m` CPU / `128Mi` Arbeitsspeicher. |
| `manager.affinity` / `manager.nodeSelector` / `manager.tolerations` | Standardmäßige Kubernetes-Scheduling-Einstellungen für den Bediener-pod. Standardmäßig leer. |
| `rbacHelpers.enable` | Installiert vordefinierte Admin-/Editor-/Viewer-Rollen für die CRDs. Standard: `false`. |
| `crd.enable` | Installiert die CRD `vantages.vantage.abbyy.com` zusammen mit dem chart. Standard: `true`. |
| `crd.keep` | Behält die CRDs bei, wenn das chart deinstalliert wird. Standard: `true`. |
| `metrics.enable` / `metrics.port` | Stellt den RBAC-geschützten Endpunkt `/metrics` bereit. Standardwerte: `true` / `8443`. |
| `certManager.enable` | Cert-manager-Integration für TLS-Zertifikate. Erforderlich für Webhook-Zertifikate und Zertifikate des Metrics-Endpunkts. Standard: `false`. |
| `prometheus.enable` | Erstellt einen Prometheus-`ServiceMonitor` zum Abrufen von Metriken. Setzt den prometheus-Bediener im Cluster voraus. Standard: `false`. |

Die Konfiguration der Vantage-Anwendung erfolgt in der Custom-Resource `Vantage`, die vom chart `vantage-selfhosted` erstellt wird.

## `vantage-selfhosted`

Wird in einen Namensraum Ihrer Wahl installiert. Dieser chart enthält die `Vantage`-Custom-Resource, eine ConfigMap mit den Daten der Vantage-Workloads samt zugehörigem RBAC sowie die Vantage-bezogenen CRDs und Rollen aus dem Upstream-Infrastruktur-Repository von ABBYY.

Die meisten Werte lassen sich direkt den Feldern der `Vantage`-Custom-Resource zuordnen. Die Spezifikation auf Feldebene finden Sie in der [API-Referenz](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/reference/latest/api-reference.md).

### Abschnitte der obersten Ebene

* **`operator`**: Verweis auf die Bediener-Installation (`namespace` und `controllerManagerServiceAccount`).
* **`ingress`**: der integrierte Ingress des Charts, ausgewählt über `ingress.type`. Setzen Sie `enabled: false`, wenn Sie den Ingress selbst verwalten, zum Beispiel mit Traefik.
* **`mesh`**: Istio-Mesh-Ressourcen (`mesh.istio.enabled`). Dies ist ein Konfigurationsabschnitt auf oberster Ebene, kein `Vantage.spec`-Feld.
* **`serviceAccounts`**: ServiceAccounts, die das Chart für Vantage-Workloads, den OCI-Migrations-Job und einzelne Workloads erstellt. Dies ist ein Konfigurationsabschnitt auf oberster Ebene, kein `Vantage.spec`-Feld.
* **`vantage`**: die `Vantage.spec`-Nutzdaten: `argocd`, `databaseProvider`, `debug`, `dnsRecord`, `idReadingEnabled`, `keda`, `mailFrom`, `minimalInstall`, `ociMigration`, `platformAdminEmail`, `reportingEnabled`, `reverseProxy`, `secrets`, `serviceAccountName`, `smtp`, `storage`, `techcore`, `updatePolicy`, `vantageVersion`, `workloads`. Diese Werte werden direkt an die Custom-Resource `Vantage` übergeben.
* **`defaultSkills`**: legt fest, welche Standard-Skills aus dem mitgelieferten Katalog der skill-installer-Bediener installiert. Dies ist ein Konfigurationsabschnitt auf oberster Ebene, kein `Vantage.spec`-Feld.
* **`observability`**: vom Chart gerenderte Prometheus-`ServiceMonitor`-Konfiguration. Dies ist ein Konfigurationsabschnitt auf oberster Ebene, kein `Vantage.spec`-Feld.
* **`workloadsConfigMap`**: steuert die workload-ConfigMap, die mit dem Chart ausgeliefert wird. `create` legt fest, ob das Chart sie erstellt, und `additionalMetadata` enthält erweiterte Überschreibungen pro Chart. Dies ist ein Konfigurationsabschnitt auf oberster Ebene, kein `Vantage.spec`-Feld.

### Erforderliche Werte

| Wert | Zuordnung zu | Zweck |
| - | - | - |
| `operator.namespace` | N/A | Namensraum, in dem Sie `vantage-operator` installiert haben. Standard: `vantage-operator-system`. |
| `operator.controllerManagerServiceAccount` | N/A | ServiceAccount des Bediener-Controller-Managers. Standard: `vantage-operator-controller-manager`. |
| `ingress.tls.secretName` | N/A | Name des Secrets vom Typ `kubernetes.io/tls`. Standard: `vantage-ingress-tls`. Wird verwendet, wenn `ingress.enabled` und `ingress.tls.enabled` auf `true` gesetzt sind. Bei `ingress.type: istio` muss sich das Secret im Namensraum des Istio-Ingress-Gateways befinden. Bei `gateway` erstellen Sie es im Vantage-Namensraum oder in dem über `ingress.gateway.certificateRef.namespace` festgelegten Namensraum. Bei `gateway` mit `ingress.gateway.create: false` wird es vom chart nicht verwendet; das Zertifikat stellt dann das vorhandene Gateway bereit. |
| `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` | E-Mail-Adresse des Plattform-Administrators. |
| `vantage.secrets.azure` oder `vantage.secrets.kubernetes` | `Vantage.spec.secrets` | Es muss genau ein Provider für Secrets konfiguriert sein. Siehe [Secrets und Key Vault](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/secrets-and-keyvault.md). |
| `vantage.secrets.azure.keyVaultName` / `tenantId` | `Vantage.spec.secrets.azure` | Erforderlich beim Azure Key Vault-Anbieter: der Key Vault, in dem die Secrets gespeichert sind, und der Azure AD-Mandant, dem er gehört. |

### Optionale Werte

| Wert | Zweck |
| - | - |
| `ingress.enabled` | Erstellt die Ingress-Ressourcen für `ingress.type`. Standard: `true`. Setzen Sie `false`, wenn Sie Ingress selbst verwalten, zum Beispiel mit einer Traefik-`IngressRoute`. |
| `ingress.type` | Ingress-Ressourcen, die das Chart erstellt, wenn `ingress.enabled` auf `true` steht: `istio` (Standard; Istio-`Gateway` und `VirtualService`), `kubernetes` (Kubernetes-`Ingress`), `gateway` (Gateway-API-`Gateway` und `HTTPRoute`) oder `native` (`gateway`, wenn der Cluster die Gateway API bereitstellt, andernfalls `kubernetes`). `native` erkennt die Gateway API anhand der API-Versionen des Clusters. Daher benötigt `helm template` die Option `--api-versions`, und im selben Release installierte Gateway-API-CRDs werden bei der Erstinstallation nicht erkannt. Die Gateway-API-CRDs und der zugehörige Controller bzw. der Ingress-Controller müssen bereits installiert sein. Setzen Sie bei `gateway` zusätzlich `vantage.reverseProxy: true`. Bei `kubernetes` setzen Sie diesen Wert, wenn der Ingress-Controller TLS terminiert. |
| `ingress.tls.enabled` | Terminiert TLS mit dem in `ingress.tls.secretName` angegebenen Secret. Standard: `true`. Setzen Sie `false`, wenn der Ingress-Controller das Zertifikat bereitstellt. |
| `ingress.istio.ingressGatewaySelector` | Labels, über die das Istio-Ingress-Gateway ausgewählt wird. Standard: `istio: aks-istio-ingressgateway-external`. |
| `ingress.istio.gateway.labels` / `annotations` | Zusätzliche Labels und Annotationen für das Istio-`Gateway`. Standard: `{}`. |
| `ingress.istio.internalDNSResolution.enabled` / `destination.host` | Leitet Aufrufe an `vantage.dnsRecord` aus dem Mesh über das Istio-Ingress-Gateway zurück, wenn für `vantage.dnsRecord` kein öffentlicher DNS-Eintrag existiert. Erfordert Istio-[DNS-Proxying](https://istio.io/latest/docs/ops/configuration/traffic-management/dns-proxy). Verwenden Sie nach Möglichkeit einen `vantage.dnsRecord` mit öffentlichem DNS-Eintrag. Standardwerte: `false` / `aks-istio-ingressgateway-external.aks-istio-ingress.svc.cluster.local`. |
| `ingress.kubernetes.ingressClassName` | `IngressClass`, die die `Ingress`-Ressourcen des Charts implementiert. Standard: `""`. Pfadumschreibungen basieren auf nginx-Annotationen und erfolgen daher nur mit der Klasse `nginx` oder mit `ingress.kubernetes.nginx: true`; bei nginx erhält jede umgeschriebene Route ein eigenes `Ingress`. Bei anderen Controllern erreichen umgeschriebene Routen das richtige Backend mit dem ursprünglichen Pfad, und Routen mit regulären Ausdrücken erhalten stattdessen das nächstliegende Präfix. |
| `ingress.kubernetes.nginx` | Behandelt die Ingress-Klasse als nginx-kompatibel, auch wenn sie nicht `nginx` heißt, zum Beispiel beim AKS-Anwendungsrouting. Standard: `false`. |
| `ingress.kubernetes.labels` / `annotations` | Zusätzliche Labels und Annotationen für die `Ingress`-Ressourcen des Charts, zum Beispiel zur Steuerung von TLS über den Ingress-Controller. Standard: `{}`. |
| `ingress.gateway.create` | Erstellt das Gateway-API-`Gateway`. Standard: `true`. Setzen Sie `false`, um die `HTTPRoute` über `ingress.gateway.parentRefs` an ein vorhandenes Gateway anzubinden. |
| `ingress.gateway.parentRefs` | `parentRefs` für die `HTTPRoute`, wenn `create` auf `false` steht, zum Beispiel `name`, `namespace` und `sectionName` eines Listeners auf einem gemeinsam genutzten Gateway. Die `allowedRoutes` des Gateways müssen Routen aus dem Namensraum des Releases zulassen. Standard: `[]`. |
| `ingress.gateway.name` / `gatewayClassName` | Name und `GatewayClass` des Gateways, das das Chart erstellt. Standardwerte: `vantage-gateway` / `""`. `gatewayClassName` ist erforderlich, wenn `create` auf `true` steht. |
| `ingress.gateway.meshIntegrated` | Setzen Sie `true`, wenn die GatewayClass-Implementierung Teil des Istio-Mesh ist, zum Beispiel die Gateway-API-Implementierung von Istio selbst. Mit `mesh.istio.enabled: true` verwendet das Chart dann `STRICT`-mTLS (siehe `mesh.istio.enabled`). Setzen Sie diesen Wert nicht für Implementierungen, deren Gateway-Pods im Vantage-Namensraum einen Istio-Sidecar erhalten, zum Beispiel kgateway mit Sidecar-Injektion. Standard: `false`. |
| `ingress.gateway.regexCatchAll` | Rendert die Catch-All-Route `/` als `RegularExpression`-Abgleich (`/.*`) statt als `PathPrefix`-Abgleich. Setzen Sie `true` für Implementierungen, die jeden `PathPrefix`-Abgleich vor `RegularExpression`-Abgleichen priorisieren, zum Beispiel Istio, wo das Präfix `/` sonst die Routen mit regulären Ausdrücken verdecken würde. Standard: `false`. |
| `ingress.gateway.labels` / `annotations` | Zusätzliche Labels und Annotationen für das `Gateway`, zum Beispiel `cert-manager.io/cluster-issuer`, damit cert-manager das Zertifikat in `ingress.tls.secretName` ausstellt. Standard: `{}`. |
| `ingress.gateway.infrastructure` | Gateway-`spec.infrastructure`: Labels, Annotationen und `parametersRef`, die die Implementierung an die von ihr erstellten Ressourcen weitergibt, etwa an den Load-Balancer-Service. Standard: `{}`. |
| `ingress.gateway.listeners.httpsPort` / `httpPort` | Ports der HTTPS- und HTTP-Listener des Gateways. Standardwerte: `443` / `80`. Das Gateway erhält einen HTTPS-Listener, wenn `ingress.tls.enabled` oder `listeners.controllerSuppliedTls` auf `true` steht, andernfalls einen HTTP-Listener. |
| `ingress.gateway.listeners.httpRedirect` | Fügt einen HTTP-Listener hinzu, dessen Anfragen auf HTTPS umgeleitet werden, sofern das Gateway einen HTTPS-Listener hat. Gilt nur, wenn `create` auf `true` steht. Standard: `false`. |
| `ingress.gateway.listeners.controllerSuppliedTls` / `tlsOptions` | Erstellt bei `ingress.tls.enabled: false` statt eines HTTP-Listeners einen HTTPS-Listener ohne `certificateRefs` – für Implementierungen, die das Zertifikat selbst bereitstellen. `tlsOptions` legt die implementierungsspezifischen `tls.options` des HTTPS-Listeners fest und ist bei `controllerSuppliedTls: true` erforderlich. Standardwerte: `false` / `{}`. |
| `ingress.gateway.certificateRef.namespace` / `createReferenceGrant` | Namensraum des Secrets `ingress.tls.secretName`, falls es sich nicht im Namensraum des Releases befindet. Das Gateway kann ein Secret in einem anderen Namensraum nur über einen dort angelegten `ReferenceGrant` verwenden. Mit `createReferenceGrant: true` erstellt das Chart diesen; andernfalls müssen Sie ihn selbst erstellen. Gilt nur, wenn `create` und `ingress.tls.enabled` auf `true` stehen. Standardwerte: `""` / `false`. |
| `ingress.gateway.route.labels` / `annotations` | Zusätzliche Labels und Annotationen für die `HTTPRoute`-Ressourcen des Charts. Standard: `{}`. |
| `ingress.gateway.route.timeouts` | `timeouts` für jede `HTTPRoute`-Regel. Standard: `request: 0s` (kein Zeitlimit für Anfragen). Setzt voraus, dass die Implementierung `HTTPRouteRequestTimeout` unterstützt. Setzen Sie `{}`, um den Standardwert der Implementierung beizubehalten. |
| `mesh.istio.enabled` | Stellt die empfohlene Istio-Mesh-Konfiguration bereit. Standard: `true`. Der `PeerAuthentication`-Modus des Charts ist `STRICT` bei Istio-Ingress oder einem Mesh-integrierten Gateway (`ingress.gateway.meshIntegrated`), andernfalls `PERMISSIVE`. Bei `ingress.type: kubernetes` wird diese `PERMISSIVE`-Konfiguration ohne eine entsprechende Istio-`AuthorizationPolicy` nicht für den Produktivbetrieb empfohlen. Wenn Sie Istio als Service Mesh einsetzen, verwenden Sie Istio-Ingress oder ein Mesh-integriertes Gateway. |
| `vantage.vantageVersion` | Zu installierende Version von Vantage. Wird `Vantage.spec.vantageVersion` zugeordnet. Standard: `""`. |
| `vantage.databaseProvider` | Datenbank-Engine für Vantage-Services. Zulässige Werte: `SqlServer` (Standard) oder `PostgreSQL`; Groß-/Kleinschreibung wird beachtet. |
| `vantage.secrets.azure.clientId` | Client-ID der benutzerzugewiesenen verwalteten Identität mit Lesezugriff auf den Key Vault. Bei `identityMode: workloadIdentity` (Standard) verwendet jeder Workload die Annotation `azure.workload.identity/client-id` an seinem ServiceAccount und greift ersatzweise auf `clientId` zurück. Wird `Vantage.spec.secrets.azure.clientId` zugeordnet. |
| `vantage.secrets.azure.identityMode` | Einer der Werte `workloadIdentity` (Standard), `podIdentity` oder `vmManagedIdentity`. Siehe [Secrets und Key Vault](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/secrets-and-keyvault.md#azure-key-vault-provider). |
| `vantage.secrets.azure.userAssignedIdentityID` | Client-ID der UAMI, die verwendet wird, wenn `identityMode` auf `vmManagedIdentity` steht. |
| `vantage.secrets.azure.objects` | Zuordnung von Secret-Alias → `{objectName, objectType, objectVersion}` für Key-Vault-Objekte, deren Namen nicht mit dem Alias übereinstimmen. |
| `vantage.secrets.kubernetes` | Verwendet bereits vorhandene Kubernetes-`Secret`-Ressourcen anstelle von Azure Key Vault. Eine optionale `objects`-Zuordnung überschreibt die Standardnamen der Secrets. |
| `vantage.smtp.host` / `port` / `useSSL` / `login` / `password` | Ausgehendes SMTP. Wird nur verwendet, wenn gesetzt; standardmäßig wird SendGrid verwendet. Entspricht `Vantage.spec.smtp`. `port` ist standardmäßig `587`; `useSSL` (TLS) ist standardmäßig `false`. |
| `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 den `imagePullSecrets` dieses ServiceAccounts sowie jedes in `vantage.workloads.serviceAccounts` genannten ServiceAccounts hinzu (oder setzen Sie `serviceAccounts.imagePullSecrets`, wenn das Chart sie erstellt). Siehe [Azure-Image-Pull-Zugriff](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/providers/azure.md#image-pull-access) oder [Registry-Zugriff bei self-managed](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/providers/self-managed.md#configure-registry-access). |
| `serviceAccounts.vantage.create` / `name` / `labels` / `annotations` / `imagePullSecrets` | Lässt das Chart den ServiceAccount für Vantage-Workloads erstellen. Standardwert `create: false`. Der Name entspricht standardmäßig dem Release-Namen und wird als `vantage.serviceAccountName` gesetzt. |
| `serviceAccounts.ociMigration.create` / `name` / `labels` / `annotations` / `imagePullSecrets` | Lässt das Chart den ServiceAccount für den OCI-Migrations-Job erstellen. Standardwert `create: false`. Der Name lautet standardmäßig `<release name>-oci-migration` und wird als `vantage.ociMigration.serviceAccountName` gesetzt. |
| `serviceAccounts.labels` / `annotations` / `imagePullSecrets` | Werden jedem ServiceAccount hinzugefügt, den das Chart erstellt. Labels und Annotationen, die für einen einzelnen ServiceAccount gesetzt sind, haben Vorrang. Pull-Secrets werden zusätzlich zu den für den jeweiligen ServiceAccount gesetzten hinzugefügt. Standardmäßig leer. |
| `serviceAccounts.workloads.<chart>.<kind>` | Weist einem Workload einen eigenen ServiceAccount anstelle des `vantage`-ServiceAccounts zu. Schlüssel sind der Chart-Name und darunter die Workload-Art (`migrator`, `deployment` oder `statefulSet`). Jeder Eintrag unterstützt `create` (Standard `true`), `name` (Standard `<chart name without -helm>-<kind>`, zum Beispiel `mail-migrator`; erforderlich, wenn `create` auf `false` gesetzt ist), `labels`, `annotations`, `imagePullSecrets` und `roles`. Jeder ServiceAccount wird an `roles` gebunden; standardmäßig sind dies `migration-writer` und `serviceversion-reader` für Migratoren, für alle anderen `migration-reader` und `serviceversion-reader`. Workloads können einen ServiceAccount gemeinsam nutzen, indem sie denselben Namen verwenden; Einträge, die einen gemeinsam genutzten ServiceAccount erstellen, müssen ihn identisch konfigurieren. Setzt `Vantage.spec.workloads.serviceAccounts`. Standardwert `{}`. |
| `vantage.workloads.configMap` / `metadataTemplateKey` / `secretsKey` / `workloadsKey` / `additionalMetadataKey` | Schlüssel der workload-ConfigMap, die mit dem Chart ausgeliefert wird. Wenn `workloadsConfigMap.create` auf `true` gesetzt ist (Standard), benennt das Chart die ConfigMap nach der Chart-Version und verwendet `configMap` (Standard `vantage-workloads`) nur als Namenspräfix. `additionalMetadataKey` (Standard `additional-metadata.yml`) gibt den Schlüssel an, der Ihre `workloadsConfigMap.additionalMetadata`-Überschreibungen enthält. Entspricht `Vantage.spec.workloads`. |
| `vantage.workloads.pods.labels` / `vantage.workloads.pods.charts.<chart>.<kind>.labels` | Labels, die den Pods aller oder bestimmter Workloads hinzugefügt werden, zum Beispiel `azure.workload.identity/use: "true"`. Chartspezifische Labels haben Vorrang. Entspricht `Vantage.spec.workloads.pods`. `<chart>` ist der vollständige Chart-Name aus der workload-ConfigMap, zum Beispiel `mail-helm`. `<kind>` ist `migrator`, `deployment` oder `statefulSet`. |
| `vantage.storage.custom.storageClass` / `size` | Verwendet anstelle von Azure Blob ein Backend auf Basis einer Kubernetes-`StorageClass`. Entspricht `Vantage.spec.storage.custom`. `size` ist standardmäßig `300Gi`. |
| `vantage.idReadingEnabled` | Aktiviert Funktionen zum Lesen von Ausweisdokumenten. Entspricht `Vantage.spec.idReadingEnabled`. Standardwert `false`. Der Operator stellt die `worker-id-reading`-Charts nie bereit; siehe [Bereitstellung von TechCore-Workern](#techcore-worker-deployment). |
| `vantage.minimalInstall` | Stellt Vantage-Workloads mit minimalen Ressourcenkonfigurationen bereit. Entspricht `Vantage.spec.minimalInstall`. Standardwert `false`. Steuert nur die Dimensionierung der Workloads. Kombinieren Sie die Option mit `defaultSkills.mode: minimal` oder `custom`. |
| `vantage.debug` | Stellt Vantage-Workloads im Debug-Modus bereit. Entspricht `Vantage.spec.debug`. Standardwert `false`. |
| `defaultSkills.mode` | `all` (Standard; jede Version jedes Standard-Skills), `minimal` (neueste Version jedes Skills plus die im Chart festgelegten Versionen) oder `custom` (nur `defaultSkills.skills`). `all` ist die einzige sichere Voreinstellung: Skills, die von einem Standard-Skill abgeleitet sind, funktionieren nicht mehr, wenn dieser Standard-Skill nicht installiert ist. Eine reduzierte Auswahl muss daher immer bewusst getroffen werden. Installierte Standard-Skills können nicht entfernt werden; legen Sie die Auswahl also vor der ersten Installation fest. Überschreibungen für `skill-installer-def-installation` in `workloadsConfigMap.additionalMetadata` haben Vorrang. |
| `defaultSkills.skills` | Im `custom`-Modus zu installierende Skills als `{id, versions}`-Einträge. Wird in anderen Modi ignoriert. Lassen Sie `versions` für die neueste Version weg, setzen Sie `all` für alle Versionen oder geben Sie Versionsnummern an. Bei einer unbekannten ID oder Version schlägt das Rendern fehl. Standardwert `[]`. |
| `workloadsConfigMap.create` | Erstellt die ConfigMap mit Daten zu den für die Installation von Vantage erforderlichen Charts und Images sowie die zugehörige RBAC. Standardwert `true`. Der Name der ConfigMap enthält die Chart-Version, sodass jedes Chart-Upgrade `Vantage.spec.workloads.configMap` ändert und der Operator Vantage direkt aktualisiert – sowohl bei `helm upgrade` als auch bei GitOps-Tools, die mit `helm template` rendern. |
| `workloadsConfigMap.additionalMetadata` | Erweiterte chartspezifische Überschreibungen, die mit den gerenderten Workload-Metadaten zusammengeführt werden. Standardwert `{}`. Ein Eintrag für `charts.skill-installer-def-installation.values.defaultSkills` hat Vorrang vor `defaultSkills.mode`. Siehe [Zusätzliche Workload-Metadaten](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/performance/additional-workloads-metadata.md). |
| `vantage.reportingEnabled` | Schaltet die SQL-Server-Reporting-Funktionen ein oder aus. Standardwert `false`. Muss bei PostgreSQL auf `false` bleiben. |
| `vantage.reverseProxy` | Konfiguriert Vantage-Anwendungsdienste für den Betrieb hinter einem Reverse Proxy, der TLS terminiert. Standardwert `false`. Setzen Sie den Wert auf `true` bei `ingress.type: gateway` sowie immer dann, wenn der Ingress-Controller oder ein kundenverwalteter Proxy TLS terminiert, was bei `ingress.type: kubernetes` üblich ist. Entspricht `Vantage.spec.reverseProxy`. Siehe [Weitergeleitetes HTTPS-Schema](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/providers/self-managed.md#forwarded-https-scheme). |
| `vantage.argocd.project` | Argo-CD-Projekt für die vom Operator generierten Applications. Standardwert `default`. Das Projekt muss den Zielcluster und den Ziel-Namespace zulassen. Entspricht `Vantage.spec.argocd.project`. |
| `vantage.updatePolicy.manual` / `auto` | Upgrade-Richtlinie. Entspricht `Vantage.spec.updatePolicy`. Standardwert `manual: {}`: Vantage wird nur aktualisiert, wenn Sie neue Chart-Versionen installieren. Es ist genau eine Richtlinie erforderlich, und die CRD lehnt `auto` ab, da automatische Updates noch nicht unterstützt werden. Siehe [`updatePolicy`](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/reference/latest/api-reference#vantagespecupdatepolicy). |
| `vantage.ociMigration.enabled` | Führt den OCI-Migrations-Job aus. Standardwert `true`. |
| `vantage.ociMigration.serviceAccountName` | ServiceAccount, unter dem der OCI-Migrations-Job ausgeführt wird. Entspricht `Vantage.spec.ociMigration.serviceAccountName`. Um das Job-Image mit einem Pull-Secret abzurufen, fügen Sie das Secret den `imagePullSecrets` dieses ServiceAccounts hinzu. |
| `vantage.ociMigration.imagePullSecrets` | Pull-Secrets für das Operator-Image, das den OCI-Migrations-Job ausführt. |
| `vantage.ociMigration.sources[]` | Quell-Registries, aus denen Vantage-Artefakte kopiert werden. Setzen Sie `sources[0].host` und `sources[0].repository` auf die ABBYY-Quell-Registry. Setzen Sie `sources[].credentialsRef.name` auf ein Secret mit den Schlüsseln `username` und `password` oder auf ein `kubernetes.io/dockerconfigjson`-Secret. |
| `vantage.ociMigration.sources[].username` / `password` | Anmeldedaten im Klartext für eine Quell-Registry. Standardwert `""`. Verwenden Sie in Produktionsumgebungen `sources[].credentialsRef.name`; diese Einstellung hat Vorrang. |
| `vantage.ociMigration.destination.host` / `repository` | Ziel-Registry, in die Artefakte kopiert werden. Erforderlich, solange `enabled` auf `true` gesetzt ist. Standard-Host `abbyy.com`. `host` ist der Hostname der Registry mit optionalem Port, ohne Schema oder Pfad. Geben Sie den Pfad in `repository` an, zum Beispiel `vantage/images`. |
| `vantage.ociMigration.destination.username` / `password` / `credentialsRef.name` | Anmeldedaten für die Ziel-Registry. `username` und `password` werden im Klartext angegeben und sind standardmäßig `""`. Setzen Sie in Produktionsumgebungen `credentialsRef.name` auf ein Secret mit den Schlüsseln `username` und `password` oder auf ein `kubernetes.io/dockerconfigjson`-Secret. `credentialsRef` hat Vorrang vor `username` und `password`. Entspricht `Vantage.spec.ociMigration.destination`. |
| `vantage.ociMigration.concurrency` | Anzahl der Artefakte, die der OCI-Migrations-Job parallel kopiert. Standardwert `5`. |
| `vantage.ociMigration.resources` | Requests und Limits für den Container des OCI-Migrations-Jobs. Standardwerte: Requests `100m` CPU / `128Mi` Arbeitsspeicher, Limit `512Mi` Arbeitsspeicher, kein CPU-Limit. Ein angegebener Wert ersetzt die Standardwerte vollständig. |
| `vantage.keda.enabled` | Legt fest, ob [KEDA](https://keda.sh/) für die automatische Skalierung von Vantage-Workloads verwendet wird. Standardwert `false`. Die aktuellen Vantage-Workload-Charts erfordern KEDA 2.17.x. Siehe [Automatische Skalierung mit KEDA](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/performance/autoscaling.md). |
| `observability.prometheus.namespace` | Namensraum, in dem Ihre Prometheus-Instanz installiert ist. Standard: `observability`. Die Vantage-KEDA-Autoscaler fragen Prometheus unter `prometheus-operated.observability.svc.cluster.local:9090` ab. Belassen Sie Prometheus daher im Namensraum `observability`. |
| `observability.prometheus.serviceMonitor.create` | Erstellt Prometheus-`ServiceMonitor`-Ressourcen, über die Vantage-Anwendungsmetriken abgerufen werden. Standard: `false`. |
| `observability.prometheus.serviceMonitor.selectorMatchLabels` | Labels, die Ihre Prometheus-Instanz benötigt, um einen `ServiceMonitor` zu registrieren. Muss mit `spec.serviceMonitorSelector.matchLabels` Ihrer `Prometheus`-Ressource übereinstimmen. Standard: `{}`. |
| `observability.prometheus.serviceMonitor.interval` | Gibt an, wie oft Prometheus Vantage-Metriken abruft. Da KEDA diese Metriken ausliest, bestimmt das Intervall auch, wie schnell TechCore-Worker auf Aufgaben in der Warteschlange reagieren können. Standard: `15s` bzw. `60s`, wenn `vantage.minimalInstall` auf `true` gesetzt ist. Siehe [Automatische Skalierung mit KEDA](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/performance/autoscaling.md#scale-out-responsiveness). |
| `observability.prometheus.serviceMonitor.scheme` | Schema für die Scrape-Endpunkte des `ServiceMonitor`. Standardmäßig nicht gesetzt (HTTP). Setzen Sie `https` zusammen mit `tlsConfig` bei Istio-`STRICT`-mTLS oder bei Linkerd, wenn eine Autorisierungsrichtlinie unverschlüsselte Metrikabrufe blockiert. Bei Istio-`PERMISSIVE`-mTLS nicht setzen. Siehe [Überwachung mit Prometheus](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/monitoring/prometheus.md#istio-mtls). |
| `observability.prometheus.serviceMonitor.tlsConfig` | Prometheus-`tlsConfig` für die Scrape-Endpunkte des `ServiceMonitor` (`caFile`, `certFile`, `keyFile`, `insecureSkipVerify`). Standardmäßig nicht gesetzt. Zusammen mit `scheme: https` verwenden. |
| `vantage.techcore.versions` | Bereitzustellende TechCore-Versionen. Zulässige Werte: `2`, `3`, `4`. Standard: `[3, 4]`. Die höchste Version gilt als aktuelle Version. Siehe [Bereitstellung der TechCore-Worker](#techcore-worker-deployment). |
| `vantage.techcore.nnTrainingWorkers.enabled` / `gpu` | Stellt die Trainings-Worker für neuronale Netze für die aktuelle (höchste) TechCore-Version bereit. Mit `gpu: true` werden statt der CPU-Varianten die GPU-Varianten bereitgestellt. Standardwerte: `false` / `false`. |

## Verfügbare Werte anzeigen

Der `vantage-operator`-chart wird vom Kubebuilder-Helm-plugin generiert. Im `vantage-selfhosted`-chart werden die Vorlagen für die `Vantage`-Custom-Resource und die workload-ConfigMap manuell gepflegt. So geben Sie die Werte aus, die eine chart-version akzeptiert:

```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
```

Für `$charts_uri`, `$chart_uri` und die Versionsvariablen gelten die unter [Installationsvariablen](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/providers/azure.md#install-variables) beschriebenen Konventionen.

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
```

## Bediener- vs. Vantage-Konfiguration

| Bereich | Konfiguriert in |
| - | - |
| Bediener-Runtime (Image, Pull-Secrets, Scheduling, CRD-Lebenszyklus, Metriken) | Helm-Werte von `vantage-operator` |
| Vantage-Anwendung (secrets, SMTP, Workloads, Speicher, techcore) | Helm-Werte von `vantage-selfhosted` → `Vantage.spec` |

## Bereitstellung der TechCore-Worker

Das `vantage-selfhosted`-chart wendet eine `Vantage`-Custom-Resource an. Der Bediener stellt anschließend anhand von `spec.techcore.*` eine Teilmenge der TechCore-Worker-charts bereit, wie in den folgenden Matrizen dargestellt.

### Namenskonvention

Worker-charts werden nach dem Schema `vtc-{version}-worker-{name}-helm` benannt, wobei `{version}` eine in `spec.techcore.versions` aufgeführte Version ist. Die Versionsnummern dienen lediglich als Namenspräfixe und haben für den Bediener keine semantische Bedeutung. Welche Worker verfügbar sind, ergibt sich aus der workload-ConfigMap, die mit dem chart `vantage-selfhosted` ausgeliefert wird.

### Zwei Bereitstellungsdurchläufe

| Durchlauf | Versionen | Berücksichtigte Charts |
| - | - | - |
| Aktuelle Version | Die höchste Version in `spec.techcore.versions` | `vtc-{version}-worker*` |
| Vorherige Versionen | Alle anderen Versionen in `spec.techcore.versions` | `vtc-{version}-worker*` |

Worker-Charts für Versionen, die nicht in `spec.techcore.versions` aufgeführt sind, werden nicht bereitgestellt. Wenn die Worker einer früheren TechCore-Version parallel zur aktuellen weiterlaufen sollen, geben Sie beide Versionen an. Mit dem Standardwert des Charts, `[3, 4]`, wird TechCore 4 als aktuelle Version und TechCore 3 als vorherige Version bereitgestellt.

### Inklusionsmatrix: Durchlauf der aktuellen Version

| 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 anderen Worker | Immer |

### Inklusionsmatrix: Durchlauf für vorherige Versionen

Wird für jede Version in `spec.techcore.versions` außer der höchsten ausgeführt.

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

> [!NOTE]
>
> Die ID-Erkennung wird auf Plattformebene gesteuert, nicht über TechCore. Das zugehörige Flag `spec.idReadingEnabled` befindet sich außerhalb von `spec.techcore`. Die `worker-id-reading`-Charts werden nie bereitgestellt. Siehe [`Vantage.spec`-Referenz](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/reference/latest/api-reference#vantagespec).

Die Matrix entscheidet nur darüber, welche der Worker aus der workload-ConfigMap der ausgewählten Version aufgenommen werden. Charts, die in den Workloads dieser Version fehlen, können schlicht nicht bereitgestellt werden. So ist `worker-ocr-join` derzeit nur im Workload-Satz von `vtc-2` enthalten und wird daher nur dann als `vtc-2-worker-ocr-join-helm` bereitgestellt, wenn `spec.techcore.versions` den Wert `2` enthält.

## Wie geht es weiter?

> [card] [API-Referenz](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/reference/latest/api-reference.md)
>
> Referenz aller Felder der `Vantage`-Custom-Resource.

> [card] [Installation auf Azure](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/providers/azure.md)
>
> Schritt-für-Schritt-Anleitung zur Installation mit diesen charts.

> [card] [Selbstverwaltetes Kubernetes](https://docs.abbyy.com/de/vantage/self-hosted/v3.0/providers/self-managed.md)
>
> Installation mit kundenseitig verwaltetem Ingress, Mesh, secrets, Speicher und Datendiensten.