Passer au contenu principal
Quelques contraintes s’appliquent actuellement à Vantage 3.0 auto-hébergé. Tenez-en compte avant de dimensionner ou de planifier un déploiement.

​
Contraintes architecturales

​
Une instance de l’opérateur par cluster

Le chart Helm vantage-operator utilise des noms de ressources de portée cluster non paramétrés : le manager-role ClusterRole, le manager-rolebinding ClusterRoleBinding et le controller-manager ServiceAccount. Installer le chart deux fois dans le même cluster (même dans des namespaces différents) entraîne des conflits sur ces ressources. Installez une seule instance de ce chart par cluster.

​
Prise en charge du déploiement

​
Cibles de déploiement prises en charge

Vantage 3.0 auto-hébergé prend en charge AKS et Kubernetes autogéré. Les intégrations validées sont documentées dans Compatibilité. Les autres versions de Kubernetes, maillages de services, contrôleurs d’ingress, moteurs de base de données et remplacements de composants n’ont pas été validés ; rapprochez-vous de votre équipe ABBYY en charge de votre compte avant d’utiliser en production une combinaison ne figurant pas dans la liste.

​
Prise en charge des bases de données

​
La génération de rapports nécessite SQL Server

PostgreSQL est pris en charge pour les services Vantage, mais la charge de travail de génération de rapports utilise des migrations propres à SQL Server et n’est pas disponible avec PostgreSQL. Définissez vantage.databaseProvider: PostgreSQL et laissez vantage.reportingEnabled: false pour les déploiements avec PostgreSQL.

​
Envoi d’e-mails

​
SMTP prend uniquement en charge l’authentification Basic

SendGrid est le fournisseur de messagerie par défaut : fournissez un secret sendgridApiKey et Vantage l’utilisera sans configuration supplémentaire. SMTP n’est utilisé que lorsque vous configurez spec.smtp, et le mode SMTP ne prend actuellement en charge que l’authentification Basic ou l’absence d’authentification. Si votre relais de messagerie nécessite un autre mécanisme d’authentification et que vous ne pouvez pas utiliser SendGrid, prévoyez un relais intermédiaire qui redescend vers l’authentification Basic.

​
Notes opérationnelles

​
Les contrôleurs d’ingress alternatifs nécessitent le contrat de routage Vantage

Les configurations d’ingress validées sont la configuration Istio intégrée sur AKS et la configuration Traefik documentée sur Kubernetes autogéré. Tout autre contrôleur d’ingress doit implémenter les mêmes routes, réécritures, comportement TLS, protection du statut interne et schéma HTTPS transmis. La validation d’un autre contrôleur ou d’une autre implémentation de routage relève de votre responsabilité. Lorsque la terminaison TLS a lieu en amont d’un backend HTTP, les services d’authentification Vantage doivent respecter X-Forwarded-Proto. Si les charts de charge de travail n’exposent pas la variable d’environnement requise, utilisez un mécanisme de mutation d’admission pris en charge, comme décrit dans Kubernetes autogéré.

​
KEDA est limité à la version 2.17.x

Les charts des charges de travail Vantage actuels utilisent un champ du scaler KEDA qui a été supprimé dans KEDA 2.18. Utilisez KEDA 2.17.3. Avec KEDA 2.18 ou version ultérieure, les ressources ScaledObject concernées ne peuvent pas créer leurs HPA et restent dégradées. Voir Mise à l’échelle automatique avec KEDA.

​
L’installation des Skills n’apparaît pas dans ArgoCD

Les Skills sont installés par un job Kubernetes distinct, et non par une application ArgoCD gérée par un opérateur. ArgoCD ne permet donc actuellement pas de suivre la progression de l’installation des Skills. La ressource Vantage peut signaler l’état Ready alors que le job est toujours en cours d’exécution ; vous pouvez utiliser Vantage pendant l’installation des Skills. Surveillez directement le job avec kubectl wait. Voir Lifecycle pour les commandes.

​
Étapes suivantes

Migrer depuis Vantage 2.7

Planifiez la migration d’un déploiement auto-hébergé 2.7 existant.

Mise à niveau

Procédure manuelle de mise à niveau pour passer d’une version 3.0 à une autre.