Vous pouvez utiliser W&B Launch pour déployer des charges de travail ML sur un cluster Kubernetes, ce qui offre aux ingénieurs ML une interface simple directement dans W&B pour exploiter les ressources que vous gérez déjà avec Kubernetes.
W&B propose une image officielle de l’agent Launch, qui peut être déployée sur votre cluster à l’aide d’un chart Helm maintenu par W&B.
W&B utilise Kaniko 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 façon de désactiver la création de jobs et d’utiliser uniquement des images Docker préconstruites, voir Configuration avancée de l’agent.
Pour installer Helm et appliquer ou mettre à niveau le chart Helm de l’agent Launch de W&B, 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, un utilisateur disposant du rôle cluster-admin, ou d’un rôle personnalisé avec des autorisations équivalentes, est requis.
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 pouvez vouloir utiliser des définitions CustomResource. Les définitions CustomResource sont utiles si, par exemple, 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. Vous pouvez également vouloir utiliser W&B 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
securityContextbackOffLimitttlSecondsAfterFinished
L’extrait YAML suivant montre comment ces valeurs apparaîtront dans votre file d’attente Launch :
spec:
template:
`backOffLimit`: 0
ttlSecondsAfterFinished: 60
securityContext:
allowPrivilegeEscalation: False,
capabilities:
drop:
- ALL,
seccompProfile:
type: "RuntimeDefault"
- Accédez à la page Launch.
- Cliquez sur le bouton Create Queue.
- Sélectionnez l’Entity dans laquelle 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 workflow job Kubernetes ou la spécification de Ressource personnalisée que vous avez configurée dans la section précédente.
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 avec le fichier values.yaml.
Indiquez, dans la clé launchConfig du fichier values.yaml, le contenu qui serait normalement défini dans votre fichier de configuration de l’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 à l’aide du builder d’image Docker Kaniko :
queues:
- <queue name>
max_jobs: <n 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>
values.yaml, vous pourriez avoir quelque chose comme ceci :
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
# 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
# Namespaces cibles supplémentaires dans lesquels l'agent Launch peut déployer
additionalTargetNamespaces:
- default
- wandb
# Doit contenir le contenu littéral de votre configuration d'agent Launch.
launchConfig: |
queues:
- <queue name>
max_jobs: <n 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éfinir 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éfinir avec la clé d'accès au stockage azure si vous utilisez kaniko avec azure.
azureStorageAccessKey: ''
