Passer au contenu principal
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

Pour connaître les versions des composants prises en charge et testées, consultez Compatibilité. Pour l’inventaire complet de l’infrastructure et la base de dimensionnement, consultez Prérequis.

​
Avant de commencer

Préparez les valeurs et ressources suivantes : 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.
  • 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. 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. 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 :
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 sélectionnent les nœuds portant le label suivant :
Sans au moins un nœud correspondant, les pods TechCore restent à l’état Pending. Pour l’isolation du training-worker et la référence de dimensionnement, voir Configuration requise pour les nœuds Kubernetes.

​
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 :
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.

​
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 :
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 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 :
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 :
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 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 : 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 :
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 :
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 :
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. Pour la configuration de collecte spécifique au maillage, consultez Supervision avec 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 :
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. 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. Assurez-vous que la variable d’environnement suivante est définie sur les conteneurs d’application de auth-identity, auth-adminapi2, api-gateway et api-registry :
Si les charts de charge de travail actuels n’exposent pas de remplacement via une variable d’environnement, utilisez votre mécanisme standard de mutation d’admission, tel que Kyverno ou un webhook mutateur équivalent. Appliquez la mutation avant de créer les pods Vantage. Sans cela, le document de découverte OIDC peut annoncer des points de terminaison http:// et l’authentification dans le navigateur échoue.

​
Installer l’opérateur

Installez une instance de l’opérateur dans le cluster :
Si le registre de l’opérateur nécessite un secret d’extraction, ajoutez cette option à la commande avant --wait :

​
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 :
Installez le chart vantage-selfhosted approprié :
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 :
Vérifiez ensuite les applications ArgoCD et les charges de travail générées. Ne vous fiez pas à la seule valeur Ready :
Lorsque la migration OCI est activée, surveillez-la séparément :
L’installation du Skill s’exécute dans une tâche distincte et peut se poursuivre après que Vantage a indiqué Ready :
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 <unknown>.
  • 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

Secrets

Alias de Secret Kubernetes, paires de clés d’authentification et chaînes de connexion à la base de données.

Supervision

Configurez Prometheus pour collecter les métriques de Vantage via le maillage de services.

Dépannage

Diagnostiquez les défaillances de l’opérateur, de la base de données, du registre, de l’ingress et de l’autoscaling.

Mise à niveau

Mettez à niveau l’opérateur et les charts Vantage simultanément.