Tutoriel : Configurer W&B Launch sur Kubernetes

Configurer W&B Launch sur un cluster Kubernetes à l’aide de charts Helm, de la création d’images avec Kaniko et de spécifications de jobs Kubernetes.

Ce tutoriel explique aux administrateurs de cluster comment configurer 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. Vous pouvez utiliser W&B Launch pour envoyer des charges de travail ML vers un cluster Kubernetes, ce qui offre aux ingénieurs ML une interface directement dans W&B pour utiliser les ressources que vous gérez déjà avec Kubernetes.

W&B propose une image officielle de l’agent Launch que vous pouvez déployer sur votre cluster à l’aide d’un chart Helm maintenu par W&B.

W&B utilise Kaniko comme outil de build pour permettre à l’agent Launch de créer des images Docker dans un cluster Kubernetes. Pour en savoir plus sur la configuration de Kaniko pour l’agent Launch, ou sur la manière de désactiver la création de jobs et d’utiliser uniquement des images Docker déjà créées, voir 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 général, cela nécessite un utilisateur disposant du rôle cluster-admin ou d’un rôle personnalisé avec des autorisations équivalentes.

​

Configurer une file d’attente pour Kubernetes

Une file d’attente Launch définit la spécification de workload Kubernetes que l’agent utilise pour exécuter chaque job. La configuration d’une file d’attente Launch pour une ressource cible Kubernetes prendra la forme soit d’une spécification de job Kubernetes, soit d’une spécification de ressource personnalisée Kubernetes.

Vous pouvez contrôler n’importe quel aspect de la spécification de la ressource de workload Kubernetes lorsque vous créez une file d’attente Launch.

Spécification de job Kubernetes

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

Spécification de ressource personnalisée

Dans certains cas, vous pouvez vouloir utiliser des définitions CustomResource. Par exemple, les définitions CustomResource sont utiles lorsque vous souhaitez effectuer un entraînement distribué sur plusieurs nœuds. Voir le tutoriel sur l’utilisation de Launch avec des jobs multi-nœuds utilisant Volcano pour voir un exemple d’utilisation. Un autre cas d’usage est celui où vous souhaitez utiliser Launch avec Kubeflow.

L’extrait YAML suivant montre un exemple de configuration de file d’attente Launch qui utilise 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 une file d’attente dans la W&B App en utilisant Kubernetes comme ressource de calcul :

1. Accédez à la page Launch.
2. Cliquez sur le bouton Create Queue.
3. Sélectionnez l’Entity dans laquelle vous souhaitez créer la file d’attente.
4. Saisissez un nom pour votre file d’attente dans le champ Name.
5. Sélectionnez Kubernetes comme Resource.
6. Dans le champ Configuration, indiquez la spécification du workflow 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 créée, déployez l’agent Launch qui récupère les jobs dans 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 d’agent Launch vous 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
  # Politique de récupération d'image pour l'image de l'agent.
  imagePullPolicy: Always
  # Bloc de ressources pour la spécification de l'agent.
  resources:
    limits:
      cpu: 1000m
      memory: 1Gi

# Espace de noms 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

# Espaces de noms cibles supplémentaires dans lesquels l'agent Launch peut effectuer des déploiements
additionalTargetNamespaces:
  - default
  - wandb

# Doit contenir le contenu littéral de votre fichier de configuration de l'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]

# Le contenu d'un fichier de credentials git. Il sera stocké dans un secret k8s
# et monté dans le conteneur de l'agent. Définissez cette valeur si vous souhaitez cloner des
# dépôts privés.
gitCreds: |

# Annotations pour le compte de service wandb. Utile lors de la configuration de l'identité de charge de travail sur GCP.
serviceAccount:
  annotations:
    iam.gke.io/gcp-service-account:
    azure.workload.identity/client-id:

# Définissez la clé d'accès au stockage Azure si vous utilisez Kaniko avec Azure.
azureStorageAccessKey: ''

Pour plus d’informations sur les registries, les environnements et les autorisations d’agent requises, voir Configuration avancée de l’agent.