> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wandb.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# 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](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) maintenu par W\&B.
W\&B utilise [Kaniko](https://github.com/GoogleContainerTools/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](./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 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](https://kubernetes.io/docs/concepts/workloads/controllers/job/), soit d’une [spécification de ressource personnalisée Kubernetes](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
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.
```yaml theme={null}
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`. 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 :
```yaml theme={null}
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={null}
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](https://wandb.ai/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](#configure-a-queue-for-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](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 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 :
```yaml title="launch-config.yaml" theme={null}
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={null}
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](./setup-agent-advanced).