Prérequis - ABBYY Documentation

Cette page présente les prérequis pour une installation auto-hébergée de Vantage 3.0. Vous provisionnez tous les éléments décrits sur cette page dans votre propre abonnement et votre propre cluster ; cette page indique ce qu’il faut créer, et non les outils permettant de le créer. Pour la procédure complète, choisissez Azure ou Kubernetes autogéré.

Vantage 3.0 utilise un modèle de déploiement différent de celui de la version 2.7 et des versions antérieures. Les versions précédentes nécessitaient l’infrastructure précisément spécifiée par ABBYY, créée et configurée à l’aide des scripts Ansible et Azure CLI fournis par ABBYY. Ce modèle n’est plus pris en charge dans la version 3.0 :

Vous provisionnez votre propre infrastructure : le cluster Kubernetes, les bases de données, les comptes de stockage et le Key Vault. ABBYY ne fournit pas de scripts de provisionnement, de modèles ni d’autre automatisation d’infrastructure pour la version 3.0.
L’installateur déploie uniquement Vantage Core. Les logiciels tiers dont Vantage dépend, tels qu’ArgoCD, votre maillage de services et votre contrôleur d’ingress, votre intégration des secrets et votre stack de monitoring, sont installés et maintenus par vos soins, généralement via Helm.
Les configurations documentées correspondent aux scénarios testés par ABBYY. Vous pouvez adapter votre installation à partir des exemples documentés ; la validation de cette adaptation relève de votre responsabilité.

Prérequis de Vantage operator

Le Vantage operator fonctionne avec Kubernetes et ArgoCD.

Composant	Version	Version testée	Remarques
Kubernetes	Voir la matrice des versions prises en charge	AKS 1.33.6; Kubernetes autogéré 1.36.1	Voir Compatibilité pour la liste complète.
ArgoCD	`>= 2.6.0`	v3.3.2 sur AKS; v3.4.3 sur Kubernetes autogéré	La fonctionnalité ApplicationSet Progressive Syncs doit être activée. ArgoCD a également besoin d’une connexion au référentiel vers votre registre OCI afin de pouvoir récupérer les charts des composants Vantage.
Helm	`>= 3.0.0`	v4.2.0 sur AKS; v3.21.1 sur Kubernetes autogéré	Utilisé pour installer l’opérateur et les charts Vantage.

Exigences au niveau du cluster

Ces services et composants doivent être présents dans le cluster avant d’installer Vantage. Les versions testées sont répertoriées dans Compatibilité.

Component	Notes
Service mesh	Istio sur AKS ou Linkerd sur Kubernetes autogéré. Le maillage doit fournir un mTLS entre charges de travail dans le namespace Vantage. Activez l’injection de namespace appropriée avant d’installer Vantage.
Ingress controller	Le chart inclut un routage d’ingress Istio. Si vous utilisez un autre contrôleur, désactivez l’ingress intégré et implémentez les exigences Vantage en matière de routage, de réécriture, de TLS et de schéma transmis, comme indiqué dans Self-Managed Kubernetes.
Secrets Store CSI driver¶	Le driver lui-même, ainsi que le plugin Azure Key Vault Provider. Obligatoire si vous utilisez le provider de secrets Azure. Rend disponibles, dans les pods au moment de l’exécution, les secrets et certificats de votre coffre de clés dans le cloud.
TLS certificates	Doivent être signés par une autorité de certification publique. Un secret de type `kubernetes.io/tls` valide pour votre valeur `dnsRecord`, dans le même namespace que l’ingress gateway externe Istio.
OCI registry	Registry de destination pour les artefacts Vantage. Le job de migration de l’opérateur y copie les artefacts depuis le registry source ABBYY (`abbyy.jfrog.io`, dépôt `abbyy-docker`). Vos charges de travail récupèrent les images Vantage depuis ce registry : configurez l’accès d’extraction avec des secrets Kubernetes d’extraction d’images ou, sur Azure, en accordant `AcrPull` à l’identité managée AKS. Voir Image pull access.
KEDA 2.17.3 (facultatif, recommandé)	Un composant de mise à l’échelle automatique. Lorsque la prise en charge de KEDA est activée, les réplicas de charge de travail augmentent et diminuent automatiquement en fonction de l’utilisation du système. Les charts de charge de travail Vantage actuels nécessitent KEDA 2.17.x ; n’utilisez pas la version 2.18 ni une version ultérieure. Voir Autoscaling with KEDA.

Prise en charge de KEDA

Certaines ressources KEDA ScaledObject de Vantage dépendent d’une instance Prometheus dans le namespace observability. Le service Prometheus doit être accessible à l’adresse http://prometheus-operated.observability.svc.cluster.local:9090, et il doit collecter les métriques de l’application Vantage via le ServiceMonitor créé par le chart. Consultez Autoscaling with KEDA pour le comportement des déclencheurs et leur vérification, ainsi que Monitoring pour le pipeline de traitement des métriques.

Exigences relatives aux nœuds Kubernetes

Une installation de base de Vantage comprend environ 100 pods (et un niveau de base d’environ 140 lorsque la prise en charge de KEDA est activée). L’environnement de validation AKS utilise 12 nœuds Standard de la famille B à 8 vCPU. Considérez cela comme une configuration de référence testée, et non comme un dimensionnement de production universel : sur un Kubernetes autogéré, prévoyez une capacité d’ordonnancement équivalente ou supérieure, puis dimensionnez en fonction du volume de documents, de la concurrence, de la disponibilité, de la supervision et de la tolérance aux pannes.

Nœuds de travail TechCore

Vantage comprend plusieurs charges de travail appelées “techcore workers”. Ces charges de travail assurent une grande partie du traitement principal de l’application (par opposition aux charges de travail sur lesquelles s’exécutent les applications UI et API). Il est recommandé de dédier un pool de nœuds Kubernetes spécifiquement à ces charges de travail. Pour ce faire, ajoutez le label k8s.abbyy.com/techcore=true au jeu de nœuds sur lesquels les charges de travail des workers TechCore doivent être planifiées. Segmentez davantage les nœuds de travail TechCore en désignant des nœuds spécifiques qui ne doivent pas exécuter les tâches liées à l’entraînement. Les charges de travail liées à l’entraînement possèdent la tolérance suivante :

- key: k8s.abbyy.com/techcore
  operator: Equal
  value: training
  effect: NoSchedule

Vous pouvez ajouter une taint aux nœuds qui ne doivent pas exécuter de charges de travail d’entraînement, en leur appliquant la taint k8s.abbyy.com/techcore=training:NoSchedule. Consultez la documentation officielle de Kubernetes pour en savoir plus sur les taints et les tolérances.

Services externes

Préparez-les avant l’installation. Les produits effectivement testés sont répertoriés dans Compatibilité.

Service	Notes
Serveur de base de données	SQL Server ou PostgreSQL. Vantage nécessite une base de données logique distincte pour chaque alias de chaîne de connexion répertorié dans Secrets and Key Vault. Les bases de données n’ont pas besoin d’exister à l’avance : le migrateur de chaque service crée sa base de données lors de la première exécution. La base de données SQL Server `reporting` doit prendre en charge l’indexation Columnstore. La fonctionnalité de reporting n’est pas disponible avec PostgreSQL.
Redis	Utilisé pour le cache, les verrous et le cache client.
SendGrid†	Fournisseur de messagerie par défaut. Obligatoire sauf si vous configurez SMTP (`spec.smtp`) à la place. Fournissez une `sendgridApiKey` via votre fournisseur de secrets.
Serveur SMTP†	Alternative facultative à SendGrid ; utilisée uniquement lorsque `spec.smtp` est configuré. Seule l’authentification de base, ou l’absence d’authentification, est prise en charge. Voir Known Limitations.
Stockage d’objets	Les chaînes de connexion proviennent de votre fournisseur de secrets. Voir Secrets and Key Vault. Si vous utilisez un backend de stockage personnalisé (`spec.storage.custom`) au lieu du stockage Azure Blob par défaut, le `StorageClass` Kubernetes référencé doit être configuré dans le cluster avant d’installer Vantage.
Backend de secrets¶	Azure Key Vault lors de l’utilisation du fournisseur Azure. Avec le fournisseur Kubernetes, créez au préalable des Secrets Kubernetes natifs directement ou matérialisez-les depuis votre magasin de secrets existant à l’aide d’un outil tel qu’External Secrets Operator. Voir Secrets and Key Vault.

† SendGrid et SMTP s’excluent mutuellement ; un seul des deux est requis. ¶ Obligatoire uniquement lors de l’utilisation du fournisseur de secrets Azure (vantage.secrets.azure). Le fournisseur Kubernetes Secrets (vantage.secrets.kubernetes) lit les ressources Secret préexistantes dans le namespace d’installation et ne nécessite ni le pilote CSI ni un coffre de clés cloud.

Étapes suivantes

Installer sur Azure

Prérequis pour AKS, configuration de l’identité et procédure d’installation.

Kubernetes autogéré

Utilisez votre propre maillage, ingress, secrets, services de données et registry.

Compatibilité

Versions prises en charge de Kubernetes, des distributions et des dépendances.

​Prérequis de Vantage operator

​Exigences au niveau du cluster

​Prise en charge de KEDA

​Exigences relatives aux nœuds Kubernetes

​Nœuds de travail TechCore

​Services externes

​Étapes suivantes