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

# Bekannte Einschränkungen

> Aktuelle Einschränkungen und Rahmenbedingungen, die Kunden beim Betrieb von Vantage 3.0 selbstgehostet berücksichtigen sollten.

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

<div id="architectural-constraints">
  ## Architekturbedingte Einschränkungen
</div>

<div id="one-operator-instance-per-cluster">
  ### Eine Operator-Instanz pro Cluster
</div>

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

<div id="deployment-support">
  ## Unterstützung für die Bereitstellung
</div>

<div id="supported-deployment-targets">
  ### Unterstützte Bereitstellungsziele
</div>

Vantage 3.0 selbstgehostet unterstützt AKS und selbstverwaltetes Kubernetes. Die validierten Integrationen sind unter [Compatibility](/de/vantage/self-hosted/v3.0/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.

<div id="database-support">
  ## Unterstützte Datenbanken
</div>

<div id="reporting-requires-sql-server">
  ### Für Reporting ist SQL Server erforderlich
</div>

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.

<div id="mail-delivery">
  ## E-Mail-Versand
</div>

<div id="smtp-supports-basic-auth-only">
  ### SMTP unterstützt nur Basic Auth
</div>

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.

<div id="operational-notes">
  ## Hinweise zum Betrieb
</div>

<div id="alternate-ingress-controllers-require-the-vantage-route-contract">
  ### Alternative Ingress-Controller müssen den Vantage-Routenvertrag einhalten
</div>

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](/de/vantage/self-hosted/v3.0/providers/self-managed#forwarded-https-scheme) beschrieben.

<div id="keda-is-limited-to-217x">
  ### KEDA ist auf 2.17.x begrenzt
</div>

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](/de/vantage/self-hosted/v3.0/performance/autoscaling).

<div id="skill-installation-is-not-surfaced-in-argocd">
  ### Die Skill-Installation wird in ArgoCD nicht angezeigt
</div>

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](/de/vantage/self-hosted/v3.0/lifecycle#skill-installation-runs-separately).

<div id="whats-next">
  ## Nächste Schritte
</div>

<CardGroup cols={2}>
  <Card title="Migration von Vantage 2.7" icon="right-left" href="/de/vantage/self-hosted/v3.0/migration-from-2.7">
    Planen Sie die Migration einer vorhandenen selbstgehosteten 2.7-Bereitstellung.
  </Card>

  <Card title="Upgrade" icon="arrow-up" href="/de/vantage/self-hosted/v3.0/upgrading">
    Manueller Workflow für Upgrades zwischen 3.0-Versionen.
  </Card>
</CardGroup>