> ## 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. # 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](/fr/vantage/self-hosted/v3.0/providers/azure) ou [Kubernetes autogéré](/fr/vantage/self-hosted/v3.0/providers/self-managed). **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é](/fr/vantage/self-hosted/v3.0/compatibility#supported-kubernetes-versions) 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](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#enabling-progressive-syncs) doit être activée. ArgoCD a également besoin d’une [connexion au référentiel](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/) 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é](/fr/vantage/self-hosted/v3.0/compatibility). | 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](/fr/vantage/self-hosted/v3.0/providers/self-managed#configure-ingress-and-tls). | | **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](/fr/vantage/self-hosted/v3.0/providers/azure#image-pull-access). | | [KEDA](https://keda.sh/) 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](/fr/vantage/self-hosted/v3.0/performance/autoscaling). |
### Prise en charge de KEDA
Certaines ressources KEDA `ScaledObject` de Vantage dépendent d’une instance [Prometheus](https://prometheus.io/) 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](/fr/vantage/self-hosted/v3.0/performance/autoscaling) pour le comportement des déclencheurs et leur vérification, ainsi que [Monitoring](/fr/vantage/self-hosted/v3.0/monitoring/overview) 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 : ```yaml theme={null} - 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](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) 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é](/fr/vantage/self-hosted/v3.0/compatibility). | 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](/fr/vantage/self-hosted/v3.0/secrets-and-keyvault). 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](/fr/vantage/self-hosted/v3.0/known-limitations#smtp-supports-basic-auth-only). | | **Stockage d’objets** | Les chaînes de connexion proviennent de votre fournisseur de secrets. Voir [Secrets and Key Vault](/fr/vantage/self-hosted/v3.0/secrets-and-keyvault). 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](/fr/vantage/self-hosted/v3.0/secrets-and-keyvault). | † 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
Prérequis pour AKS, configuration de l’identité et procédure d’installation. Utilisez votre propre maillage, ingress, secrets, services de données et registry. Versions prises en charge de Kubernetes, des distributions et des dépendances.