Passer au contenu principal

Aperçu

L’opérateur Kubernetes W&B est la méthode recommandée pour déployer W&B Server sur Kubernetes (dans le cloud ou sur site). Pour un aperçu de l’opérateur, savoir pourquoi W&B l’utilise et comprendre le fonctionnement de la hiérarchie de configuration, voir Autogéré.

Avant de commencer

Avant de déployer W&B avec l’opérateur Kubernetes, assurez-vous que votre infrastructure répond à toutes les exigences :
  1. Vérifier les exigences de l’infrastructure : Voir la page des exigences d’infrastructure pour l’environnement Autogéré pour plus de détails sur :
  • Exigences relatives aux versions logicielles (Kubernetes, MySQL, Redis, Helm)
    • Exigences matérielles (architecture CPU, recommandations de dimensionnement)
    • Configuration du cluster Kubernetes
    • Exigences relatives au réseau, à SSL/TLS et au DNS
  1. Obtenir une licence W&B Server : Voir la section License sur la page des exigences.
  2. Préparer les services externes : Configurer MySQL, Redis et le stockage d’objets avant le déploiement.
Pour plus d’informations, voir la page de l’architecture de référence.

Base de données MySQL

W&B nécessite une base de données MySQL externe. Pour la Production, W&B recommande fortement d’utiliser des services de base de données gérés : Les services de base de données gérés offrent des sauvegardes automatisées, de la supervision, une haute disponibilité et l’application des correctifs, tout en réduisant la charge opérationnelle. Voir l’architecture de référence pour connaître l’ensemble des exigences MySQL, y compris les recommandations de dimensionnement et les paramètres de configuration. Pour le SQL de création de la base de données, consultez le guide bare-metal. Pour toute question sur la configuration de la base de données de votre déploiement, contactez l’assistance ou votre AISE. Pour des instructions complètes sur la configuration de MySQL, y compris les paramètres de configuration et la création de la base de données, voir la section MySQL de la page des exigences.

Redis

W&B dépend d’un déploiement Redis 7.x à nœud unique, utilisé par les composants de W&B pour mettre les jobs en file d’attente et mettre les données en cache. Pour plus de commodité lors des tests et du développement de preuves de faisabilité, W&B Self-Managed inclut un déploiement Redis local qui n’est pas adapté aux déploiements de production. Pour les déploiements de production, W&B peut se connecter à une instance Redis dans les environnements suivants : Voir la section de configuration de Redis externe pour savoir comment configurer une instance Redis externe dans les valeurs Helm.

Stockage d’objets

W&B requiert un stockage d’objets prenant en charge les URL pré-signées et CORS. Fournisseurs de stockage recommandés :
  • Amazon S3 : service de stockage d’objets offrant une évolutivité, une disponibilité des données, une sécurité et des performances de premier plan.
  • Google Cloud Storage : service géré permettant de stocker des données non structurées à grande échelle.
  • Azure Blob Storage : solution de stockage d’objets cloud pour stocker de grandes quantités de données non structurées.
  • CoreWeave AI Object Storage : service de stockage d’objets hautes performances, compatible S3, optimisé pour les charges de travail d’IA.
  • Stockage compatible S3 pour les entreprises : MinIO Enterprise (AIStor), NetApp StorageGRID ou d’autres solutions de niveau entreprise
MinIO Open Source est en mode de maintenance, sans développement actif ni binaires précompilés. Pour les déploiements de production, W&B recommande d’utiliser des services de stockage d’objets gérés ou des solutions compatibles S3 pour les entreprises, telles que MinIO Enterprise (AIStor).
Pour des instructions détaillées sur le provisionnement du bucket, y compris les stratégies IAM, la configuration CORS et la configuration de l’accès, voir le guide Bring Your Own Bucket (BYOB). Voir la section sur le stockage d’objets de l’architecture de référence pour connaître l’ensemble des exigences.

Provisionnez votre bucket de stockage

Avant de configurer W&B, provisionnez votre bucket de stockage d’objets avec les politiques IAM appropriées, une configuration CORS et les identifiants d’accès nécessaires. Voir le guide Bring Your Own Bucket (BYOB) pour obtenir des instructions de provisionnement détaillées, étape par étape, pour :
  • Amazon S3 (y compris les politiques IAM et les politiques de bucket)
  • Google Cloud Storage (y compris les notifications PubSub)
  • Azure Blob Storage (y compris les identités gérées)
  • CoreWeave AI Object Storage
  • stockage compatible S3 (MinIO Enterprise, NetApp StorageGRID et d’autres solutions d’entreprise)
Voir la section de configuration du stockage d’objets pour plus de détails sur sa configuration dans les valeurs Helm.

clusters Kubernetes OpenShift

W&B prend en charge le déploiement sur les clusters Kubernetes OpenShift dans le cloud, sur site et dans des environnements isolés du réseau.
W&B recommande d’utiliser le chart Helm officiel de W&B pour l’installation.

Exécutez le conteneur avec un utilisateur non privilégié

Par défaut, les conteneurs utilisent un $UID de 999. Spécifiez un $UID >= 100000 et un $GID de 0 si votre orchestrateur exige que le conteneur s’exécute sous un utilisateur non root.
W&B doit démarrer avec le groupe root ($GID=0) pour que les autorisations du système de fichiers fonctionnent correctement.
Configurez des contextes de sécurité pour chaque composant W&B. Par exemple, pour configurer le composant API :
Si nécessaire, configurez un contexte de sécurité personnalisé pour d’autres composants, comme app ou console. Pour plus de détails, voir Contexte de sécurité personnalisé.

Déployer l’application W&B Server

L’opérateur Kubernetes W&B avec Helm est la méthode d’installation recommandée pour tous les déploiements W&B Autogéré, y compris dans les environnements cloud, sur site et isolé du réseau.
Choisissez votre méthode de déploiement :
W&B fournit un chart Helm pour déployer l’opérateur Kubernetes W&B sur un cluster Kubernetes. Cette approche vous permet de déployer W&B Server avec la CLI Helm ou un outil de déploiement continu comme ArgoCD.Pour les considérations spécifiques au déploiement, voir Considérations spécifiques à l’environnement et Déployer avec Terraform sur un cloud public. Pour les environnements déconnectés, voir Déployer sur Kubernetes en environnement isolé.Suivez ces étapes pour installer l’opérateur Kubernetes W&B avec la CLI Helm :
  1. Ajoutez le dépôt Helm W&B. Le chart Helm W&B est disponible dans le dépôt Helm W&B :
  2. Installez l’opérateur sur un cluster Kubernetes :
  3. Configurez la ressource personnalisée de l’opérateur W&B pour déclencher l’installation de W&B Server. Créez un fichier nommé operator.yaml avec votre configuration de déploiement W&B. Référez-vous à la Référence de configuration pour connaître toutes les options disponibles. Voici une configuration minimale :
  4. Lancez l’opérateur avec votre configuration personnalisée afin qu’il puisse installer, configurer et gérer l’application W&B Server :
    Attendez que le déploiement soit terminé. Cela prend quelques minutes.
  5. Pour vérifier l’installation via l’interface utilisateur web, créez le premier compte administrateur, puis suivez les étapes de vérification décrites dans Vérifiez l’installation.

Vérifiez l’installation

Pour vérifier l’installation, W&B recommande d’utiliser le W&B CLI. La commande verify exécute plusieurs tests pour vérifier l’ensemble des composants et de la configuration.
Cette étape suppose que le premier compte administrateur a été créé depuis le navigateur.
Suivez ces étapes pour vérifier l’installation :
  1. Installez le W&B CLI :
  1. Connectez-vous à W&B :
Par exemple :
  1. Vérifiez l’installation :
Une installation réussie et un déploiement W&B pleinement opérationnel affichent la sortie suivante :
Contactez l’assistance W&B en cas d’erreur.

Considérations spécifiques à l’environnement

Kubernetes fonctionne de la même manière, qu’il soit exécuté sur site ou dans le cloud. Les principales différences concernent les conventions de nommage et les services gérés (par exemple, MySQL vs RDS, ou S3 vs le stockage d’objets sur site). Cette section aborde les considérations qui varient selon l’environnement.

sur site et bare metal

Lors d’un déploiement sur un cluster Kubernetes sur site ou bare metal, tenez compte des points suivants.

Configuration de l’équilibreur de charge

Les clusters Kubernetes sur site nécessitent généralement une configuration manuelle de l’équilibreur de charge. Les options possibles sont les suivantes :
  • Équilibreur de charge externe : configurez un équilibreur de charge matériel ou logiciel existant (F5, HAProxy, etc.)
  • Nginx Ingress Controller : déployez nginx-ingress-controller avec NodePort ou le réseau hôte
  • MetalLB : pour les clusters Kubernetes bare metal, MetalLB fournit des services d’équilibreur de charge
Pour des exemples détaillés de configuration de l’équilibreur de charge, voir la section réseau de l’architecture de référence.

Stockage persistant

Assurez-vous que votre cluster Kubernetes dispose d’une StorageClass configurée pour les volumes persistants. Les composants W&B peuvent nécessiter un stockage persistant pour la mise en cache et les données temporaires. Options courantes de stockage sur site :
  • Classes de stockage basées sur NFS
  • Stockage Ceph/Rook
  • Volumes persistants locaux
  • Solutions de stockage d’entreprise (NetApp, Pure Storage, etc.)

Gestion du DNS et des certificats

Pour les déploiements sur site :
  • Configurez les enregistrements DNS internes pour qu’ils pointent vers votre nom d’hôte W&B
  • Générez des certificats SSL/TLS auprès de votre autorité de certification (CA) interne
  • Si vous utilisez des certificats auto-signés, configurez l’opérateur pour qu’il fasse confiance à votre certificat d’autorité de certification (CA)
Voir les exigences SSL/TLS pour plus de détails sur la configuration des certificats.

Déploiements OpenShift

W&B prend entièrement en charge les déploiements sur des clusters Kubernetes OpenShift. Les déploiements OpenShift nécessitent des configurations supplémentaires du contexte de sécurité en raison des politiques de sécurité plus strictes d’OpenShift. Pour en savoir plus sur la configuration spécifique à OpenShift, voir clusters Kubernetes OpenShift ci-dessus. Pour des exemples complets de déploiement OpenShift dans des environnements isolés du réseau, voir Déployer sur Kubernetes isolé du réseau.

Stockage d’objets pour les environnements sur site et compatibles S3

Une fois votre bucket de stockage d’objets provisionné (voir Provisionnement du stockage d’objets), configurez-le dans votre Ressource personnalisée W&B. AWS S3 (sur site) Pour AWS S3 sur site (via Outposts ou un stockage compatible) :
Stockage compatible avec S3 (MinIO, Ceph, NetApp, etc.) Pour les systèmes de stockage compatibles avec S3 :
Pour activer TLS pour le stockage compatible avec S3, ajoutez ?tls=true au chemin du bucket :
Le certificat doit être approuvé. Les certificats autosignés nécessitent une configuration supplémentaire. Voir les exigences SSL/TLS pour en savoir plus.
Considérations importantes pour le stockage d’objets sur site Si vous exploitez votre propre stockage d’objets, tenez compte des points suivants :
  1. Capacité de stockage et performances : Surveillez attentivement la capacité du disque. Une utilisation moyenne de W&B représente de quelques dizaines à quelques centaines de gigaoctets. Une utilisation intensive peut entraîner des pétaoctets de consommation de stockage.
  2. Tolérance aux pannes : Au minimum, utilisez des baies RAID pour les disques physiques. Pour le stockage compatible S3, utilisez des configurations distribuées ou hautement disponibles.
  3. Disponibilité : Mettez en place une supervision afin de garantir que le stockage reste disponible.
Considérations relatives à MinIO
MinIO Open Source est en mode maintenance et ne fait plus l’objet de développement actif. Les binaires précompilés ne sont plus fournis et seuls les correctifs de sécurité critiques sont examinés au cas par cas. Pour les déploiements de production, W&B recommande d’utiliser des services gérés de stockage d’objets ou MinIO Enterprise (AIStor).
Les alternatives Enterprise au stockage d’objets sur site incluent : Si vous utilisez un déploiement MinIO existant ou MinIO Enterprise, vous pouvez créer un bucket à l’aide du client MinIO :

Sur cloud public avec Terraform

Pour un déploiement complet de l’infrastructure et de l’application sur AWS, Google Cloud ou Azure, voir Déployer avec Terraform sur un cloud public ci-dessous.

Déployer avec Terraform sur un cloud public

W&B recommande des options de déploiement entièrement gérées, comme W&B Multi-tenant Cloud ou W&B Dedicated Cloud. Les services entièrement gérés de W&B sont simples à utiliser et sécurisés, avec peu ou pas de configuration requise.
W&B fournit des modules Terraform pour déployer la plateforme chez des fournisseurs de cloud public. Ces modules automatisent le provisionnement de l’infrastructure et l’installation de W&B Server. Avant de commencer, W&B recommande de choisir l’un des backends distants disponibles pour Terraform afin d’y stocker le fichier d’état. Le fichier d’état est indispensable pour appliquer des mises à niveau ou apporter des modifications à votre déploiement sans recréer tous les composants. Sélectionnez votre fournisseur de cloud :
W&B recommande d’utiliser le W&B Server AWS Terraform Module pour déployer la plateforme sur AWS.Le module Terraform déploie les composants obligatoires suivants :
  • Équilibreur de charge
  • AWS Identity & Access Management (IAM)
  • AWS Key Management System (KMS)
  • Amazon Aurora MySQL
  • Amazon VPC
  • Amazon S3
  • Amazon Route53
  • Amazon Certificate Manager (ACM)
  • Amazon Elastic Load Balancing (ALB)
  • Amazon Secrets Manager
Les composants facultatifs incluent :
  • ElastiCache pour Redis
  • SQS

Permissions requises

Le compte qui exécute Terraform doit pouvoir créer tous les composants décrits ci-dessus et disposer des autorisations nécessaires pour créer des IAM Policies et des IAM Roles, ainsi qu’attribuer des rôles aux ressources.

Étapes générales

Les étapes de cette section sont communes à toutes les options de déploiement.
  1. Préparez l’environnement de développement.
    • Installez Terraform
    • W&B recommande de créer un dépôt Git pour le suivi des versions.
  2. Créez le fichier terraform.tfvars. Le contenu du fichier tvfars peut être personnalisé selon le type d’installation, mais la configuration minimale recommandée ressemble à l’exemple ci-dessous.
    Veillez à définir les variables dans votre fichier tvfars avant de déployer, car la variable namespace est une chaîne de caractères utilisée comme préfixe pour toutes les ressources créées par Terraform. La combinaison de subdomain et domain forme le FQDN de votre instance W&B. Dans l’exemple ci-dessus, le FQDN W&B sera wandb-aws.wandb.ml, ainsi que le zone_id DNS dans lequel l’enregistrement FQDN sera créé. Les paramètres allowed_inbound_cidr et allowed_inbound_ipv6_cidr doivent également être définis. Dans le module, il s’agit d’une entrée obligatoire. L’exemple suivant autorise l’accès à l’installation W&B depuis n’importe quelle source.
  3. Créez le fichier versions.tf Ce fichier contiendra les versions requises de Terraform et du fournisseur Terraform pour déployer W&B sur AWS :
    Consultez la documentation officielle de Terraform pour configurer le fournisseur AWS. Bien que facultative, l’ajout de la configuration du backend distant mentionnée au début de cette documentation est fortement recommandé.
  4. Créez le fichier variables.tf Pour chaque option configurée dans terraform.tfvars, Terraform nécessite une déclaration de variable correspondante.

Déploiement recommandé

Il s’agit de la configuration de déploiement la plus simple, qui crée tous les composants obligatoires et installe la dernière version de W&B dans le cluster Kubernetes.
  1. Créez le fichier main.tf Dans le même répertoire que celui où vous avez créé les fichiers dans les étapes General, créez un fichier main.tf avec le contenu suivant :
  2. Déployer W&B Pour déployer W&B, exécutez les commandes suivantes :

Activer Redis

Pour utiliser Redis afin de mettre en cache les requêtes SQL et accélérer la réponse de l’application lors du chargement des métriques, ajoutez l’option create_elasticache_subnet = true au fichier main.tf :

Activer le courtier de messages (file d’attente)

Pour activer un courtier de messages externe via SQS, ajoutez l’option use_internal_queue = false au fichier main.tf :
Ceci est facultatif, car W&B inclut un broker intégré. Cette option n’apporte aucune amélioration des performances.

Ressources supplémentaires

Autres options de déploiement

Vous pouvez combiner plusieurs options de déploiement en ajoutant toutes les configurations dans le même fichier. Chaque module Terraform propose plusieurs options, que vous pouvez combiner avec les options standard et la configuration minimale décrite dans la section sur le déploiement recommandé. Consultez la documentation du module correspondant à votre cloud provider pour obtenir la liste complète des options disponibles :

Accéder à la console de gestion W&B

L’opérateur Kubernetes W&B inclut une console de gestion. Elle se trouve à l’adresse ${HOST_URI}/console, par exemple https://wandb.company-name.com/console. Vous pouvez vous connecter à la console de gestion de deux façons :
  1. Ouvrez l’application W&B dans votre navigateur et connectez-vous. Connectez-vous à l’application W&B à l’adresse ${HOST_URI}/, par exemple https://wandb.company-name.com/
  2. Accédez à la console. Cliquez sur l’icône dans le coin supérieur droit, puis sur Console système. Seuls les utilisateurs disposant des privilèges d’administrateur peuvent voir l’entrée Console système.
    Accès à la console système

Mettre à jour l’opérateur Kubernetes W&B

Cette section explique comment mettre à jour l’opérateur Kubernetes W&B.
  • La mise à jour de l’opérateur Kubernetes W&B ne met pas à jour l’application W&B Server.
  • Voir les instructions ici si vous utilisez un chart Helm qui n’utilise pas l’opérateur Kubernetes W&B, avant de suivre les instructions ci-dessous pour mettre à jour l’opérateur W&B.
Copiez-collez les extraits de code ci-dessous dans votre terminal.
  1. Commencez par mettre à jour le dépôt avec helm repo update :
  2. Ensuite, mettez à jour le chart Helm avec helm upgrade :

Mettre à jour l’application W&B Server

Vous n’avez plus besoin de mettre à jour l’application W&B Server si vous utilisez l’opérateur Kubernetes W&B. L’opérateur met automatiquement à jour votre application W&B Server lorsqu’une nouvelle version du logiciel W&B est publiée.

Migrer des instances Autogéré vers W&B Operator

La section suivante explique comment passer d’une gestion autonome de votre propre installation W&B Server à l’utilisation de W&B Operator pour la gérer à votre place. Le processus de migration dépend de la façon dont vous avez installé W&B Server :
W&B Operator est la méthode d’installation par défaut et recommandée pour W&B Server. Contactez Customer Support ou votre équipe W&B si vous avez des questions.

Migrer vers des modules Terraform AWS basés sur l’opérateur

Pour une description détaillée du processus de migration, consultez ce guide.

Migrer vers les modules Terraform Google Cloud basés sur l’Operator

Contactez Customer Support ou votre équipe W&B si vous avez des questions ou besoin d’assistance.

Migrer vers des modules Terraform Azure basés sur l’Operator

Contactez Customer Support ou votre équipe W&B si vous avez des questions ou besoin d’assistance.

Migrer vers le chart Helm basé sur un opérateur

Suivez ces étapes pour migrer vers le chart Helm basé sur un opérateur :
  1. Obtenez la configuration W&B actuelle. Si W&B a été déployé avec une version du chart Helm non basée sur un opérateur, exportez les valeurs comme ceci :
    Si W&B a été déployé avec des manifests Kubernetes, exportez les valeurs comme ceci :
    Vous disposez maintenant de toutes les valeurs de configuration nécessaires pour l’étape suivante.
  2. Créez un fichier nommé operator.yaml. Suivez le format décrit dans la Référence de configuration. Utilisez les valeurs de l’étape 1.
  3. Réduisez le déploiement actuel à 0 pods. Cette étape arrête le déploiement actuel.
  4. Mettez à jour le dépôt du chart Helm :
  5. Installez le nouveau chart Helm :
  6. Configurez le nouveau chart Helm et déclenchez le déploiement de l’application W&B. Appliquez la nouvelle configuration.
    Le déploiement prend quelques minutes.
  7. Vérifiez l’installation. Assurez-vous que tout fonctionne en suivant les étapes de Vérifiez l’installation.
  8. Supprimez l’ancienne installation. Désinstallez l’ancien chart Helm ou supprimez les ressources créées à l’aide de manifests.

Migrer vers un chart Helm Terraform basé sur l’opérateur

Suivez ces étapes pour migrer vers le chart Helm basé sur l’opérateur :
  1. Préparez la configuration Terraform. Remplacez dans votre configuration Terraform le code Terraform de l’ancien déploiement par celui décrit ici. Définissez les mêmes variables qu’auparavant. Ne modifiez pas le fichier .tfvars si vous en avez un.
  2. Exécutez Terraform. Exécutez terraform init, plan et apply
  3. Vérifiez l’installation. Assurez-vous que tout fonctionne en suivant les étapes de Vérifiez l’installation.
  4. Supprimez l’ancienne installation. Désinstallez l’ancien chart Helm ou supprimez les ressources créées à l’aide de manifest.

Référence de configuration pour W&B Server

Cette section décrit les options de configuration de l’application W&B Server. L’application reçoit sa configuration sous la forme d’une définition de ressource personnalisée nommée WeightsAndBiases. Certaines options de configuration sont disponibles dans la configuration ci-dessous, tandis que d’autres doivent être définies au moyen de variables d’environnement. La documentation comporte deux listes de variables d’environnement : de base et avancées. Utilisez des variables d’environnement uniquement si l’option de configuration dont vous avez besoin n’est pas exposée via le chart Helm.

Exemple de base

Cet exemple définit le jeu minimal de valeurs requis pour W&B. Pour un exemple de production plus réaliste, voir Exemple complet. Ce fichier YAML définit l’état souhaité de votre déploiement W&B, y compris la version, les variables d’environnement, les ressources externes comme les bases de données, ainsi que d’autres paramètres nécessaires.
Consultez la liste complète des valeurs dans le dépôt Helm W&B. Modifiez uniquement les valeurs que vous devez surcharger.

Exemple complet

Cet exemple de configuration déploie W&B sur Google Cloud Anthos à l’aide de Google Cloud Storage :

Hôte

Stockage d’objets (bucket)

AWS
Google Cloud
Azure
Autres fournisseurs (Minio, Ceph et autres services de stockage compatibles S3) Pour les autres fournisseurs compatibles S3, définissez la configuration du bucket comme suit :
Pour un stockage compatible S3 hébergé en dehors d’AWS, kmsKey doit être null. Pour faire référence à accessKey et secretKey depuis un secret :

MySQL

Pour référencer le password d’un secret :

License

Pour faire référence à la license à partir d’un secret :

Ingress

Pour identifier la classe d’ingress, voir cette entrée de FAQ ici. Sans TLS
Avec TLS Créez un secret contenant le certificat
Indiquez le secret dans la configuration d’ingress
Dans le cas de Nginx, il se peut que vous deviez ajouter l’annotation suivante :

Comptes de service Kubernetes personnalisés

Spécifiez des comptes de service Kubernetes personnalisés pour exécuter les pods W&B. L’extrait suivant crée un compte de service dans le déploiement avec le nom indiqué :
Les sous-systèmes “app” et “parquet” s’exécutent avec le compte de service spécifié. Les autres sous-systèmes s’exécutent avec le compte de service par défaut. Si le compte de service existe déjà sur le cluster, définissez create: false :
Vous pouvez spécifier des comptes de service pour différents sous-systèmes, tels que app, parquet, console et autres :
Les comptes de service peuvent varier d’un sous-système à l’autre :

Redis externe

Pour référencer le password à partir d’un secret :
Faites-y référence dans la configuration ci-dessous :

LDAP

La prise en charge de la configuration LDAP dans le chart Helm actuel est limitée. Contactez l’équipe d’assistance de W&B ou votre AISE pour vous aider à configurer LDAP.
Configurez LDAP en définissant des variables d’environnement dans global.extraEnv :

OIDC SSO

authMethod est facultatif.

SMTP

Variables d’environnement

Autorité de certification personnalisée

customCACerts est une liste qui peut contenir plusieurs certificats. Les autorités de certification spécifiées dans customCACerts s’appliquent uniquement à l’application W&B Server.
Les certificats CA peuvent également être stockés dans une ConfigMap :
Le ConfigMap doit se présenter comme suit :
Si vous utilisez une ConfigMap, chaque clé de la ConfigMap doit se terminer par .crt (par exemple, my-cert.crt ou ca-cert1.crt). Cette convention de nommage est requise pour que update-ca-certificates puisse traiter et ajouter chaque certificat au magasin système des autorités de certification.

Contexte de sécurité personnalisé

Chaque composant W&B prend en charge des configurations de contexte de sécurité personnalisées sous la forme suivante :
La seule valeur valide pour runAsGroup: est 0. Toute autre valeur constitue une erreur.
Par exemple, pour configurer le pod de l’application, ajoutez une section app à votre configuration :
Le même concept s’applique à console, weave, weave-trace et parquet.

Référence de configuration pour l’opérateur W&B

Cette section décrit les options de configuration de l’opérateur Kubernetes W&B (wandb-controller-manager). L’opérateur reçoit sa configuration sous la forme d’un fichier YAML. Par défaut, l’opérateur Kubernetes W&B n’a pas besoin de fichier de configuration. Créez un fichier de configuration si nécessaire. Par exemple, vous pouvez en avoir besoin pour spécifier des autorités de certification personnalisées, déployer dans un environnement isolé (air gap), etc. Consultez la liste complète des personnalisations de la spécification dans le dépôt Helm.

CA personnalisée

Une autorité de certification personnalisée (customCACerts) correspond à une liste pouvant contenir plusieurs certificats. Une fois ajoutées, ces autorités de certification s’appliquent uniquement à l’opérateur Kubernetes W&B (wandb-controller-manager).
Les certificats CA peuvent également être stockés dans une ConfigMap :
Le ConfigMap doit se présenter ainsi :
Chaque clé du ConfigMap doit se terminer par .crt (par exemple, my-cert.crt ou ca-cert1.crt). Cette convention de nommage est nécessaire pour que update-ca-certificates puisse interpréter et ajouter chaque certificat au magasin système d’autorités de certification.

FAQ

Quel est l’objectif/le rôle de chaque pod ?

  • wandb-app: le cœur de W&B, y compris l’API GraphQL et l’application frontend. Il assure la majeure partie des fonctionnalités de notre plateforme.
  • wandb-console: la console d’administration, accessible via /console.
  • wandb-otel: l’agent OpenTelemetry, qui collecte les métriques et les journaux des ressources au niveau de Kubernetes pour les afficher dans la console d’administration.
  • wandb-prometheus: le serveur Prometheus, qui capture les métriques de différents composants pour les afficher dans la console d’administration.
  • wandb-parquet: un microservice backend distinct du pod wandb-app qui exporte les données de la base de données vers le stockage d’objets au format Parquet.
  • wandb-weave: un autre microservice backend qui charge les tables de requête dans l’UI et prend en charge diverses fonctionnalités essentielles de l’application.
  • wandb-weave-trace: un framework pour le suivi, l’expérimentation, l’évaluation, le déploiement et l’amélioration d’applications basées sur des LLM. Le framework est accessible via le pod wandb-app.

Comment obtenir le mot de passe de la console de l’opérateur W&B

Voir Accéder à la console de gestion de l’opérateur Kubernetes W&B.

Comment accéder à la console de l’opérateur W&B si l’ingress ne fonctionne pas

Exécutez la commande suivante sur un hôte ayant accès au cluster Kubernetes :
Ouvrez la console dans votre navigateur à l’adresse https://localhost:8082/. Voir Accéder à la console de gestion de l’opérateur Kubernetes W&B pour savoir comment obtenir le mot de passe (option 2).

Comment consulter les journaux de W&B Server

Le pod de l’application s’appelle wandb-app-xxx.

Comment identifier la classe d’ingress Kubernetes

Vous pouvez obtenir la classe d’ingress installée dans votre cluster en exécutant