> ## 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. # Kubernetes autogéré > Déployez Vantage 3.0 auto-hébergé sur une infrastructure Kubernetes que vous provisionnez et administrez. Ce guide explique comment déployer Vantage 3.0 auto-hébergé sur un cluster Kubernetes que vous provisionnez et administrez. Il définit les interfaces que le cluster doit fournir à Vantage et utilise Linkerd, Traefik et External Secrets avec HashiCorp Vault comme exemples. Vous pouvez utiliser des composants équivalents qui répondent aux mêmes exigences. Ce guide suppose qu’un cluster Kubernetes est déjà en cours d’exécution. Il n’installe pas Kubernetes, le maillage de services, le contrôleur d’ingress, le système de gestion des secrets, les bases de données, le stockage ni les registres pour vous. Les charts `vantage-operator` et `vantage-selfhosted` doivent utiliser la même version. Les exemples de cette page utilisent la version `0.70.13` pour les deux charts.

Architecture de référence

| Aspect | Exigence de Vantage | Exemple d’implémentation | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | Kubernetes | Une version de Kubernetes prise en charge, avec un DNS, une connectivité réseau et des volumes persistants opérationnels. | Le cluster Kubernetes que vous exploitez. | | Orchestration du déploiement | ArgoCD avec ApplicationSet Progressive Syncs activés. | ArgoCD 3.4.3. | | Maillage de services | mTLS entre charges de travail dans l’espace de noms Vantage. | Linkerd. | | Ingress | Un ingress HTTPS qui implémente les règles de chemin et de réécriture de Vantage, et qui préserve le schéma d’origine de la requête. | Traefik avec cert-manager. | | Secrets | Des ressources Kubernetes `Secret` natives dans l’espace de noms Vantage. | External Secrets Operator matérialisant des Secrets depuis HashiCorp Vault. | | Base de données | SQL Server ou PostgreSQL, avec une base de données logique distincte pour chaque service Vantage. | PostgreSQL. | | Cache | Redis. | Redis 7.4. | | Messagerie | SendGrid par défaut, ou un serveur SMTP. | SendGrid. | | Stockage | Une `StorageClass` Kubernetes préexistante, adaptée à vos exigences en matière de disponibilité et de durabilité. | Une classe de stockage persistant fournie par le client. | | Registres | Un registre source fourni pour les artefacts Vantage et un registre de destination que vous exploitez. | Tout registre privé compatible OCI. | | Mise à l’échelle automatique et métriques | KEDA et Prometheus lorsque la prise en charge de KEDA est activée. | KEDA 2.17.3 et Prometheus Operator. | Pour connaître les versions des composants prises en charge et testées, consultez [Compatibilité](/fr/vantage/self-hosted/v3.0/compatibility). Pour l’inventaire complet de l’infrastructure et la base de dimensionnement, consultez [Prérequis](/fr/vantage/self-hosted/v3.0/prerequisites).

Avant de commencer

Préparez les valeurs et ressources suivantes : | Variable | Description | | -------------------------------------------------------- | ------------------------------------------------------------------------ | | `$operator_namespace` | Espace de noms de l’opérateur Vantage. | | `$install_namespace` | Espace de noms des charges de travail Vantage. | | `$operator_version` | Version du chart `vantage-operator`. Utilisez `0.70.13` pour ce guide. | | `$selfhosted_version` | Version du chart `vantage-selfhosted`. Utilisez `0.70.13` pour ce guide. | | `$charts_uri` | URI OCI fournie par ABBYY pour le chart de l’opérateur Vantage. | | `$chart_uri` | URI OCI fournie par ABBYY pour le chart `vantage-selfhosted`. | | `$release_name` | Nom de release Helm pour Vantage. | | `$your_vantage_hostname` | Nom d’hôte DNS de Vantage. | | `$your_mailfrom` | Adresse de l’expéditeur pour les e-mails sortants. | | `$your_platformadmin_email` | Adresse e-mail initiale de l’administrateur de la plateforme. | | `$your_oci_host` | Registre OCI de destination que vous exploitez. | | `$abbyy_oci_source_host`, `$abbyy_oci_source_repository` | Registre source et dépôt fournis pour les artefacts Vantage. | Vous avez également besoin de : * D’un enregistrement DNS pour `$your_vantage_hostname` qui pointe vers votre point d’entrée ingress. * D’un certificat TLS valide pour ce nom d’hôte. * De Secrets Kubernetes de pull depuis le registre si votre registre nécessite une authentification. * De chaque Secret d’application répertorié sous [Alias de Secrets](/fr/vantage/self-hosted/v3.0/secrets-and-keyvault#secret-aliases). * D’un nom de base de données logique distinct pour chaque alias de base de données. Le migrateur de chaque service crée sa base de données lors de sa première exécution. * De nœuds étiquetés pour les workers TechCore.

Préparer le cluster

Configurer ArgoCD

Installez ArgoCD et activez [ApplicationSet Progressive Syncs](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#enabling-progressive-syncs). ArgoCD nécessite également une connexion à un référentiel OCI capable d’extraire les charts des composants Vantage depuis votre registre de destination. Enregistrez le registre de destination en tant que référentiel Helm OCI en suivant la [documentation d’ArgoCD sur les dépôts privés](https://argo-cd.readthedocs.io/en/stable/user-guide/private-repositories/). Conservez les identifiants du registre dans votre système de gestion des secrets existant plutôt que de placer directement des identifiants dans un manifeste ArgoCD `Application`.

Configurer le maillage de services

Vantage nécessite l’utilisation de mTLS entre ses charges de travail. Installez et utilisez un maillage de services pris en charge, puis activez l’injection du maillage pour `$install_namespace` avant d’installer Vantage. Par exemple, avec Linkerd : ```bash theme={null} kubectl create namespace $install_namespace --dry-run=client -o yaml | kubectl apply -f - kubectl label namespace $install_namespace linkerd.io/inject=enabled --overwrite ``` Vérifiez que les pods de test nouvellement créés dans l’espace de noms reçoivent bien le sidecar du maillage avant de poursuivre. Si vous utilisez un autre maillage, suivez sa procédure d’injection au niveau de l’espace de noms ou de la charge de travail.

Configurer les nœuds de travail TechCore

Les charges de travail des workers TechCore sont planifiées sur les nœuds portant le label `k8s.abbyy.com/techcore=true`. Appliquez un label et une taint à chaque nœud du pool TechCore : ```bash theme={null} kubectl label node k8s.abbyy.com/techcore=true kubectl taint node k8s.abbyy.com/techcore=true:NoSchedule ``` En l'absence d'au moins un nœud correspondant, les pods TechCore restent à l'état `Pending`. Pour l'isolation des workers d'entraînement, consultez [Exigences relatives aux nœuds Kubernetes](/fr/vantage/self-hosted/v3.0/prerequisites#kubernetes-node-requirements) ; pour la capacité par pool, consultez [Dimensionnement](/fr/vantage/self-hosted/v3.0/sizing).

Configurer le stockage persistant

Créez ou sélectionnez une `StorageClass` avant d’installer Vantage. La solution de stockage doit répondre à vos exigences de production en matière de disponibilité, de durabilité, de capacité, d’extension, de sauvegarde et de restauration. Référencez-la dans les valeurs de Vantage : ```yaml theme={null} vantage: storage: custom: storageClass: size: 300Gi ``` Le nom `StorageClass` est indépendant de la distribution Kubernetes. Ne copiez pas en production la classe de stockage local d’un cluster de développement sans avoir évalué ses caractéristiques en matière de perte de données et de basculement. Vantage provisionne ses propres `PersistentVolumeClaims` sur la classe que vous indiquez. Deux exigences s’appliquent à toute `StorageClass` : * **Les volumes provisionnés doivent être accessibles en écriture par un utilisateur non-root.** Les services Vantage s’exécutent avec un utilisateur non-root. Si le répertoire de montage d’un volume appartient à root et n’est pas accessible en écriture pour l’utilisateur du conteneur (par exemple, mode `0755`), le service blobstorage échoue lors de sa vérification du système de fichiers au démarrage, l’initialisation de l’hôte est abandonnée et chaque service qui dépend du stockage passe à l’état `Degraded`. * **Le `storageClassName` d’un PVC est immuable.** Pour déplacer une installation existante vers une autre `StorageClass`, supprimez et recréez les PVC de l’opérateur sur la nouvelle classe. Une classe locale au nœud associe chaque PVC au disque d’un seul nœud. Pour un stockage partagé entre les nœuds, l’exemple testé est NFS via [csi-driver-nfs](https://github.com/kubernetes-csi/csi-driver-nfs), qui fournit une `StorageClass` `nfs`. Le plugin de nœud du pilote inclut les utilitaires de montage NFS, de sorte que les nœuds du cluster n’ont besoin d’aucun package NFS supplémentaire. ```yaml theme={null} vantage: storage: custom: storageClass: nfs size: 300Gi ``` Lors de l’utilisation de csi-driver-nfs : * Le pilote nécessite un serveur NFSv3 ou NFSv4 existant et déjà configuré. Vantage ne fournit ni ne gère le pilote ni le serveur ; vous devez installer et exploiter les deux. * Définissez `mountPermissions: "0777"` sur la `StorageClass`. Le provisioner crée le sous-répertoire de chaque volume, dont le propriétaire est root, et un répertoire `0755` n’est pas accessible en écriture pour l’utilisateur de service Vantage. * Le serveur NFS doit être accessible depuis chaque nœud et exporter son partage avec `rw,sync,all_squash,insecure,no_subtree_check,anonuid=65532,anongid=65532`. Le mappage `all_squash` avec `anonuid`/`anongid` présente chaque client, y compris le pilote CSI, avec l’uid/gid `65532`, ce qui correspond au contexte de sécurité du pod Vantage. `insecure` autorise les connexions depuis les ports non privilégiés qu’utilisent les clients NFS conteneurisés ; sans cela, le serveur rejette ces connexions silencieusement et les écritures sur le stockage échouent sans erreur visible. * Le répertoire racine exporté doit appartenir à `65532:65532` avec le mode `0755`. Après avoir modifié `/etc/exports` ou le propriétaire sur un serveur en cours d’exécution, réexportez avec `exportfs -ra`.

Préparer les bases de données

Vantage prend en charge SQL Server et PostgreSQL. Définissez le fournisseur exactement comme indiqué ; la valeur est sensible à la casse : ```yaml theme={null} vantage: databaseProvider: PostgreSQL ``` Les valeurs valides sont `SqlServer` et `PostgreSQL`. Une valeur telle que `Postgresql` ou `PostgreSql` peut échouer à l’exécution, car elle ne correspond pas au nom du fournisseur de données de l’application. Chaque service Vantage doit utiliser une base de données logique distincte. Les services exécutent leurs propres migrations, et si plusieurs services pointent vers une même base de données, leurs états de migration entrent en conflit. Utilisez l’inventaire figurant dans [Alias de bases de données](/fr/vantage/self-hosted/v3.0/secrets-and-keyvault#databases) pour planifier les noms de base de données et les chaînes de connexion. Vous n’avez pas besoin de créer les bases de données manuellement : le migrateur de chaque service crée sa base de données lors de la première exécution. Le reporting est disponible uniquement avec SQL Server. Lorsque vous utilisez PostgreSQL, laissez `vantage.reportingEnabled` défini sur `false`. Les chaînes de connexion PostgreSQL doivent être sur une seule ligne, sans caractère de nouvelle ligne au début, à la fin ou au milieu.

Préparer les secrets Kubernetes

Le fournisseur de secrets Kubernetes lit les ressources `Secret` Kubernetes natives dans `$install_namespace`. Vantage ne se connecte pas directement à Vault ni à un autre gestionnaire de secrets externe. Si vous utilisez External Secrets Operator, un pilote CSI ou un autre outil de synchronisation, configurez-le pour qu’il crée les secrets Kubernetes requis avant d’installer Vantage. Sélectionnez le fournisseur Kubernetes : ```yaml theme={null} vantage: secrets: kubernetes: {} ``` Par défaut, Vantage utilise les noms de Secret définis dans sa documentation. Utilisez `objects` pour mettre en correspondance un alias avec un autre Secret : ```yaml theme={null} vantage: secrets: kubernetes: objects: authSigningTlsCrt: secretName: vantage-auth-signing authSigningTlsKey: secretName: vantage-auth-signing authDeactivatedTlsCrt: secretName: vantage-auth-deactivated authDeactivatedTlsKey: secretName: vantage-auth-deactivated subscriptionDatabaseConnectionString: secretName: vantage-db-subscriptions ``` Les deux paires de clés d’authentification signent les jetons d’application. Elles sont distinctes du certificat qui assure la terminaison du HTTPS public sur le contrôleur ingress. Voir [Certificate aliases](/fr/vantage/self-hosted/v3.0/secrets-and-keyvault#certificate-aliases) pour connaître les clés et les formats requis. Lorsque plusieurs services utilisent la clé générique `Database__ConnectionString`, créez un Secret distinct pour chaque service et mettez chaque alias de base de données en correspondance via `vantage.secrets.kubernetes.objects`. Votre système de gestion des secrets peut générer ces Secrets à partir d’un modèle commun de chaîne de connexion, mais chaque chaîne de connexion obtenue doit indiquer une base de données différente. L’opérateur valide la configuration des secrets pendant la vérification préalable. Les charts `vantage-operator` et `vantage-selfhosted` correspondants accordent à l’opérateur un accès en lecture aux Secrets via un ClusterRole lié uniquement dans l’espace de noms de la release Vantage. Si vous personnalisez l’espace de noms de l’opérateur ou le ServiceAccount du contrôleur, assurez-vous que les valeurs `operator` correspondantes dans le chart Vantage correspondent à cette installation. Une restriction `resourceNames` personnalisée doit inclure chaque Secret référencé par le provider Kubernetes.

Configurer l’accès au registre

L’accès au registre repose sur trois consommateurs distincts : | Consumer | Required access | | ---------------------------- | ----------------------------------------------------------------------------------------------------------- | | Vantage operator | Télécharger l’image de l’opérateur. Configurez `manager.imagePullSecrets` si nécessaire. | | OCI migration job | Télécharger son image de job, lire depuis le registre source et écrire dans le registre de destination. | | Vantage workloads and ArgoCD | Télécharger les images de charge de travail et les charts des composants depuis le registre de destination. | Créez des Secrets de registre dans l’espace de noms où s’exécute chaque consommateur. Ne stockez pas de mots de passe de registre en clair dans votre fichier de valeurs. Pour OCI migration, référencez les Secrets d’identifiants source et destination : ```yaml theme={null} vantage: ociMigration: enabled: true serviceAccountName: imagePullSecrets: - name: sources: - host: repository: credentialsRef: name: destination: host: credentialsRef: name: ``` Ajoutez le secret d’extraction du registre de destination à `imagePullSecrets` du ServiceAccount désigné par `vantage.serviceAccountName`, le ServiceAccount par défaut des charges de travail Vantage. Si un pod de composant s’exécute avec un autre ServiceAccount, ce ServiceAccount doit lui aussi disposer d’un accès d’extraction au registre. Vérifiez le `spec.serviceAccountName` du pod avant de modifier le ServiceAccount `default` de l’espace de noms.

Configurer l’autoscaling et les métriques

La prise en charge de KEDA est facultative, mais recommandée. Utilisez KEDA 2.17.3 : KEDA 2.18 et les versions ultérieures ont supprimé un champ de scaler utilisé par les charts de charges de travail Vantage actuels et ne peuvent pas créer les HPA nécessaires. Certaines ressources Vantage `ScaledObject` interrogent Prometheus à cette adresse fixe : ```text theme={null} http://prometheus-operated.observability.svc.cluster.local:9090 ``` Avant d’activer KEDA : 1. Installez KEDA 2.17.3. 2. Installez Prometheus Operator et une instance Prometheus dans l’espace de noms `observability`. 3. Vérifiez que le Service associé est nommé `prometheus-operated` et expose le port `9090`. 4. Configurez Prometheus pour qu’il découvre le `ServiceMonitor` de Vantage. Activez KEDA sur la ressource `Vantage` et activez le `ServiceMonitor` du chart via le bloc `observability` distinct situé au niveau supérieur : ```yaml theme={null} vantage: keda: enabled: true observability: prometheus: namespace: observability serviceMonitor: create: true ``` `observability` est une clé de niveau supérieur ; ne la placez pas sous `vantage`. Pour les stratégies de déclenchement, la vérification et la planification des capacités, consultez [Mise à l’échelle automatique avec KEDA](/fr/vantage/self-hosted/v3.0/performance/autoscaling). Pour la configuration de collecte spécifique au maillage, consultez [Supervision avec Prometheus](/fr/vantage/self-hosted/v3.0/monitoring/prometheus).

Configurer l’ingress et TLS

L’ingress intégré du chart est conçu pour Istio. Si vous utilisez Traefik ou un autre contrôleur d’ingress, désactivez-le : ```yaml theme={null} ingress: enabled: false ``` Votre configuration ingress doit : * Terminer HTTPS pour `vantage.dnsRecord` avec un certificat approuvé. * Router les chemins de l’UI Vantage, de l’API, de l’authentification, de l’aide, de SCIM, du raccourcisseur d’URL, de l’espace de travail, de la vérification et de Try Any Skill vers leurs Services correspondants. * Appliquer les réécritures `/api/vN/` vers `/publicapi/vN/`, `/api/`, SCIM et heartbeat utilisées par Vantage. * Faire correspondre les routes les plus spécifiques avant la route générique de l’UI. * Transmettre l’hôte et le protocole d’origine, y compris `X-Forwarded-Proto: https` lorsque TLS se termine au niveau du contrôleur ingress. Traefik implémente ces exigences à l’aide d’un `IngressRoute` et de ressources `Middleware` ordonnées. Traitez le manifeste de routage comme une configuration Vantage versionnée : paramétrez le nom d’hôte, l’espace de noms, le Secret du certificat et les noms de Service générés pour votre version au lieu de copier des valeurs d’un autre environnement.

Contrat de routage

Identifiez les noms de Service Kubernetes générés dans `$install_namespace`, puis implémentez ces routes dans l’ordre indiqué. Les routes regex et exactes doivent être prioritaires par rapport aux routes par préfixe et aux routes fourre-tout. | Chemin public | Composant Vantage | Réécriture ou comportement | | ------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------- | ---------------------------------------------------------------------------------------- | | `^/api/v[0-9]+(/\|$)` | Passerelle API | Réécrivez `/api/vN/...` en `/publicapi/vN/...`. | | `^/verification/(markup\|manualreview)//notifications` | Vérification | Aucune réécriture. | | `^/workspace/(v1/files\|skilloperations/notifications\|projects//notifications\|skills//notifications\|catalogoperations/notifications)` | Espace de travail | Aucune réécriture. | | Exact `/try-any-skill` | Try Any Skill | Redirigez de manière permanente vers `/try-any-skill/`. | | `/try-any-skill/` | Try Any Skill | Aucune réécriture. | | `/ad/` et `/ss/` | Front-end AD | Aucune réécriture ; utilisez le port du Service exposé par la charge de travail générée. | | `/auth2` | Identité Auth | Aucune réécriture. | | `/surl` | Raccourcisseur d’URL | Aucune réécriture. | | `/api` et `/api/` | Passerelle API | Supprimez le préfixe `/api`. | | `/` | Front-end Vantage | Route fourre-tout ; évaluez-la en dernier. | L’ingress Istio intégré au chart bloque également `/api/status` et `/api/status/config`, qui exposent des informations d’état internes dont les clients n’ont pas besoin. Il est recommandé de bloquer ces chemins, mais ce n’est pas nécessaire au fonctionnement de Vantage. Si votre contrôleur d’ingress ne peut pas renvoyer directement une réponse de refus, vous pouvez les acheminer vers un backend de refus dédié avant la règle générale `/api`.

Protocole HTTPS transmis

Lorsque TLS se termine sur un contrôleur d’ingress et que la connexion au backend se fait en HTTP, les services d’authentification de Vantage doivent tenir compte de `X-Forwarded-Proto`. Sans cela, le document de découverte OIDC peut annoncer des points de terminaison `http://` et l’authentification dans le navigateur échoue. Activez cette configuration en définissant `vantage.reverseProxy` sur `true` : ```yaml theme={null} vantage: reverseProxy: true ```

Installer l’opérateur

Installez une instance de l’opérateur dans le cluster : ```bash theme={null} helm upgrade --install vantage-operator $charts_uri/vantage-operator \ --version 0.70.13 \ --namespace $operator_namespace \ --create-namespace \ --wait ``` Si le registre de l’opérateur nécessite un secret d’extraction, ajoutez cette option à la commande avant `--wait` : ```bash theme={null} --set "manager.imagePullSecrets[0].name=" ```

Installer Vantage

Créez un fichier de valeurs qui regroupe la configuration préparée ci-dessus. Cet exemple abrégé présente les valeurs propres au déploiement autogéré ; ajoutez les mises en correspondance complètes des Secret ainsi que les identifiants du registre pour votre environnement : ```yaml theme={null} operator: namespace: ingress: enabled: false vantage: dnsRecord: mailFrom: platformAdminEmail: serviceAccountName: databaseProvider: PostgreSQL reportingEnabled: false updatePolicy: manual: {} secrets: # Ajoutez une mise en correspondance d'objets lorsque vos noms de Secret diffèrent des valeurs par défaut. kubernetes: {} storage: custom: storageClass: size: 300Gi keda: enabled: true ociMigration: enabled: true serviceAccountName: imagePullSecrets: - name: sources: - host: repository: credentialsRef: name: destination: host: credentialsRef: name: observability: prometheus: namespace: observability serviceMonitor: create: true ``` Installez le chart `vantage-selfhosted` approprié : ```bash theme={null} helm upgrade --install $release_name $chart_uri/vantage-selfhosted \ --version 0.70.13 \ --namespace $install_namespace \ --create-namespace \ --values values-self-managed.yaml \ --wait ``` Après que l’opérateur a créé les services de la charge de travail, appliquez la configuration de votre contrôleur d’ingress et vérifiez que le certificat TLS est prêt.

Suivre l’installation

Attendez que la ressource personnalisée indique `Ready` : ```bash theme={null} kubectl -n $install_namespace wait \ --for=condition=Ready vantages.vantage.abbyy.com/$release_name \ --timeout=30m ``` Vérifiez ensuite les applications ArgoCD et les charges de travail générées. Ne vous fiez pas à la seule valeur `Ready` : ```bash theme={null} argocd app list -l vantage.abbyy.com/managed-by=vantage-operator kubectl -n $install_namespace get pods kubectl -n $install_namespace get scaledobjects,hpa ``` Lorsque la migration OCI est activée, surveillez-la séparément : ```bash theme={null} kubectl -n $install_namespace wait --for=create job/$release_name-oci-migration --timeout=2m kubectl -n $install_namespace wait --for=condition=Complete job/$release_name-oci-migration --timeout=20m ``` L’installation du Skill s’exécute dans une tâche distincte et peut se poursuivre après que Vantage a indiqué `Ready` : ```bash theme={null} kubectl -n $install_namespace wait --for=create job/$install_namespace-skill-installer-job kubectl -n $install_namespace wait --for=condition=Complete job/$install_namespace-skill-installer-job ``` Enfin, confirmez que : * Chaque application ArgoCD générée est `Synced` et `Healthy`. * Les pods Vantage sont en cours d’exécution et injectés dans le maillage. * Prometheus signale les cibles Vantage `/metrics-text` comme étant `UP`. * Les ressources KEDA `ScaledObject` sont `Ready` et les valeurs des métriques HPA ne sont pas ``. * Le document de découverte OIDC et les redirections du navigateur utilisent des URL en `https://`. * Vantage est disponible à l’adresse `https://$your_vantage_hostname`.

Étapes suivantes

Alias de Secret Kubernetes, paires de clés d’authentification et chaînes de connexion à la base de données. Configurez Prometheus pour collecter les métriques de Vantage via le maillage de services. Diagnostiquez les défaillances de l’opérateur, de la base de données, du registre, de l’ingress et de l’autoscaling. Mettez à niveau l’opérateur et les charts Vantage simultanément.