Prérequis

Infrastructure requise avant l’installation de Vantage 3.0 auto-hébergé.

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 Kubernetes autogéré.
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 fourni par ABBYY ; obtenez l’hôte du registry et le dépôt auprès de votre équipe de compte ABBYY. 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

Vantage répartit ses charges de travail sur trois pools de nœuds : un pool default pour l’UI, l’API et les services de plateforme, un pool TechCore pour les workers de traitement des documents et un pool d’entraînement pour les workers liés à l’entraînement. Appliquez aux pools TechCore et d’entraînement les labels et taints décrits ci-dessous afin d’isoler les tâches de traitement du reste de l’application.

​

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, et appliquez à ces nœuds la taint suivante :

- key: k8s.abbyy.com/techcore
  value: "true"
  effect: NoSchedule

​

Nœuds de travail d’entraînement

Segmentez davantage les nœuds de travail TechCore en désignant des nœuds spécifiques qui doivent 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

Appliquez la taint k8s.abbyy.com/techcore=training:NoSchedule aux nœuds qui doivent exécuter les charges de travail d’entraînement. Seules les charges de travail liées à l’entraînement tolèrent cette taint, de sorte qu’aucune autre charge de travail Vantage n’est planifiée sur ces nœuds.

Consultez la documentation officielle de Kubernetes pour en savoir plus sur les taints et les tolérances.

​

Tailles et nombre de nœuds Kubernetes

Le nombre et la taille des nœuds dépendent du profil d’installation et des composants optionnels que vous activez. Consultez le guide Dimensionnement pour connaître les exigences en CPU, en mémoire et en nombre de pods par pool de nœuds, pour les installations minimales comme pour les installations de production.

​

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, et les volumes qu’il provisionne doivent être accessibles en écriture par un utilisateur non root. Voir Configurer le stockage persistant.
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.

Dimensionnement

Besoins en CPU, en mémoire et en nombre de pods par pool de nœuds.