Charts Helm

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 manifestes associés dans l’espace de noms d’installation de votre choix). Cette page présente ces deux charts ainsi que les valeurs que vous serez le plus souvent amené à définir. Pour le détail des champs du CRD, voir Référence de l’API. Pour la procédure d’installation, choisissez Azure ou Kubernetes autogéré.

Installez des versions correspondantes de vantage-operator et de vantage-selfhosted. Les valeurs par défaut indiquées sur cette page sont celles de la dernière version. Certaines valeurs ne sont pas disponibles dans les versions antérieures des artefacts. L’ensemble des valeurs et des valeurs par défaut d’une version donnée figure sur la page des valeurs du chart Helm de cette version ; retrouvez votre version sur la page Versions.

`vantage-operator`

S’installe une seule fois par cluster, dans l’espace de noms 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 de ce chart par cluster. Les objets ClusterRole et ClusterRoleBinding du chart s’appliquent à l’ensemble du cluster et portent des noms fixes. Voir Limitations Connues.

Sections de premier niveau

nameOverride / fullnameOverride : remplace partiellement le nom complet du chart (en conservant le nom de la version) ou le remplace entièrement. Non défini par défaut.
manager : le Deployment de l’operator : image, args du conteneur (l’élection du leader est activée par défaut), env (nom et espace de noms du pod transmis via l’API downward), imagePullSecrets, contextes de sécurité du pod et du conteneur (exécution non-root, aucune élévation de privilèges, système de fichiers root en lecture seule), resources et planification (affinity, nodeSelector, tolerations).
rbacHelpers : rôles admin/editor/viewer facultatifs pour gérer les ressources personnalisées. Désactivé par défaut.
crd : cycle de vie des CRD : installation des CRD avec le chart (enable) et conservation de celles-ci lors de la désinstallation du chart (keep).
metrics : le point de terminaison /metrics, protégé par RBAC.
certManager : intégration de cert-manager pour les certificats TLS, requise pour les certificats du webhook et du point de terminaison des métriques. Désactivé par défaut.
prometheus : un ServiceMonitor Prometheus pour la collecte de métriques. Nécessite que prometheus-operator soit installé dans le cluster. Désactivé par défaut.

Valeurs notables

Les valeurs par défaut sont celles de la dernière version. Pour afficher les valeurs acceptées par une version du chart, voir Consulter les valeurs disponibles.

Valeur	Rôle
`manager.replicas`	Par défaut : `1`.
`manager.image.repository` / `tag` / `pullPolicy`	Image de conteneur de l’operator. `pullPolicy` a pour valeur par défaut `IfNotPresent`.
`manager.imagePullSecrets`	Secrets d’extraction d’images pour l’image de l’operator, si votre registre exige une authentification, par exemple `--set "manager.imagePullSecrets[0].name=my-pull-secret"`. Par défaut : `[]`. Inutile sur AKS si le rôle `AcrPull` est attribué à l’identité du kubelet. Voir Accès pour l’extraction d’images.
`manager.args`	Arguments du conteneur. Par défaut : `[--leader-elect]` (élection du leader activée).
`manager.env`	Variables d’environnement du conteneur de l’operator. Par défaut : `POD_NAME` issu de `metadata.name` et `POD_NAMESPACE` issu de `metadata.namespace` (références de champ).
`manager.podSecurityContext` / `manager.securityContext`	Contextes de sécurité du pod et du conteneur de l’operator. Valeurs par défaut : pour le pod, `runAsNonRoot: true` et `seccompProfile.type: RuntimeDefault` ; pour le conteneur, `allowPrivilegeEscalation: false`, `capabilities.drop: [ALL]` et `readOnlyRootFilesystem: true`.
`manager.resources`	Requêtes et limites de CPU/mémoire. Valeurs par défaut : requêtes de `10m` CPU / `64Mi` de mémoire, limites de `500m` CPU / `128Mi` de mémoire.
`manager.affinity` / `manager.nodeSelector` / `manager.tolerations`	Paramètres de planification Kubernetes standard pour le pod de l’operator. Vides par défaut.
`rbacHelpers.enable`	Installe des rôles prédéfinis admin/editor/viewer pour les CRD. Par défaut : `false`.
`crd.enable`	Installe la CRD `vantages.vantage.abbyy.com` avec le chart. Par défaut : `true`.
`crd.keep`	Conserve les CRD lors de la désinstallation du chart. Par défaut : `true`.
`metrics.enable` / `metrics.port`	Expose le point de terminaison `/metrics`, protégé par RBAC. Par défaut : `true` / `8443`.
`certManager.enable`	Intégration de cert-manager pour les certificats TLS. Obligatoire pour les certificats des webhooks et du point de terminaison des métriques. Par défaut : `false`.
`prometheus.enable`	Crée un `ServiceMonitor` Prometheus pour la collecte de métriques. Nécessite la présence de prometheus-operator dans le cluster. Par défaut : `false`.

La configuration de l’application Vantage est définie dans la ressource personnalisée Vantage, créée par le chart vantage-selfhosted.

`vantage-selfhosted`

S’installe dans l’espace de noms de votre choix. Ce chart contient la ressource personnalisée Vantage, une ConfigMap qui regroupe les données des charges de travail Vantage ainsi que le RBAC associé, et enfin les CRD et les rôles propres à Vantage, issus du référentiel d’infrastructure en amont d’ABBYY. La plupart des valeurs correspondent directement à des champs de la ressource personnalisée Vantage. Consultez la Référence de l’API pour obtenir la spécification détaillée de chaque champ.

Sections de premier niveau

operator : pointeur vers l’installation de l’operator (namespace et controllerManagerServiceAccount).
ingress : l’ingress intégré du chart, sélectionné via ingress.type. Définissez enabled: false si vous gérez vous-même l’ingress, par exemple avec Traefik.
mesh : ressources du maillage Istio (mesh.istio.enabled). Il s’agit d’une section de premier niveau, et non d’un champ de Vantage.spec.
serviceAccounts : ServiceAccounts créés par le chart pour les charges de travail Vantage, le job de migration OCI et les charges de travail individuelles. Il s’agit d’une section de premier niveau, et non d’un champ de Vantage.spec.
vantage : le contenu de Vantage.spec : argocd, databaseProvider, debug, dnsRecord, idReadingEnabled, keda, mailFrom, minimalInstall, ociMigration, platformAdminEmail, reportingEnabled, reverseProxy, secrets, serviceAccountName, smtp, storage, techcore, updatePolicy, vantageVersion, workloads. Ces valeurs sont transmises telles quelles à la ressource personnalisée Vantage.
defaultSkills : compétences par défaut du catalogue fourni que le skill-installer-operator doit installer. Il s’agit d’une section de premier niveau, et non d’un champ de Vantage.spec.
observability : configuration du ServiceMonitor Prometheus générée par le chart. Il s’agit d’une section de premier niveau, et non d’un champ de Vantage.spec.
workloadsConfigMap : contrôle le ConfigMap de charge de travail fourni avec le chart. create détermine si le chart le crée, et additionalMetadata contient des valeurs de remplacement avancées propres au chart. Il s’agit d’une section de premier niveau, et non d’un champ de Vantage.spec.

Valeurs obligatoires

Valeur	Correspondance	Rôle
`operator.namespace`	N/A	Espace de noms dans lequel vous avez installé `vantage-operator`. Par défaut : `vantage-operator-system`.
`operator.controllerManagerServiceAccount`	N/A	ServiceAccount du controller-manager de l’operator. Par défaut : `vantage-operator-controller-manager`.
`ingress.tls.secretName`	N/A	Nom du Secret `kubernetes.io/tls`. Par défaut : `vantage-ingress-tls`. Utilisé lorsque `ingress.enabled` et `ingress.tls.enabled` valent `true`. Avec `ingress.type: istio`, le Secret doit se trouver dans l’espace de noms de l’ingress gateway Istio. Avec `gateway`, créez-le dans l’espace de noms de Vantage ou dans celui défini par `ingress.gateway.certificateRef.namespace`. Avec `gateway` et `ingress.gateway.create: false`, le chart ne l’utilise pas : c’est la Gateway existante qui fournit le certificat.
`vantage.dnsRecord`	`Vantage.spec.dnsRecord`	Nom d’hôte DNS par lequel Vantage est accessible.
`vantage.mailFrom`	`Vantage.spec.mailFrom`	Expéditeur des e-mails sortants.
`vantage.platformAdminEmail`	`Vantage.spec.platformAdminEmail`	Adresse e-mail de l’administrateur de la plateforme.
`vantage.secrets.azure` ou `vantage.secrets.kubernetes`	`Vantage.spec.secrets`	Un fournisseur de secrets, et un seul, est obligatoire. Voir Secrets et Key Vault.
`vantage.secrets.azure.keyVaultName` / `tenantId`	`Vantage.spec.secrets.azure`	Obligatoire avec le fournisseur Azure Key Vault : le Key Vault qui contient les secrets et le locataire Azure AD auquel il appartient.

Valeurs facultatives

Valeur	Rôle
`ingress.enabled`	Crée les ressources d’ingress correspondant à `ingress.type`. Par défaut : `true`. Définissez `false` lorsque vous gérez vous-même l’ingress, par exemple avec un `IngressRoute` Traefik.
`ingress.type`	Ressources d’ingress créées par le chart lorsque `ingress.enabled` vaut `true` : `istio` (par défaut ; `Gateway` et `VirtualService` Istio), `kubernetes` (`Ingress` Kubernetes), `gateway` (`Gateway` et `HTTPRoute` de la Gateway API) ou `native` (`gateway` lorsque le cluster prend en charge la Gateway API, sinon `kubernetes`). `native` détecte la Gateway API à partir des versions d’API du cluster ; `helm template` nécessite donc `--api-versions`, et les CRD de la Gateway API installées dans la même release ne sont pas détectées lors de la première installation. Les CRD et le contrôleur de la Gateway API, ou le contrôleur d’Ingress, doivent déjà être installés. Avec `gateway`, définissez également `vantage.reverseProxy: true`. Avec `kubernetes`, définissez-le lorsque le contrôleur d’ingress assure la terminaison TLS.
`ingress.tls.enabled`	Assure la terminaison TLS avec le Secret désigné par `ingress.tls.secretName`. Par défaut : `true`. Définissez `false` lorsque le contrôleur d’ingress fournit le certificat.
`ingress.istio.ingressGatewaySelector`	Labels permettant de sélectionner l’ingress gateway Istio. Par défaut : `istio: aks-istio-ingressgateway-external`.
`ingress.istio.gateway.labels` / `annotations`	Labels et annotations supplémentaires appliqués à la `Gateway` Istio. Par défaut : `{}`.
`ingress.istio.internalDNSResolution.enabled` / `destination.host`	Fait repasser par l’ingress gateway Istio les appels émis depuis le maillage vers `vantage.dnsRecord` lorsque `vantage.dnsRecord` ne dispose d’aucun enregistrement DNS public. Nécessite le proxy DNS d’Istio. Dans la mesure du possible, utilisez un `vantage.dnsRecord` disposant d’un enregistrement DNS public. Valeurs par défaut : `false` / `aks-istio-ingressgateway-external.aks-istio-ingress.svc.cluster.local`.
`ingress.kubernetes.ingressClassName`	`IngressClass` qui implémente les ressources `Ingress` du chart. Par défaut : `""`. Les réécritures de chemin reposent sur des annotations nginx ; elles ne s’appliquent donc qu’avec la classe `nginx` ou avec `ingress.kubernetes.nginx: true`. Avec nginx, chaque route réécrite dispose de son propre `Ingress`. Avec les autres contrôleurs, les routes réécrites atteignent le bon backend avec le chemin d’origine, et les routes à expression régulière utilisent à la place le préfixe le plus proche.
`ingress.kubernetes.nginx`	Traite la classe d’ingress comme compatible nginx lorsqu’elle ne s’appelle pas `nginx`, par exemple avec le routage d’applications AKS. Par défaut : `false`.
`ingress.kubernetes.labels` / `annotations`	Labels et annotations supplémentaires appliqués aux ressources `Ingress` du chart, par exemple pour contrôler TLS via le contrôleur d’ingress. Par défaut : `{}`.
`ingress.gateway.create`	Crée la `Gateway` de la Gateway API. Par défaut : `true`. Définissez `false` pour rattacher le `HTTPRoute` à une Gateway existante avec `ingress.gateway.parentRefs`.
`ingress.gateway.parentRefs`	`parentRefs` du `HTTPRoute` lorsque `create` vaut `false`, par exemple `name`, `namespace` et `sectionName` d’un écouteur sur une Gateway partagée. Le paramètre `allowedRoutes` de la Gateway doit accepter les routes provenant de l’espace de noms de la release. Par défaut : `[]`.
`ingress.gateway.name` / `gatewayClassName`	Nom et `GatewayClass` de la Gateway créée par le chart. Valeurs par défaut : `vantage-gateway` / `""`. `gatewayClassName` est obligatoire lorsque `create` vaut `true`.
`ingress.gateway.meshIntegrated`	Définissez `true` lorsque l’implémentation de la GatewayClass fait partie du maillage Istio, par exemple l’implémentation de la Gateway API propre à Istio. Avec `mesh.istio.enabled: true`, le chart utilise alors le mTLS `STRICT` (voir `mesh.istio.enabled`). Ne le définissez pas pour une implémentation dont les pods de passerelle reçoivent un sidecar Istio dans l’espace de noms Vantage, par exemple kgateway avec injection de sidecar. Par défaut : `false`.
`ingress.gateway.regexCatchAll`	Génère la route fourre-tout `/` sous forme de correspondance `RegularExpression` (`/.*`) plutôt que de correspondance `PathPrefix`. Définissez `true` pour les implémentations qui font systématiquement primer les correspondances `PathPrefix` sur les correspondances `RegularExpression`, par exemple Istio, où le préfixe `/` masquerait les routes à expression régulière. Par défaut : `false`.
`ingress.gateway.labels` / `annotations`	Labels et annotations supplémentaires appliqués à la `Gateway`, par exemple `cert-manager.io/cluster-issuer` pour que cert-manager émette le certificat dans `ingress.tls.secretName`. Par défaut : `{}`.
`ingress.gateway.infrastructure`	`spec.infrastructure` de la Gateway : labels, annotations et `parametersRef` que l’implémentation propage aux ressources qu’elle crée, comme le Service du répartiteur de charge. Par défaut : `{}`.
`ingress.gateway.listeners.httpsPort` / `httpPort`	Ports des écouteurs HTTPS et HTTP de la Gateway. Valeurs par défaut : `443` / `80`. La Gateway dispose d’un écouteur HTTPS lorsque `ingress.tls.enabled` ou `listeners.controllerSuppliedTls` vaut `true`, et d’un écouteur HTTP dans le cas contraire.
`ingress.gateway.listeners.httpRedirect`	Ajoute un écouteur HTTP dont les requêtes sont redirigées vers HTTPS, lorsque la Gateway dispose d’un écouteur HTTPS. S’applique uniquement lorsque `create` vaut `true`. Par défaut : `false`.
`ingress.gateway.listeners.controllerSuppliedTls` / `tlsOptions`	Avec `ingress.tls.enabled: false`, crée un écouteur HTTPS sans `certificateRefs` au lieu d’un écouteur HTTP, pour les implémentations qui fournissent elles-mêmes le certificat. `tlsOptions` définit les `tls.options` propres à l’implémentation pour l’écouteur HTTPS et est obligatoire avec `controllerSuppliedTls: true`. Valeurs par défaut : `false` / `{}`.
`ingress.gateway.certificateRef.namespace` / `createReferenceGrant`	Espace de noms du Secret `ingress.tls.secretName` lorsqu’il diffère de l’espace de noms de la release. La Gateway ne peut utiliser un Secret situé dans un autre espace de noms que par l’intermédiaire d’un `ReferenceGrant` défini dans cet espace de noms. Avec `createReferenceGrant: true`, le chart le crée ; sinon, créez-le vous-même. S’appliquent uniquement lorsque `create` et `ingress.tls.enabled` valent `true`. Valeurs par défaut : `""` / `false`.
`ingress.gateway.route.labels` / `annotations`	Labels et annotations supplémentaires appliqués aux ressources `HTTPRoute` du chart. Par défaut : `{}`.
`ingress.gateway.route.timeouts`	`timeouts` pour chaque règle `HTTPRoute`. Par défaut : `request: 0s` (aucun délai d’attente de requête). Nécessite que l’implémentation prenne en charge `HTTPRouteRequestTimeout`. Définissez `{}` pour conserver la valeur par défaut de l’implémentation.
`mesh.istio.enabled`	Déploie la configuration de maillage Istio recommandée. Par défaut : `true`. Le mode `PeerAuthentication` du chart est `STRICT` avec l’ingress Istio ou une Gateway intégrée au maillage (`ingress.gateway.meshIntegrated`), et `PERMISSIVE` dans les autres cas. Avec `ingress.type: kubernetes`, cette configuration `PERMISSIVE` est déconseillée en production sans `AuthorizationPolicy` Istio correspondante. Si Istio est votre maillage de services, utilisez l’ingress Istio ou une Gateway intégrée au maillage.
`vantage.vantageVersion`	Version de Vantage à installer. Correspond à `Vantage.spec.vantageVersion`. Par défaut : `""`.
`vantage.databaseProvider`	Moteur de base de données des services Vantage. Valeurs acceptées : `SqlServer` (par défaut) ou `PostgreSQL` ; case-sensitive.
`vantage.secrets.azure.clientId`	Identifiant client de l’identité managée attribuée par l’utilisateur disposant d’un accès en lecture au Key Vault. Avec `identityMode: workloadIdentity` (valeur par défaut), chaque charge de travail utilise l’annotation `azure.workload.identity/client-id` de son ServiceAccount, ou à défaut `clientId`. Correspond à `Vantage.spec.secrets.azure.clientId`.
`vantage.secrets.azure.identityMode`	L’une des valeurs `workloadIdentity` (par défaut), `podIdentity` ou `vmManagedIdentity`. Voir Secrets et Key Vault.
`vantage.secrets.azure.userAssignedIdentityID`	Identifiant client de l’UAMI à utiliser lorsque `identityMode` vaut `vmManagedIdentity`.
`vantage.secrets.azure.objects`	Correspondance alias de secret → `{objectName, objectType, objectVersion}` pour les objets Key Vault dont le nom diffère de l’alias.
`vantage.secrets.kubernetes`	Utilise des ressources `Secret` Kubernetes existantes au lieu d’Azure Key Vault. Le mappage facultatif `objects` remplace les noms de secrets par défaut.
`vantage.smtp.host` / `port` / `useSSL` / `login` / `password`	SMTP sortant. Utilisé uniquement s’il est défini ; SendGrid est utilisé par défaut. Correspond à `Vantage.spec.smtp`. `port` vaut `587` par défaut ; `useSSL` (TLS) vaut `false` par défaut.
`vantage.serviceAccountName`	ServiceAccount par défaut des charges de travail Vantage. Correspond à `Vantage.spec.serviceAccountName`. Valeur par défaut : `default`. Pour extraire des images avec un Secret d’extraction, ajoutez ce Secret aux `imagePullSecrets` de ce ServiceAccount et de chaque ServiceAccount indiqué dans `vantage.workloads.serviceAccounts` (ou définissez `serviceAccounts.imagePullSecrets` lorsque le chart les crée). Voir Accès à l’extraction d’images Azure ou Accès au registre autogéré.
`serviceAccounts.vantage.create` / `name` / `labels` / `annotations` / `imagePullSecrets`	Demande au chart de créer le ServiceAccount des charges de travail Vantage. Valeur par défaut : `create: false`. Le nom correspond par défaut au nom de la release et est défini comme `vantage.serviceAccountName`.
`serviceAccounts.ociMigration.create` / `name` / `labels` / `annotations` / `imagePullSecrets`	Demande au chart de créer le ServiceAccount du job de migration OCI. Valeur par défaut : `create: false`. Le nom vaut par défaut `<release name>-oci-migration` et est défini comme `vantage.ociMigration.serviceAccountName`.
`serviceAccounts.labels` / `annotations` / `imagePullSecrets`	Ajoutés à chaque ServiceAccount créé par le chart. Les étiquettes et annotations définies sur un ServiceAccount donné sont prioritaires. Les secrets d’extraction d’images s’ajoutent à ceux définis sur chaque ServiceAccount. Vide par défaut.
`serviceAccounts.workloads.<chart>.<kind>`	Attribue à une charge de travail son propre ServiceAccount au lieu du ServiceAccount `vantage`. Indexé par nom de chart, puis par type de charge de travail (`migrator`, `deployment` ou `statefulSet`). Chaque entrée prend en charge `create` (par défaut `true`), `name` (par défaut `<chart name without -helm>-<kind>`, par exemple `mail-migrator` ; obligatoire lorsque `create` vaut `false`), `labels`, `annotations`, `imagePullSecrets` et `roles`. Chaque ServiceAccount est lié aux `roles`, qui valent par défaut `migration-writer` et `serviceversion-reader` pour les outils de migration, et `migration-reader` et `serviceversion-reader` dans les autres cas. Plusieurs charges de travail peuvent partager un ServiceAccount en utilisant le même nom ; les entrées qui créent un ServiceAccount partagé doivent le configurer de manière identique. Définit `Vantage.spec.workloads.serviceAccounts`. Valeur par défaut : `{}`.
`vantage.workloads.configMap` / `metadataTemplateKey` / `secretsKey` / `workloadsKey` / `additionalMetadataKey`	Clés du ConfigMap de charge de travail fourni avec le chart. Lorsque `workloadsConfigMap.create` vaut `true` (par défaut), le chart nomme le ConfigMap d’après la version du chart et n’utilise `configMap` (par défaut `vantage-workloads`) que comme préfixe du nom. `additionalMetadataKey` (par défaut `additional-metadata.yml`) désigne la clé contenant vos valeurs de remplacement `workloadsConfigMap.additionalMetadata`. Correspond à `Vantage.spec.workloads`.
`vantage.workloads.pods.labels` / `vantage.workloads.pods.charts.<chart>.<kind>.labels`	Étiquettes ajoutées aux pods de toutes les charges de travail ou de certaines d’entre elles, par exemple `azure.workload.identity/use: "true"`. Les étiquettes par chart sont prioritaires. Correspond à `Vantage.spec.workloads.pods`. `<chart>` est le nom complet du chart dans le ConfigMap de charge de travail, par exemple `mail-helm`. `<kind>` vaut `migrator`, `deployment` ou `statefulSet`.
`vantage.storage.custom.storageClass` / `size`	Utilise un stockage reposant sur une `StorageClass` Kubernetes au lieu d’Azure Blob. Correspond à `Vantage.spec.storage.custom`. `size` vaut `300Gi` par défaut.
`vantage.idReadingEnabled`	Active les fonctionnalités de lecture de pièces d’identité. Correspond à `Vantage.spec.idReadingEnabled`. Valeur par défaut : `false`. L’operator ne déploie jamais les charts `worker-id-reading` ; voir Déploiement du processus de traitement TechCore.
`vantage.minimalInstall`	Déploie les charges de travail Vantage avec des configurations de ressources minimales. Correspond à `Vantage.spec.minimalInstall`. Valeur par défaut : `false`. Agit uniquement sur le dimensionnement des charges de travail. À combiner avec `defaultSkills.mode: minimal` ou `custom`.
`vantage.debug`	Déploie les charges de travail Vantage en mode débogage. Correspond à `Vantage.spec.debug`. Valeur par défaut : `false`.
`defaultSkills.mode`	`all` (par défaut ; toutes les versions de chaque compétence par défaut), `minimal` (version la plus récente de chaque compétence, ainsi que les versions épinglées dans le chart) ou `custom` (uniquement `defaultSkills.skills`). `all` est la seule valeur par défaut sûre : les compétences dérivées d’une compétence par défaut cessent de fonctionner si celle-ci n’est pas installée ; réduire le jeu doit donc toujours être un choix délibéré. Les compétences par défaut installées ne peuvent pas être supprimées : choisissez donc le jeu avant la première installation. Les valeurs de remplacement `skill-installer-def-installation` dans `workloadsConfigMap.additionalMetadata` sont prioritaires.
`defaultSkills.skills`	Compétences à installer en mode `custom`, sous forme d’entrées `{id, versions}`. Ignoré dans les autres modes. Omettez `versions` pour obtenir la version la plus récente, indiquez `all` pour toutes les versions ou listez des numéros de version. Un ID ou une version inconnus font échouer le rendu. Valeur par défaut : `[]`.
`workloadsConfigMap.create`	Crée le ConfigMap contenant les données relatives aux charts et aux images nécessaires à l’installation de Vantage, ainsi que le RBAC associé. Valeur par défaut : `true`. Le nom du ConfigMap inclut la version du chart : chaque mise à niveau du chart modifie donc `Vantage.spec.workloads.configMap`, et l’operator met à jour Vantage sur place, aussi bien avec `helm upgrade` qu’avec les outils GitOps qui effectuent le rendu via `helm template`.
`workloadsConfigMap.additionalMetadata`	Valeurs de remplacement avancées par chart, fusionnées dans les métadonnées de charge de travail générées. Valeur par défaut : `{}`. Une entrée pour `charts.skill-installer-def-installation.values.defaultSkills` est prioritaire sur `defaultSkills.mode`. Voir Métadonnées supplémentaires des charges de travail.
`vantage.reportingEnabled`	Active ou désactive les fonctionnalités de reporting SQL Server. Valeur par défaut : `false`. Doit rester à `false` avec PostgreSQL.
`vantage.reverseProxy`	Configure les services applicatifs Vantage pour qu’ils fonctionnent derrière un proxy inverse assurant la terminaison TLS. Valeur par défaut : `false`. Définissez `true` avec `ingress.type: gateway`, ainsi que chaque fois que le contrôleur d’ingress ou un proxy géré par le client assure la terminaison TLS, ce qui est courant avec `ingress.type: kubernetes`. Correspond à `Vantage.spec.reverseProxy`. Voir Schéma HTTPS transféré.
`vantage.argocd.project`	Projet Argo CD des Applications générées par l’operator. Valeur par défaut : `default`. Le projet doit autoriser le cluster et l’espace de noms de destination. Correspond à `Vantage.spec.argocd.project`.
`vantage.updatePolicy.manual` / `auto`	Stratégie de mise à niveau. Correspond à `Vantage.spec.updatePolicy`. Valeur par défaut : `manual: {}` (Vantage n’est mis à niveau que lorsque vous installez de nouvelles versions du chart). Une et une seule stratégie doit être définie, et la CRD rejette `auto`, car les mises à jour automatiques ne sont pas encore prises en charge. Voir `updatePolicy`.
`vantage.ociMigration.enabled`	Exécute le job de migration OCI. Valeur par défaut : `true`.
`vantage.ociMigration.serviceAccountName`	ServiceAccount sous lequel s’exécute le job de migration OCI. Correspond à `Vantage.spec.ociMigration.serviceAccountName`. Pour extraire l’image du job avec un secret de récupération, ajoutez ce secret aux `imagePullSecrets` de ce ServiceAccount.
`vantage.ociMigration.imagePullSecrets`	Secrets d’extraction d’images pour l’image de l’operator qui exécute le job de migration OCI.
`vantage.ociMigration.sources[]`	Registres sources à partir desquels les artefacts Vantage sont copiés. Définissez `sources[0].host` et `sources[0].repository` sur le registre source d’ABBYY. Définissez `sources[].credentialsRef.name` sur un Secret contenant les clés `username` et `password`, ou sur un Secret `kubernetes.io/dockerconfigjson`.
`vantage.ociMigration.sources[].username` / `password`	Identifiants en clair d’un registre source. Valeur par défaut : `""`. En production, utilisez `sources[].credentialsRef.name`, qui est prioritaire.
`vantage.ociMigration.destination.host` / `repository`	Registre de destination dans lequel les artefacts sont copiés. Obligatoire tant que `enabled` vaut `true`. Hôte par défaut : `abbyy.com`. `host` est le nom d’hôte du registre, éventuellement suivi d’un port, sans schéma ni chemin. Indiquez le chemin dans `repository`, par exemple `vantage/images`.
`vantage.ociMigration.destination.username` / `password` / `credentialsRef.name`	Identifiants du registre de destination. `username` et `password` sont en clair et valent `""` par défaut. En production, définissez `credentialsRef.name` sur un Secret contenant les clés `username` et `password`, ou sur un Secret `kubernetes.io/dockerconfigjson`. `credentialsRef` est prioritaire sur `username` et `password`. Correspond à `Vantage.spec.ociMigration.destination`.
`vantage.ociMigration.concurrency`	Nombre d’artefacts copiés en parallèle par le job de migration OCI. Valeur par défaut : `5`.
`vantage.ociMigration.resources`	Demandes et limites du conteneur du job de migration OCI. Valeurs par défaut : demandes de `100m` de CPU / `128Mi` de mémoire, limite de `512Mi` de mémoire, aucune limite de CPU. Toute valeur définie remplace entièrement les valeurs par défaut.
`vantage.keda.enabled`	Indique si KEDA est utilisé pour la mise à l’échelle automatique des charges de travail Vantage. Valeur par défaut : `false`. Les charts actuels des charges de travail Vantage nécessitent KEDA 2.17.x. Voir Mise à l’échelle automatique avec KEDA.
`observability.prometheus.namespace`	Espace de noms dans lequel votre instance Prometheus est installée. Valeur par défaut : `observability`. Les mécanismes de mise à l’échelle automatique KEDA de Vantage interrogent Prometheus à l’adresse `prometheus-operated.observability.svc.cluster.local:9090` ; conservez donc Prometheus dans l’espace de noms `observability`.
`observability.prometheus.serviceMonitor.create`	Crée des ressources Prometheus `ServiceMonitor` pour collecter les métriques applicatives de Vantage. Valeur par défaut : `false`.
`observability.prometheus.serviceMonitor.selectorMatchLabels`	Étiquettes requises par votre instance Prometheus pour enregistrer un `ServiceMonitor`. Elles doivent correspondre au champ `spec.serviceMonitorSelector.matchLabels` de votre ressource `Prometheus`. Valeur par défaut : `{}`.
`observability.prometheus.serviceMonitor.interval`	Fréquence à laquelle Prometheus collecte les métriques de Vantage. Comme KEDA s’appuie sur ces métriques, l’intervalle détermine aussi la réactivité des agents de traitement TechCore face aux tâches en file d’attente. Valeur par défaut : `15s`, ou `60s` lorsque `vantage.minimalInstall` vaut `true`. Voir Mise à l’échelle automatique avec KEDA.
`observability.prometheus.serviceMonitor.scheme`	Schéma des points de terminaison de collecte du `ServiceMonitor`. Non défini par défaut (HTTP). Définissez `https`, avec `tlsConfig`, avec Istio en mTLS `STRICT`, ou avec Linkerd lorsqu’une stratégie d’autorisation bloque les collectes en texte clair. Ne le définissez pas avec Istio en mTLS `PERMISSIVE`. Voir Surveillance avec Prometheus.
`observability.prometheus.serviceMonitor.tlsConfig`	`tlsConfig` Prometheus pour les points de terminaison de collecte du `ServiceMonitor` (`caFile`, `certFile`, `keyFile`, `insecureSkipVerify`). Non défini par défaut. À utiliser avec `scheme: https`.
`vantage.techcore.versions`	Versions de TechCore à déployer. Valeurs acceptées : `2`, `3`, `4`. Valeur par défaut : `[3, 4]`. La version la plus élevée correspond à la version actuelle. Voir Déploiement des agents de traitement TechCore.
`vantage.techcore.nnTrainingWorkers.enabled` / `gpu`	Déploie les processus de travail d’entraînement des réseaux de neurones pour la version actuelle (la plus élevée) de TechCore. `gpu: true` déploie les variantes GPU au lieu des variantes CPU. Valeurs par défaut : `false` / `false`.

Consulter les valeurs disponibles

Le chart vantage-operator est généré par le module complémentaire Helm de Kubebuilder. Dans le chart vantage-selfhosted, les modèles de la ressource personnalisée Vantage et du ConfigMap de charge de travail sont maintenus manuellement. Pour afficher les valeurs acceptées par une version donnée du chart :

# vantage-operator
helm show values $charts_uri/vantage-operator --version $operator_version

# vantage-selfhosted
helm show values $chart_uri/vantage-selfhosted --version $selfhosted_version

$charts_uri, $chart_uri et les variables de version suivent les conventions décrites dans Variables d’installation. Pour examiner les manifestes générés avant de les appliquer :

helm template $release_name $chart_uri/vantage-selfhosted \
  --version $selfhosted_version \
  --namespace $install_namespace \
  -f my-values.yaml

Configuration de l’operator et configuration de Vantage

Domaine	Emplacement
Environnement d’exécution de l’operator (image, secrets d’extraction d’images, planification, cycle de vie des CRD, métriques)	Valeurs Helm de `vantage-operator`
Application Vantage (secrets, SMTP, charges de travail, stockage, techcore)	Valeurs Helm de `vantage-selfhosted` → `Vantage.spec`

Déploiement des agents de traitement TechCore

Le chart vantage-selfhosted applique une ressource personnalisée Vantage ; l’operator déploie ensuite un sous-ensemble des charts des agents de traitement TechCore en fonction des paramètres spec.techcore.*, comme l’indiquent les matrices ci-dessous.

Convention de nommage

Les charts d’unités de traitement sont nommés vtc-{version}-worker-{name}-helm, où {version} correspond à une version répertoriée dans spec.techcore.versions. Les numéros de version ne sont que de simples préfixes de nom : ils n’ont aucune signification sémantique pour l’operator. La liste des unités de traitement disponibles provient du ConfigMap de charge de travail fourni avec le chart vantage-selfhosted.

Deux passes de déploiement

Passe	Versions	Charts pris en compte
Version actuelle	La version la plus élevée de `spec.techcore.versions`	`vtc-{version}-worker*`
Versions précédentes	Toutes les autres versions de `spec.techcore.versions`	`vtc-{version}-worker*`

Les charts d’unités de traitement des versions absentes de spec.techcore.versions ne sont pas déployés. Pour que les unités de traitement d’une version antérieure de TechCore continuent de s’exécuter parallèlement à la version actuelle, indiquez les deux versions. La valeur par défaut du chart, [3, 4], déploie TechCore 4 en tant que version actuelle et TechCore 3 en tant que version précédente.

Matrice d’inclusion : passe de la version actuelle

Motif de chart	Inclus si
`worker-id-reading`	Jamais (exclu dans toutes les configurations)
`nn-extraction-training`	`nnTrainingWorkers.enabled: true` et `nnTrainingWorkers.gpu: false`
`nn-extraction-training-gpu`	`nnTrainingWorkers.enabled: true` et `nnTrainingWorkers.gpu: true`
`nn-nlp-model-train`	`nnTrainingWorkers.enabled: true` et `nnTrainingWorkers.gpu: false`
`nn-nlp-model-train-gpu`	`nnTrainingWorkers.enabled: true` et `nnTrainingWorkers.gpu: true`
Toutes les autres unités de traitement	Toujours

Matrice d’inclusion : passe des versions précédentes

S’exécute pour chaque version de spec.techcore.versions, à l’exception de la plus élevée.

Motif de chart	Inclus lorsque
`worker-id-reading`	Jamais
`nn-extraction-training*` (CPU et GPU)	Jamais (l’entraînement NN ne s’exécute que sur la version actuelle)
`nn-nlp-model-train*` (CPU et GPU)	Jamais (l’entraînement NN ne s’exécute que sur la version actuelle)
Toutes les autres unités de traitement	Toujours

La lecture de documents d’identité relève de la plateforme, et non de TechCore. Son indicateur, spec.idReadingEnabled, se trouve en dehors de spec.techcore. Les charts worker-id-reading ne sont jamais déployés. Voir la référence Vantage.spec.

La matrice détermine uniquement l’inclusion parmi les unités de traitement présentes dans le ConfigMap de charge de travail de la version sélectionnée. Les charts absents de la charge de travail de cette version ne sont tout simplement pas disponibles au déploiement. Par exemple, worker-ocr-join n’est actuellement fourni que dans l’ensemble de charges de travail de vtc-2 : il n’est donc déployé que lorsque spec.techcore.versions inclut 2, sous le nom vtc-2-worker-ocr-join-helm.

Étapes suivantes

Référence de l’API

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

Installer sur Azure

La procédure d’installation qui s’appuie sur ces charts.

Kubernetes autogéré

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

Configuration

Lifecycle

Monitoring

Performance

Diagnostics

Migration

`vantage-operator`

Sections de premier niveau

Valeurs notables

`vantage-selfhosted`

Sections de premier niveau

Valeurs obligatoires

Valeurs facultatives

Consulter les valeurs disponibles

Configuration de l’operator et configuration de Vantage

Déploiement des agents de traitement TechCore

Convention de nommage

Deux passes de déploiement

Matrice d’inclusion : passe de la version actuelle

Matrice d’inclusion : passe des versions précédentes

Étapes suivantes

Référence de l’API

Installer sur Azure

Kubernetes autogéré

​vantage-operator

​Sections de premier niveau

​Valeurs notables

​vantage-selfhosted

​Sections de premier niveau

​Valeurs obligatoires

​Valeurs facultatives

​Consulter les valeurs disponibles

​Configuration de l’operator et configuration de Vantage

​Déploiement des agents de traitement TechCore

​Convention de nommage

​Deux passes de déploiement

​Matrice d’inclusion : passe de la version actuelle

​Matrice d’inclusion : passe des versions précédentes

​Étapes suivantes

Référence de l’API

Installer sur Azure

Kubernetes autogéré

`vantage-operator`

Sections de premier niveau

Valeurs notables

`vantage-selfhosted`

Sections de premier niveau

Valeurs obligatoires

Valeurs facultatives

Consulter les valeurs disponibles

Configuration de l’operator et configuration de Vantage

Déploiement des agents de traitement TechCore

Convention de nommage

Deux passes de déploiement

Matrice d’inclusion : passe de la version actuelle

Matrice d’inclusion : passe des versions précédentes

Étapes suivantes