Architecture

Comment l’opérateur Kubernetes Vantage, la ressource personnalisée Vantage et ArgoCD fonctionnent ensemble pour installer, configurer et mettre à jour Vantage 3.0 auto-hébergé.

Vantage 3.0 auto-hébergé s’articule autour de trois composants : un opérateur Kubernetes, une ressource personnalisée unique exposée à l’utilisateur (Vantage) et ArgoCD. Vous appliquez un objet Vantage qui décrit l’installation souhaitée ; l’opérateur réconcilie automatiquement l’état de l’installation avec la ressource, en déléguant à ArgoCD la synchronisation de chaque composant. Cette page présente ces différents éléments d’un point de vue conceptuel. Pour plus de détails au niveau des champs, consultez la référence API.

​

Pourquoi cette approche

Vantage 2.7 auto-hébergé s’appuyait sur des playbooks Ansible fournis par ABBYY et des scripts Azure CLI qui installaient à la fois l’application et l’infrastructure associée en une seule fois. Ce modèle n’est pas pris en charge dans la version 3.0. L’opérateur 3.0 sépare les responsabilités :

• Infrastructure : provisionnée par vos soins, hors du périmètre de l’opérateur. ABBYY ne fournit pas d’automatisation du provisionnement pour la version 3.0.
• Application : décrite de manière déclarative dans la ressource Vantage. L’opérateur gère la résolution des dépendances pour les composants Vantage Core, la migration des artefacts et la réconciliation via ArgoCD.

Les logiciels tiers sur lesquels Vantage s’appuie, comme ArgoCD, votre maillage de services et votre contrôleur d’ingress, votre intégration des secrets et votre stack de monitoring, ne relèvent d’aucun de ces deux périmètres : vous devez les installer vous-même avant d’installer Vantage.

Résultat : les mises à niveau s’effectuent en installant les nouvelles versions correspondantes des charts Helm vantage-operator et vantage-selfhosted.

​

La ressource personnalisée Vantage

La CRD est enregistrée sous vantage.abbyy.com/v1alpha1. Une ressource minimale se présente ainsi (à titre d’illustration ; voir la référence API pour la spécification complète) :

apiVersion: vantage.abbyy.com/v1alpha1
kind: Vantage
metadata:
  name: vantage
  namespace: vantage
spec:
  dnsRecord: vantage.example.com
  mailFrom: [e-mail]
  platformAdminEmail: [e-mail]
  vantageVersion: "3.0.x"
  secrets:
    azure:
      keyVaultName: mykeyvault
      tenantId: 00000000-...
      clientId: 00000000-... # ID client de l'UAMI avec accès en lecture au Key Vault
      identityMode: workloadIdentity # workloadIdentity (default) | podIdentity | vmManagedIdentity
  smtp:
    host: smtp.example.com
    port: 587
  workloads:
    configMap: vantage-workloads
    metadataTemplateKey: metadata
    secretsKey: secrets
    workloadsKey: workloads

spec.secrets est obligatoire, et un seul fournisseur (azure ou kubernetes) doit être spécifié. spec.smtp est facultatif ; omettez-le pour utiliser le fournisseur de messagerie SendGrid par défaut (fournissez une sendgridApiKey via votre fournisseur de secrets). Voir Secrets and Key Vault pour connaître les fournisseurs pris en charge.

En pratique, vous définissez la plupart de ces valeurs via le chart Helm vantage-selfhosted. Voir Azure ou Kubernetes autogéré.

​

Concepts clés

​

ConfigMap des charges de travail

spec.workloads indique à l’opérateur une ConfigMap contenant le manifeste des charts et des images qui composent une version de Vantage. L’opérateur lit ce manifeste, effectue la migration OCI pour copier les artefacts dans votre registre, puis génère des manifestes ArgoCD Application pour chaque composant. La ConfigMap est générée et publiée par ABBYY pour chaque version de Vantage.

​

Secrets et certificats

L’opérateur ne stocke pas directement les secrets. Deux fournisseurs de secrets sont pris en charge (Azure Key Vault via le Secrets Store CSI driver, et des ressources Kubernetes Secret préexistantes), et un seul est configuré pour chaque installation. Voir Secrets and Key Vault pour connaître les fournisseurs pris en charge, les modes d’identité et l’inventaire complet des alias.

​

Migration OCI

spec.ociMigration déclare un job ponctuel qui copie des artefacts depuis un ou plusieurs registres sources configurés vers votre registre de destination avant l’installation. Une fois la migration terminée, tous les téléchargements ultérieurs de composants se font depuis votre propre registre. ArgoCD récupère les charts des composants depuis ce registre via une connexion au dépôt que vous configurez vous-même. L’authentification du registre de destination prend en charge l’absence d’authentification, l’authentification basique ou Azure Workload Identity avec Azure RBAC. Les charges de travail doivent également disposer d’un accès de pull via des Secrets Kubernetes d’extraction d’images ou, sur Azure, de l’autorisation AcrPull accordée à l’identité managée AKS. Voir Accès de pull d’images Azure ou accès au registre autogéré.

​

Installation des Skills

Les Skills sont installés par un job Kubernetes distinct dans le namespace d’installation, et non par l’une des applications ArgoCD générées par l’opérateur. ArgoCD n’affiche donc pas la progression de l’installation des Skills. La ressource Vantage peut indiquer l’état Ready alors que le job est toujours en cours d’exécution, et Vantage reste utilisable entre-temps. Les commandes de surveillance figurent dans Cycle de vie.

​

Contrat du Runtime

Le contrat du Runtime de l’opérateur (la façon dont il traite la ressource Vantage, les conditions qu’il renvoie et la manière de forcer une nouvelle tentative) est documenté séparément de cette présentation conceptuelle. Voir cycle de vie.

​

Pour la suite

Référence API

Référence détaillée de chaque propriété de spec et de status.

Cycle de vie

Phases de réconciliation, conditions de status et forçage d’une nouvelle tentative.

Valeurs du chart Helm

Référence de chaque valeur Helm acceptée par l’opérateur et les charts Vantage.

Dépannage

Diagnostic des problèmes courants liés à l’opérateur, à ArgoCD, aux secrets, à la base de données, à l’ingress et au maillage.