Passer au contenu principal
Vantage 3.0 auto-hébergé est fourni sous la forme de deux charts Helm : vantage-operator (le contrôleur qui surveille la ressource personnalisée Vantage) et vantage-selfhosted (le chart qui crée la ressource Vantage et les manifests associés dans le namespace d’installation choisi). Cette page présente la référence des valeurs pour les deux. Pour plus de détails sur les CRD au niveau des champs, consultez l’référence de l’API. Pour connaître la procédure d’installation, choisissez Azure ou Kubernetes autogéré.
Installez des versions correspondantes de vantage-operator et vantage-selfhosted. La procédure self-managed actuelle utilise la version 0.70.13 pour les deux charts.

​
vantage-operator

Installé une seule fois par cluster, dans le namespace de votre choix. L’operator réconcilie automatiquement l’installation de Vantage définie par la ressource personnalisée Vantage.
N’installez qu’une seule instance par cluster. Le chart utilise des noms de resource à portée cluster non paramétrés (manager-role ClusterRole, manager-rolebinding ClusterRoleBinding, controller-manager ServiceAccount). Une deuxième installation dans le même cluster (même dans un namespace différent) entre en conflit avec ces resources. Voir Known Limitations.

​
Sections de premier niveau

  • nameOverride / fullnameOverride: remplacent partiellement ou entièrement le préfixe généré du nom de la ressource.
  • manager: le Deployment de l’opérateur : replicas, image, args du conteneur (l’élection du leader est activée par défaut), env (nom du pod et namespace via la downward API), imagePullSecrets, contextes de sécurité du pod et du conteneur (non-root, sans élévation de privilèges, système de fichiers racine en lecture seule), resources et planification (affinity, nodeSelector, tolerations).
  • rbacHelpers: ClusterRoles administrateur/editor/viewer facultatifs pour utiliser les CRD vantage.abbyy.com. Désactivés par défaut.
  • crd: cycle de vie des CRD : installer les CRD avec le chart (enable) et les conserver lors de la désinstallation (keep).
  • metrics: le point de terminaison /metrics protégé par RBAC.
  • certManager: intégration de cert-manager pour les certificats du webhook et du point de terminaison des métriques. Désactivée par défaut.
  • prometheus: un ServiceMonitor Prometheus pour le point de terminaison des métriques. Nécessite prometheus-operator dans le cluster. Désactivé par défaut.

​
Valeurs notables

Les valeurs par défaut reflètent le values.yaml généré par le chart pour cette version. Le chart lui-même fait autorité ; voir Consulter les valeurs disponibles. Le chart de l’operator n’accepte aucune configuration de l’application Vantage. La configuration de l’application se trouve entièrement dans la ressource personnalisée Vantage, créée par le chart vantage-selfhosted.

​
vantage-selfhosted

Installé une seule fois par instance Vantage, dans le namespace de votre choix. Ce chart contient la ressource personnalisée Vantage, une ConfigMap contenant les données des charges de travail Vantage avec le RBAC associé, ainsi que les CRD et rôles liés à Vantage issus du dépôt d’infrastructure amont d’ABBYY. La plupart des valeurs sont directement mises en correspondance avec les champs de la ressource personnalisée Vantage. Consultez la référence de l’API pour le contrat de ces champs.

​
Blocs de premier niveau

  • operator : référence à l’installation de l’operator (namespace et controllerManagerServiceAccount). Le chart utilise ces valeurs pour associer le ClusterRole de lecture des secrets de l’operator au namespace de la release Vantage.
  • ingress : configuration de l’ingress Istio intégré. Définissez enabled: false si vous utilisez un autre contrôleur d’ingress.
  • vantage : le contenu de Vantage.spec : databaseProvider, dnsRecord, mailFrom, platformAdminEmail, secrets, vantageVersion, workloads, idReadingEnabled, keda, ociMigration, reportingEnabled, serviceAccountName, smtp, storage, techcore.
  • observability : configuration ServiceMonitor Prometheus générée par le chart. Il s’agit d’un bloc de premier niveau, et non d’un champ Vantage.spec.

​
Valeurs obligatoires

​
Valeurs facultatives

​
Vérification des valeurs disponibles

Le chart vantage-operator, y compris son fichier values.yaml, est généré par le plugin Helm de Kubebuilder ; les modèles du chart vantage-selfhosted, eux, sont maintenus manuellement. Dans les deux cas, le chart publié fait foi quant à ce qu’accepte une version donnée. Les tableaux de cette page résument un instantané testé ; en cas de divergence entre cette page et le chart, fiez-vous au chart :
$charts_uri, $chart_uri et les variables de version suivent les conventions de Install variables. Pour inspecter les manifestes générés avant de les appliquer :

​
Operator vs configuration de Vantage

La configuration se répartit selon une ligne claire :

​
Déploiement des workers TechCore

Le chart vantage-selfhosted applique une ressource personnalisée Vantage ; l’operator déploie ensuite un sous-ensemble des charts de workers TechCore selon spec.techcore.*. La sélection s’effectue dans l’operator, mais la matrice ci-dessous fait foi ; utilisez-la pour prévoir quels workers s’exécuteront pour une configuration donnée.

​
Convention de nommage

Les charts des workers sont nommés vtc-{version}-worker-{name}, où {version} provient de spec.techcore.version et {previousVersion} de spec.techcore.previousVersion. Les numéros de version sont de simples préfixes de nom ; ils n’ont aucune signification sémantique pour l’operator. Le jeu des workers disponibles provient de la ConfigMap des charges de travail qu’ABBYY publie avec chaque version.

​
Deux phases de déploiement

Définir keepPreviousVersion: true permet de laisser les workers de la version précédente de TechCore s’exécuter en parallèle des nouveaux, ce qui est utile pour les mises à niveau progressives de TechCore. La CRD exige que previousVersion soit défini lorsque cet indicateur est défini sur true.

​
Matrice d’inclusion : version actuelle

​
Matrice d’inclusion : version précédente

S’exécute uniquement lorsque spec.techcore.keepPreviousVersion: true.
La lecture d’ID relève de la plateforme, et non de TechCore. L’indicateur qui la contrôle est spec.idReadingEnabled, qui se trouve en dehors de spec.techcore. Consultez la référence Vantage.spec.
La matrice détermine uniquement l’inclusion parmi les workers présents dans la ConfigMap des charges de travail pour la version sélectionnée. Les charts absents des charges de travail de cette version ne sont tout simplement pas disponibles pour le déploiement. Par exemple, worker-ocr-join n’est actuellement livré que dans l’ensemble de charges de travail de vtc-2, donc même avec keepPreviousVersion: true et previousVersion: 2, il est déployé uniquement sous la forme vtc-2-worker-ocr-join.

​
Étapes suivantes

Référence de l’API

Référence détaillée champ par champ de la ressource personnalisée Vantage.

Installation sur Azure

Procédure d’installation utilisant ces charts.

Kubernetes autogéré

Installation avec ingress, maillage, secrets, stockage et services de données gérés par le client.