メインコンテンツへスキップ
W&B Launch を使用すると、ML ワークロードを Kubernetes クラスターにプッシュできます。これにより、ML エンジニアは、Kubernetes で既に管理しているリソースを、W&B 上のシンプルなインターフェースから利用できます。 W&B は、公式 Launch エージェントイメージを提供しており、W&B が管理する Helm チャートを使ってクラスターにデプロイできます。 W&B は Kaniko ビルダーを使用して、Launch エージェントが Kubernetes クラスター内で Docker イメージをビルドできるようにしています。Launch エージェント用に Kaniko を設定する方法や、ジョブのビルドを無効にしてビルド済みの Docker イメージのみを使用する方法について詳しくは、高度なエージェント設定を参照してください。
Helm をインストールし、W&B の Launch エージェント Helm チャートを適用またはアップグレードするには、Kubernetes リソースを作成、更新、削除するための十分な権限を持つクラスターへの kubectl アクセスが必要です。通常は、cluster-admin 権限を持つユーザー、または同等の権限を持つ custom role が必要です。

​
Kubernetes向けのキューを設定する

Kubernetesのターゲットリソースに対するLaunchのキュー設定は、Kubernetes Job spec または Kubernetes Custom Resource spec のいずれかに似たものになります。 Launchキューの作成時には、Kubernetesワークロードリソースの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
セキュリティ上の理由から、次のリソースが指定されていない場合、W&BはそれらをLaunchキューに追加します。
  • securityContext
  • backOffLimit
  • ttlSecondsAfterFinished
次のYAMLスニペットは、これらの値がLaunchキュー内でどのように表示されるかを示しています。
example-spec.yaml
spec:
  template:
    `backOffLimit`: 0
    ttlSecondsAfterFinished: 60
    securityContext:
      allowPrivilegeEscalation: False,
      capabilities:
        drop:
          - ALL,
      seccompProfile:
        type: "RuntimeDefault"

​
キューを作成する

Kubernetes をコンピュートリソースとして使用するキューを W&B App で作成します。
  1. Launch ページにアクセスします。
  2. Create Queue ボタンをクリックします。
  3. キューを作成する Entity を選択します。
  4. Name フィールドにキューの名前を入力します。
  5. Resource として Kubernetes を選択します。
  6. Configuration フィールドに、前のセクションで設定した Kubernetes Job workflow spec または Custom Resource spec を指定します。

​
Helm を使用して Launch エージェントを設定する

W&B が提供する Helm チャート を使用して、Kubernetes クラスターに Launch エージェントをデプロイします。Launch エージェントの動作は、values.yaml ファイル で制御します。 通常は Launch エージェントの設定ファイル (~/.config/wandb/launch-config.yaml) で定義する内容を、values.yaml ファイル内の launchConfig キーに指定します。 たとえば、Kaniko Docker イメージビルダーを使用する EKS 上で Launch エージェントを実行できるようにする Launch エージェント設定があるとします。
launch-config.yaml
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 ファイル内では、次のようになります。
values.yaml
agent:
  labels: {}
  # W&B APIキー。
  apiKey: ''
  # エージェントに使用するコンテナーイメージ。
  image: wandb/launch-agent:latest
  # エージェントイメージのイメージプルポリシー。
  imagePullPolicy: Always
  # エージェント仕様のリソースブロック。
  resources:
    limits:
      cpu: 1000m
      memory: 1Gi

# Launch エージェントをデプロイする名前空間
namespace: wandb

# W&B API URL（ご自身のURLを設定してください）
baseUrl: https://api.wandb.ai

# Launch エージェントがデプロイできる追加のターゲット名前空間
additionalTargetNamespaces:
  - default
  - wandb

# 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>

# git 認証情報ファイルの内容。k8s シークレットに保存され、
# エージェントコンテナーにマウントされます。プライベートリポジトリを
# クローンする場合に設定してください。
gitCreds: |

# wandb サービスアカウントのアノテーション。GCP でワークロードアイデンティティを設定する際に役立ちます。
serviceAccount:
  annotations:
    iam.gke.io/gcp-service-account:
    azure.workload.identity/client-id:

# Azure で Kaniko を使用する場合は、Azure ストレージのアクセスキーを設定してください。
azureStorageAccessKey: ''
レジストリ、環境、必須のエージェント権限の詳細については、高度なエージェント設定を参照してください.