Compatibilité

Versions de Kubernetes, distributions et versions des dépendances prises en charge pour l’opérateur Vantage 3.0.

L’opérateur Vantage fonctionne avec les API Kubernetes standard. Les tableaux ci-dessous indiquent quelles versions de Kubernetes, distributions et versions des dépendances sont prises en charge et testées pour Vantage 3.0 auto-hébergé.

Pour la liste de contrôle à l’installation (services à provisionner, secrets à créer), consultez Prérequis.

​

Versions de Kubernetes prises en charge

L’opérateur cible l’API standard de Kubernetes. La compatibilité des versions est limitée par la propre matrice de prise en charge de Kubernetes d’ArgoCD.

Kubernetes	Prise en charge
1.33	Testée (AKS 1.33.6)
1.36	Testée (Kubernetes autogéré 1.36.1)

D’autres versions de Kubernetes incluses dans la matrice de prise en charge d’ArgoCD peuvent fonctionner, mais ne sont pas validées. Confirmez avec votre ABBYY account team avant d’exécuter sur une version de Kubernetes qui n’est pas répertoriée ici.

​

Distributions de Kubernetes prises en charge

Distribution	Niveau de prise en charge	Remarques
Azure Kubernetes Service (AKS)	Pris en charge	Validation de bout en bout sur AKS 1.33.6 avec l’AKS Istio Add-on (asm-1-28). Voir Installer sur Azure.
Kubernetes autogéré	Pris en charge	Validé avec une mise en réseau gérée par le client, Linkerd, Traefik, les secrets Kubernetes natifs, PostgreSQL et une StorageClass personnalisée. Voir Kubernetes autogéré.

Utilisez une version de Kubernetes indiquée ci-dessus. Les distributions Kubernetes et les substitutions de composants qui ne sont pas répertoriées n’ont pas été validées ; confirmez-les auprès de votre équipe ABBYY en charge du compte avant toute utilisation en production.

​

Versions des dépendances

L’opérateur dépend des composants suivants dans le cluster.

Composant	Obligatoire	Testé	Remarques
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. Une connexion au dépôt de votre registre OCI est également requise.
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-selfhosted.
Istio	toute version	AKS Istio Add-on asm-1-28	Maillage de services et chemin d’ingress intégré testés sur AKS. Le mode mTLS STRICT est appliqué au trafic applicatif. Une ingress gateway externe est requise sur AKS.
Linkerd	toute version compatible	edge-26.6.1	Maillage de services testé pour Kubernetes autogéré. Activez l’injection dans le namespace Vantage avant d’installer Vantage.
Traefik	v3	Helm chart 39.x	Contrôleur d’ingress testé pour Kubernetes autogéré. Désactivez l’ingress Istio intégrée du chart et implémentez le contrat de routage Vantage documenté.
Secrets Store CSI Driver (Azure fournisseur)	>= 1.0.0	1.7.2 (Helm chart 1.7.2)	Obligatoire lors de l’utilisation du fournisseur de secrets Azure Key Vault. Non obligatoire lors de l’utilisation du fournisseur Kubernetes Secrets.
External Secrets Operator	toute version compatible	Helm chart 2.6.0	Exemple facultatif pour matérialiser des Kubernetes Secrets natifs à partir d’un magasin externe. Vantage consomme les Kubernetes Secrets, et non External Secrets ou le magasin externe directement.
csi-driver-nfs	toute version compatible	Helm chart 4.13.4	Exemple facultatif de provisionneur NFS pour spec.storage.custom sur Kubernetes autogéré. Définissez mountPermissions: "0777" sur la StorageClass ; les volumes provisionnés doivent être accessibles en écriture par des utilisateurs non-root.
KEDA (facultatif, recommandé)	>= 2.17.0, < 2.18.0	2.17.3 ; module complémentaire AKS 2.17.3-5	Obligatoire pour la prise en charge de la mise à l’échelle automatique KEDA. KEDA 2.18 et les versions ultérieures ont supprimé un champ de scaler utilisé par les charts de charge de travail Vantage actuels.
Prometheus Operator (obligatoire avec KEDA)	toute version compatible	kube-prometheus-stack 87.3.0	Fournissez une instance Prometheus à prometheus-operated.observability.svc.cluster.local:9090 et détectez le ServiceMonitor Vantage.

​

Versions des services de support

Il s’agit de dépendances externes provisionnées en dehors du cluster. Le tableau regroupe les versions et les implémentations testées pour les modes de déploiement pris en charge :

Service	Version testée	Notes
SQL Server	Azure SQL 12.0.2000.8 (niveau de compatibilité 170, General Purpose Serverless Gen 5)	Une base de données par alias de chaîne de connexion répertorié dans Secrets and Key Vault (23 actuellement). La base de données reporting doit prendre en charge les index columnstore.
PostgreSQL	La prise en charge du provider a été validée avec le déploiement autogéré	Définissez vantage.databaseProvider: PostgreSQL. Utilisez une base de données logique distincte par service ; l’outil de migration de chaque service crée sa base de données lors de la première exécution. Le reporting n’est pas pris en charge avec PostgreSQL.
Redis	Azure Managed Redis 7.4 (EnterpriseCluster) ; Redis 7.4 sur Kubernetes autogéré
SendGrid	n/a	Fournisseur de messagerie par défaut. Fournissez sendgridApiKey via votre fournisseur de secrets.
Serveur SMTP	MailHog v1.0.1 (Helm chart 5.8.0)	Alternative facultative à SendGrid. Seule l’authentification Basic ou l’absence d’authentification est prise en charge. Utilisé uniquement lorsque spec.smtp est défini.
Registre OCI	Azure Container Registry	Authentification pour la migration : sans authentification, authentification Basic ou Azure Workload Identity + Azure RBAC. Récupération des images : secrets d’extraction Kubernetes ou, sur Azure, AcrPull accordé à l’identité managée AKS. Voir Image pull access.
Stockage	Azure StorageV2 (usage général v2) ; StorageClass Kubernetes fournie par le client	Azure Blob est le backend par défaut. Un backend personnalisé reposant sur StorageClass peut être utilisé via spec.storage.custom.
Backend de secrets	Azure Key Vault ; chart HashiCorp Vault 0.33.0 comme exemple autogéré	Azure Key Vault est lu via le provider CSI. Les autres magasins doivent créer des Secrets Kubernetes natifs pour le provider Kubernetes.

​

Versions de l’application Vantage

L’opérateur définit la version de l’application Vantage via spec.vantageVersion dans la ressource personnalisée Vantage. Installez des versions correspondantes des charts vantage-operator et vantage-selfhosted ; le guide actuel pour l’environnement autogéré utilise 0.70.13. Voir Upgrading.

​

Et après

Architecture

Fonctionnement du schéma opérateur + ArgoCD + CRD.

Prérequis

Liste de vérification du provisionnement du cluster, des secrets et des certificats.