Zum Hauptinhalt springen
Für Vantage 3.0 selbstgehostet gelten derzeit einige Einschränkungen. Berücksichtigen Sie diese, bevor Sie eine Bereitstellung dimensionieren oder planen.”

​
Architekturbedingte Einschränkungen

​
Eine Operator-Instanz pro Cluster

Das vantage-operator-Helm-Chart verwendet clusterweite, nicht templatierte Ressourcennamen: die manager-role ClusterRole, das manager-rolebinding ClusterRoleBinding und das controller-manager ServiceAccount. Wenn das Chart zweimal im selben Cluster installiert wird (auch in unterschiedlichen Namespaces), führt das bei diesen Ressourcen zu Konflikten. Installieren Sie pro Cluster nur eine Instanz dieses Charts.

​
Unterstützung für die Bereitstellung

​
Unterstützte Bereitstellungsziele

Vantage 3.0 selbstgehostet unterstützt AKS und selbstverwaltetes Kubernetes. Die validierten Integrationen sind unter Compatibility dokumentiert. Andere Kubernetes-Versionen, Service-Meshes, Ingress-Controller, Datenbank-Engines und der Ersatz von Komponenten wurden nicht validiert; stimmen Sie sich mit Ihrem ABBYY-Account-Team ab, bevor Sie eine nicht aufgeführte Kombination in der Produktion verwenden.

​
Unterstützte Datenbanken

​
Für Reporting ist SQL Server erforderlich

PostgreSQL wird für Vantage-Services unterstützt, aber der Reporting-Workload verwendet SQL-Server-spezifische Migrationen und ist mit PostgreSQL nicht verfügbar. Setzen Sie vantage.databaseProvider: PostgreSQL und belassen Sie vantage.reportingEnabled: false für PostgreSQL-Bereitstellungen.

​
E-Mail-Versand

​
SMTP unterstützt nur Basic Auth

SendGrid ist der Standard-Mail-Provider: Hinterlegen Sie ein sendgridApiKey-Secret, und Vantage verwendet es ohne weitere Konfiguration. SMTP wird nur verwendet, wenn Sie spec.smtp konfigurieren, und unterstützt derzeit nur Basic Auth oder keine Authentifizierung. Wenn Ihr Mail-Relay ein anderes Authentifizierungsschema erfordert und Sie SendGrid nicht verwenden können, planen Sie ein zwischengeschaltetes Relay ein, das auf Basic Auth herunterstuft.

​
Hinweise zum Betrieb

​
Alternative Ingress-Controller müssen den Vantage-Routenvertrag einhalten

Die validierten Ingress-Pfade sind die integrierte Istio-Konfiguration auf AKS und die dokumentierte Traefik-Konfiguration auf selbstverwaltetem Kubernetes. Ein anderer Ingress-Controller muss dieselben Routen, Umschreibungen, dasselbe TLS-Verhalten, denselben Schutz interner Statusinformationen und dasselbe weitergeleitete HTTPS-Schema implementieren. Die Validierung eines anderen Controllers oder einer anderen Routenimplementierung liegt in Ihrer Verantwortung. Wenn TLS vor einem HTTP-Backend terminiert wird, müssen die Vantage-Authentifizierungs-Services X-Forwarded-Proto auswerten. Wenn die Workload-Charts die erforderliche Umgebungseinstellung nicht bereitstellen, verwenden Sie einen unterstützten Admission-Mutation-Mechanismus, wie unter Selbstverwaltetes Kubernetes beschrieben.

​
KEDA ist auf 2.17.x begrenzt

Die aktuellen Vantage-Workload-Charts verwenden ein KEDA-Scaler-Feld, das in KEDA 2.18 entfernt wurde. Verwenden Sie KEDA 2.17.3. Mit KEDA 2.18 oder höher können betroffene ScaledObject-Ressourcen ihre HPAs nicht erstellen und verbleiben in einem degradierten Zustand. Siehe Autoskalierung mit KEDA.

​
Die Skill-Installation wird in ArgoCD nicht angezeigt

Skills werden durch einen separaten Kubernetes-Job installiert, nicht durch eine vom Operator verwaltete ArgoCD-Anwendung. Daher bietet ArgoCD derzeit keinen Einblick in den Fortschritt der Skill-Installation. Die Vantage-Ressource kann Ready melden, während der Job noch läuft; Sie können Vantage also bereits nutzen, während die Skill-Installation noch läuft. Überwachen Sie den Job direkt mit kubectl wait. Die Commands finden Sie unter Lifecycle.

​
Nächste Schritte

Migration von Vantage 2.7

Planen Sie die Migration einer vorhandenen selbstgehosteten 2.7-Bereitstellung.

Upgrade

Manueller Workflow für Upgrades zwischen 3.0-Versionen.