> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Tutoriel : configurer W&B Launch sur Kubernetes
> Configurez 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 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](https://hub.docker.com/r/wandb/launch-agent) que vous pouvez déployer sur votre cluster à l’aide d’un [chart Helm](https://github.com/wandb/helm-charts/tree/main/charts/launch-agent) également maintenu par W\&B.
W\&B utilise le générateur [Kaniko](https://github.com/GoogleContainerTools/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](/fr/products/wandb/platform/launch/setup-agent-advanced).
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.
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](https://kubernetes.io/docs/concepts/workloads/controllers/job/), soit à une [spécification de ressource personnalisée Kubernetes](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
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.
```yaml theme={"system"}
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 :
```yaml theme={"system"}
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 :
```yaml title="example-spec.yaml" theme={"system"}
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 :
1. Accédez à la [page Launch](https://forge.coreweave.com/wandb/launch).
2. Cliquez sur le bouton **Create Queue**.
3. Sélectionnez l'**Entity** dans lequel 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 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](#configure-a-queue-for-kubernetes).
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](https://github.com/wandb/helm-charts/tree/main/charts/launch-agent) 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](https://github.com/wandb/helm-charts/blob/main/charts/launch-agent/values.yaml) `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 :
```yaml title="launch-config.yaml" theme={"system"}
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 :
```yaml title="values.yaml" theme={"system"}
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](/fr/products/wandb/platform/launch/setup-agent-advanced).