Zum Hauptinhalt springen
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. Eine Installationsanleitung finden Sie unter Azure oder selbstverwaltetes Kubernetes.
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.

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

​
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

​
Optionale Werte

​
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:
$charts_uri, $chart_uri und die Versionsvariablen entsprechen den Konventionen unter Installationsvariablen. So prüfen Sie die gerenderten Manifeste, bevor Sie sie anwenden:

​
Operator vs. Vantage-Konfiguration

Die Konfiguration ist klar aufgeteilt:

​
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

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

​
Inklusionsmatrix: Durchgang der vorherigen Version

Wird nur ausgeführt, wenn spec.techcore.keepPreviousVersion: true.
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.
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

API-Referenz

Eine Feld-für-Feld-Referenz für die Vantage Custom-Resource.

Installation auf Azure

Die Schritt-für-Schritt-Installation mit diesen Charts.

Selbstverwaltetes Kubernetes

Installation mit vom Kunden verwaltetem Ingress, Mesh, Secrets, Speicher und Datendiensten.