Tutoriel : configurer W&B Launch sur Kubernetes

Ce tutoriel guide les administrateurs de cluster dans la configuration de W&B Launch sur un cluster Kubernetes, afin que les ingénieurs ML puissent soumettre et gérer des charges de travail d’entraînement directement depuis W&B. W&B Launch vous permet d’envoyer des charges de travail ML vers un cluster Kubernetes et offre ainsi aux ingénieurs ML une interface, directement dans W&B, pour utiliser les ressources que vous gérez déjà avec Kubernetes. W&B maintient une image officielle de l’agent Launch que vous pouvez déployer sur votre cluster à l’aide d’un chart Helm également maintenu par W&B. W&B utilise le générateur Kaniko pour permettre à l’agent Launch de créer des images Docker dans un cluster Kubernetes. Pour savoir comment configurer Kaniko pour l’agent Launch, ou comment désactiver la création de jobs et utiliser uniquement des images Docker prégénérées, consultez Configuration avancée de l’agent.

Pour installer Helm et appliquer ou mettre à niveau le chart Helm de l’agent W&B Launch, vous devez disposer d’un accès kubectl au cluster avec des autorisations suffisantes pour créer, mettre à jour et supprimer des ressources Kubernetes. En règle générale, il faut pour cela un utilisateur doté du rôle cluster-admin ou d’un rôle personnalisé aux autorisations équivalentes.

Configurer une file d’attente pour Kubernetes

Une file d’attente Launch définit la spécification de charge de travail Kubernetes que l’agent utilise pour exécuter chaque job. Pour une ressource cible Kubernetes, la configuration de la file d’attente Launch ressemble soit à une spécification de job Kubernetes, soit à une spécification de ressource personnalisée Kubernetes. Lorsque vous créez une file d’attente Launch, vous pouvez contrôler tous les aspects de la spécification de ressource de charge de travail Kubernetes.

Spécification de job Kubernetes
Spécification de ressource personnalisée

spec:
  template:
    spec:
      containers:
        - env:
            - name: MY_ENV_VAR
              value: some-value
          resources:
            requests:
              cpu: 1000m
              memory: 1Gi
metadata:
  labels:
    queue: k8s-test
namespace: wandb

Dans certains cas, vous aurez besoin d’utiliser des définitions CustomResource. Elles sont par exemple utiles pour effectuer un entraînement distribué sur plusieurs nœuds. Pour un exemple d’application, consultez le tutoriel sur l’utilisation de Launch avec des jobs multinœuds à l’aide de Volcano. Elles sont également utiles si vous souhaitez utiliser Launch avec Kubeflow.L’extrait YAML suivant présente un exemple de configuration de file d’attente Launch utilisant Kubeflow :

kubernetes:
  kind: PyTorchJob
  spec:
    pytorchReplicaSpecs:
      Master:
        replicas: 1
        template:
          spec:
            containers:
              - name: pytorch
                image: '${image_uri}'
                imagePullPolicy: Always
        restartPolicy: Never
      Worker:
        replicas: 2
        template:
          spec:
            containers:
              - name: pytorch
                image: '${image_uri}'
                imagePullPolicy: Always
        restartPolicy: Never
    ttlSecondsAfterFinished: 600
  metadata:
    name: '${run_id}-pytorch-job'
  apiVersion: kubeflow.org/v1

Pour des raisons de sécurité, W&B injecte les ressources suivantes dans votre file d’attente Launch si vous ne les spécifiez pas :

securityContext
backOffLimit
ttlSecondsAfterFinished

L’extrait YAML suivant montre comment ces valeurs apparaissent dans votre file d’attente Launch :

example-spec.yaml

spec:
  template:
    backOffLimit: 0
    ttlSecondsAfterFinished: 60
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
      seccompProfile:
        type: "RuntimeDefault"

Créer une file d’attente

Créez dans la W&B App une file d’attente qui utilise Kubernetes comme ressource de calcul :

Accédez à la page Launch.
Cliquez sur le bouton Create Queue.
Sélectionnez l’Entity dans lequel vous souhaitez créer la file d’attente.
Saisissez un nom pour votre file d’attente dans le champ Name.
Sélectionnez Kubernetes comme Resource.
Dans le champ Configuration, indiquez la spécification du flux de travail du job Kubernetes ou la spécification de ressource personnalisée que vous avez configurée dans Configurer une file d’attente pour Kubernetes.

Configurer un agent Launch avec Helm

Une fois la file d’attente en place, déployez l’agent Launch, qui récupère les jobs de la file d’attente et les exécute sur votre cluster. Utilisez le chart Helm fourni par W&B pour déployer l’agent Launch dans votre cluster Kubernetes. Contrôlez le comportement de l’agent Launch à l’aide du fichier values.yaml. Dans la clé launchConfig du fichier values.yaml, indiquez le contenu que vous définiriez normalement dans le fichier de configuration de votre agent Launch (~/.config/wandb/launch-config.yaml). Par exemple, supposons que vous disposiez d’une configuration permettant d’exécuter un agent Launch dans EKS avec le générateur d’images Docker Kaniko. Remplacez [QUEUE-NAME], [MAX-CONCURRENT-JOBS], [MY-REGISTRY-URI] et [S3-BUCKET-URI] par vos propres valeurs :

launch-config.yaml

queues:
  - [QUEUE-NAME]
max_jobs: [MAX-CONCURRENT-JOBS]
environment:
  type: aws
  region: us-east-1
registry:
  type: ecr
  uri: [MY-REGISTRY-URI]
builder:
  type: kaniko
  build-context-store: [S3-BUCKET-URI]

Dans votre fichier values.yaml, cela peut se présenter comme suit. Remplacez [QUEUE-NAME], [MAX-CONCURRENT-JOBS], [AWS-REGION], [MY-REGISTRY-URI] et [S3-BUCKET-URI] par vos propres valeurs :

values.yaml

agent:
  labels: {}
  # Clé API W&B.
  apiKey: ''
  # Image de conteneur à utiliser pour l’agent.
  image: wandb/launch-agent:latest
  # Stratégie de récupération de l’image de l’agent.
  imagePullPolicy: Always
  # Bloc des ressources de la spécification de l’agent.
  resources:
    limits:
      cpu: 1000m
      memory: 1Gi

# namespace dans lequel déployer l’agent Launch
namespace: wandb

# URL de l’API W&B (indiquez la vôtre ici)
baseUrl: https://api.wandb.ai

# namespace cibles supplémentaires dans lesquels l’agent Launch peut déployer
additionalTargetNamespaces:
  - default
  - wandb

# Indiquez ici le contenu exact de la configuration de votre agent Launch.
launchConfig: |
  queues:
    - [QUEUE-NAME]
  max_jobs: [MAX-CONCURRENT-JOBS]
  environment:
    type: aws
    region: [AWS-REGION]
  registry:
    type: ecr
    uri: [MY-REGISTRY-URI]
  builder:
    type: kaniko
    build-context-store: [S3-BUCKET-URI]

# Contenu d’un fichier d’identifiants d’authentification git. Il est stocké dans un secret k8s
# et monté dans le conteneur de l’agent. Définissez-le si vous souhaitez cloner des dépôts
# privés.
gitCreds: |

# Annotations du compte de service wandb. Utiles pour configurer Workload Identity sur GCP.
serviceAccount:
  annotations:
    iam.gke.io/gcp-service-account:
    azure.workload.identity/client-id:

# Indiquez la clé d’accès du stockage Azure si vous utilisez Kaniko avec Azure.
azureStorageAccessKey: ''

Pour en savoir plus sur les registres, les environnements et les autorisations requises par l’agent, consultez Configuration avancée de l’agent.

​Configurer une file d’attente pour Kubernetes

​Créer une file d’attente

​Configurer un agent Launch avec Helm

Configurer une file d’attente pour Kubernetes

Créer une file d’attente

Configurer un agent Launch avec Helm