W&B Launch를 사용하면 ML 워크로드를 Kubernetes 클러스터에서 실행하도록 보내, ML 엔지니어가 이미 Kubernetes로 관리 중인 리소스를 W&B에서 제공하는 간단한 인터페이스로 바로 활용할 수 있습니다.
W&B는 클러스터에 배포할 수 있는 공식 Launch agent 이미지를 제공하며, 이 이미지는 W&B에서 관리하는 Helm 차트를 통해 배포할 수 있습니다.
W&B는 Kaniko 빌더를 사용하여 Launch agent가 Kubernetes 클러스터에서 Docker 이미지를 빌드할 수 있도록 합니다. Launch agent용 Kaniko 설정 방법 또는 잡 빌드를 비활성화하고 미리 빌드된 Docker 이미지만 사용하는 방법에 대해 더 알아보려면 고급 agent 설정을 참조하세요.
Helm을 설치하고 W&B의 Launch agent Helm 차트를 적용하거나 업그레이드하려면, Kubernetes 리소스를 생성·업데이트·삭제할 수 있을 만큼 충분한 권한으로 kubectl을 통해 해당 클러스터에 접근할 수 있어야 합니다. 일반적으로 cluster-admin 권한이 있는 사용자 또는 동등한 권한을 가진 커스텀 역할이 필요합니다.
Kubernetes 대상 리소스를 위한 Launch 큐 구성은 Kubernetes Job spec 또는 Kubernetes Custom Resource spec과 유사합니다.
Launch 큐를 생성할 때 Kubernetes 워크로드 리소스 스펙의 모든 항목을 제어할 수 있습니다.
Kubernetes job spec
Custom resource spec
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
일부 사용 사례에서는 CustomResource 정의를 사용하고자 할 수 있습니다. 예를 들어, 다중 노드 분산 학습을 수행하려는 경우 CustomResource 정의가 유용합니다. 예제 애플리케이션은 Volcano를 사용하여 다중 노드 Job에서 Launch를 사용하는 튜토리얼을 참조하십시오. 또 다른 사용 사례로는 Kubeflow와 함께 W&B Launch를 사용하고자 하는 경우가 있을 수 있습니다.다음 YAML 스니펫은 Kubeflow를 사용하는 샘플 Launch 큐 구성을 보여줍니다: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
보안상의 이유로, 아래 리소스들이 지정되지 않은 경우 W&B는 Launch 큐에 다음 리소스들을 자동으로 추가합니다:
securityContext
backOffLimit
ttlSecondsAfterFinished
다음 YAML 스니펫은 이러한 값들이 Launch 큐에 어떻게 표시되는지 보여줍니다:
spec:
template:
`backOffLimit`: 0
ttlSecondsAfterFinished: 60
securityContext:
allowPrivilegeEscalation: False,
capabilities:
drop:
- ALL,
seccompProfile:
type: "RuntimeDefault"
Kubernetes를 컴퓨트 리소스로 사용하는 큐를 W&B 앱에서 생성합니다:
- Launch 페이지로 이동합니다.
- Create Queue 버튼을 클릭합니다.
- 큐를 생성할 Entity를 선택합니다.
- Name 필드에 큐 이름을 입력합니다.
- Resource로 Kubernetes를 선택합니다.
- Configuration 필드에 이전 섹션에서 설정한 Kubernetes Job 워크플로 사양 또는 Custom Resource 사양을 입력합니다.
W&B에서 제공하는 Helm 차트를 사용하여 Kubernetes 클러스터에 Launch agent를 배포하세요. values.yaml 파일로 Launch agent의 동작을 제어할 수 있습니다.
일반적으로 Launch agent 설정 파일(~/.config/wandb/launch-config.yaml)에 정의하는 내용을 values.yaml 파일의 launchConfig 키에 지정합니다.
예를 들어, EKS에서 Kaniko Docker 이미지 빌더를 사용하는 Launch agent를 실행할 수 있도록 하는 Launch agent 설정이 있다고 가정해 봅시다:
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 파일에서는 다음과 같이 설정합니다:
agent:
labels: {}
# W&B API key.
apiKey: ''
# 에이전트에 사용할 컨테이너 이미지.
image: wandb/launch-agent:latest
# 에이전트 이미지의 이미지 풀 정책.
imagePullPolicy: Always
# 에이전트 스펙의 리소스 블록.
resources:
limits:
cpu: 1000m
memory: 1Gi
# Namespace to deploy launch agent into
namespace: wandb
# W&B api url (Set yours here)
baseUrl: https://api.wandb.ai
# Additional target namespaces that the launch agent can deploy into
additionalTargetNamespaces:
- default
- wandb
# This should be set to the literal contents of your launch agent config.
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>
# The contents of a git credentials file. This will be stored in a k8s secret
# and mounted into the agent container. Set this if you want to clone private
# repos.
gitCreds: |
# Annotations for the wandb service account. Useful when setting up workload identity on gcp.
serviceAccount:
annotations:
iam.gke.io/gcp-service-account:
azure.workload.identity/client-id:
# Set to access key for azure storage if using kaniko with azure.
azureStorageAccessKey: ''
레지스트리, 환경 및 필요한 에이전트 권한에 대한 자세한 내용은 고급 에이전트 설정을 참고하세요.