Kubernetes에서 W&B Server 실행하기 - Weights & Biases Documentation

W&B Kubernetes Operator

Kubernetes에서 W&B Server를 보다 쉽게 배포, 운영, 문제 해결 및 확장하려면 W&B Kubernetes Operator를 사용하세요. 이 Operator는 W&B 인스턴스를 위한 스마트한 도우미라고 생각할 수 있습니다. W&B Server 아키텍처와 설계는 AI 개발자 도구 기능을 확장하고, 고성능·우수한 확장성·간편한 관리를 위한 적절한 기본 구성 요소를 제공하기 위해 지속적으로 발전하고 있습니다. 이러한 변화는 컴퓨트 서비스, 관련 스토리지, 그리고 이들 간의 연결성 전반에 적용됩니다. 배포 유형 전반에 걸친 지속적인 업데이트와 개선을 지원하기 위해 W&B는 Kubernetes Operator를 사용합니다.

W&B는 AWS, Google Cloud, Azure 퍼블릭 클라우드에서 Dedicated Cloud 인스턴스를 배포하고 관리하기 위해 Operator를 사용합니다.

Kubernetes Operator에 대한 자세한 내용은 Kubernetes 문서의 Operator pattern을 참고하세요.

아키텍처 변경의 이유

과거에는 W&B 애플리케이션을 Kubernetes 클러스터 내의 단일 deployment 및 pod, 또는 단일 Docker 컨테이너로 배포했습니다. W&B는 예전부터 지금까지 데이터베이스와 오브젝트 스토어를 외부로 분리해 구성할 것을 권장해 왔습니다. 데이터베이스와 오브젝트 스토어를 외부화하면 애플리케이션의 상태를 디커플링(decouple)할 수 있습니다. 애플리케이션이 성장함에 따라, 모놀리식 컨테이너에서 분산 시스템(마이크로서비스)으로 전환해야 할 필요성이 분명해졌습니다. 이 변경을 통해 백엔드 로직 처리가 용이해지고, Kubernetes의 내장 인프라 기능을 자연스럽게 도입할 수 있습니다. 분산 시스템은 또한 W&B가 의존하는 추가 기능을 위해 필요한 신규 서비스를 배포할 수 있게 해줍니다. 2024년 이전에는 Kubernetes 관련 변경 사항이 있을 때마다 terraform-kubernetes-wandb Terraform 모듈을 수동으로 업데이트해야 했습니다. Terraform 모듈을 업데이트해야 클라우드 제공업체 간 호환성을 보장하고, 필요한 Terraform 변수들을 구성하며, 각 백엔드 또는 Kubernetes 레벨 변경마다 terraform apply를 실행할 수 있습니다. 이 과정은 W&B 지원팀이 각 고객의 Terraform 모듈 업그레이드를 일일이 도와야 했기 때문에 확장성이 좋지 않았습니다. 이에 대한 해결책으로, 중앙 deploy.wandb.ai 서버에 연결하여 지정된 릴리스 채널에 대한 최신 스펙 변경 사항을 요청하고 이를 적용하는 오퍼레이터를 도입했습니다. 라이선스가 유효한 동안 업데이트를 계속 받을 수 있습니다. Helm은 W&B 오퍼레이터의 배포 메커니즘이자, 오퍼레이터가 W&B Kubernetes 스택의 모든 구성 템플릿을 처리하는 수단으로 사용됩니다. 이른바 “Helm-ception”입니다.

작동 방식

operator는 Helm 또는 소스에서 설치할 수 있습니다. 자세한 설치 방법은 charts/operator를 참조하세요. 설치 과정에서는 controller-manager라는 deployment를 생성하고, weightsandbiases.apps.wandb.com(shortName: wandb)이라는 custom resource definition을 사용합니다. 이 definition은 단일 spec을 입력으로 받아 클러스터에 적용합니다:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: weightsandbiases.apps.wandb.com

controller-manager는 커스텀 리소스의 스펙, 릴리스 채널, 그리고 사용자 정의 설정을 기반으로 charts/operator-wandb를 설치합니다. 구성 스펙 계층 구조는 사용자 측에 최대한의 구성 유연성을 제공하며, W&B가 새로운 이미지, 구성, 기능, 그리고 Helm 업데이트를 자동으로 릴리스할 수 있도록 합니다. 구성 옵션에 대해서는 구성 스펙 계층 구조와 구성 레퍼런스를 참고하세요. 배포는 여러 개의 파드로 구성되며, 서비스당 하나의 파드가 생성됩니다. 각 파드의 이름 앞에는 wandb- 접두사가 붙습니다.

구성 사양 우선순위 계층

구성 사양은 상위 수준 사양이 하위 수준 사양보다 우선 적용되는 계층적 모델을 따릅니다. 동작 방식은 다음과 같습니다:

Release Channel 값: 이 기본 수준 구성은 W&B가 배포에 대해 설정한 릴리스 채널에 따라 기본 값과 구성을 설정합니다.
사용자 입력 값: 사용자는 System Console을 통해 Release Channel 사양에서 제공되는 기본 설정을 변경(재정의)할 수 있습니다.
Custom Resource 값: 사용자로부터 오는 가장 높은 수준의 사양입니다. 여기에서 지정한 모든 값은 사용자 입력 값과 Release Channel 사양보다 우선 적용됩니다. 구성 옵션에 대한 자세한 설명은 Configuration Reference를 참조하세요.

이 계층적 모델을 통해 구성을 다양한 요구 사항에 맞게 유연하게 사용자 정의하면서도, 업그레이드와 변경을 체계적이고 관리 가능한 방식으로 유지할 수 있습니다.

시작하기 전에

다음을 포함한 전체 인프라 요구 사항은 참조 아키텍처를 참고하세요.

소프트웨어 버전 요구 사항(Kubernetes, MySQL, Redis, Helm)
- 하드웨어 요구 사항(CPU 아키텍처, 권장 사양)
- 네트워킹, SSL/TLS 및 DNS 요구 사항

유효한 W&B Server 라이선스를 확보하세요.
W&B Self-Managed를 설정하고 구성하는 상세한 방법은 다음 섹션과 베어 메탈 설치 가이드를 참고하세요. 설치 방법에 따라 추가 소프트웨어를 설치하거나 추가 요구 사항을 충족해야 할 수 있습니다.

MySQL 데이터베이스

W&B는 외부 MySQL 데이터베이스가 필요합니다. 운영(프로덕션) 환경에서는 관리형 데이터베이스 서비스를 사용할 것을 W&B에서 강력히 권장합니다:

관리형 데이터베이스 서비스는 자동 백업, 모니터링, 고가용성, 패치 적용 등을 제공하며 운영 부담을 줄여줍니다. 사이징 권장 사항 및 구성 파라미터를 포함한 전체 MySQL 요구 사항은 참조 아키텍처를 참조하세요. 데이터베이스 생성용 SQL은 베어 메탈 가이드를 확인하세요. 배포 환경의 데이터베이스 구성에 대한 질문이 있는 경우 support 또는 담당 AISE에 문의하세요.

Redis

W&B는 작업 큐 처리와 데이터 캐싱을 위해 W&B 구성 요소에서 사용하는 단일 노드 Redis 7.x 배포에 의존합니다. 개념 검증(PoC)의 테스트 및 개발 편의를 위해 W&B Self-Managed에는 프로덕션 배포 환경에는 적합하지 않은 로컬 Redis 배포가 포함되어 있습니다. 프로덕션 배포 환경의 경우, W&B는 다음 환경의 Redis 인스턴스에 연결할 수 있습니다:

AWS Elasticache
Google Cloud Memory Store
Azure Cache for Redis
사용자의 클라우드 또는 온프레미스 인프라에 호스팅된 Redis 배포

외부 Redis 인스턴스를 구성하는 방법은 External Redis 구성 섹션을 참고하세요.

오브젝트 스토리지

W&B는 pre-signed URL 및 CORS를 지원하는 오브젝트 스토리지가 필요합니다. 프로덕션 배포 시 W&B는 다음과 같은 매니지드 오브젝트 스토리지 서비스 사용을 권장합니다:

Amazon S3: 업계 최고 수준의 확장성, 데이터 가용성, 보안 및 성능을 제공하는 오브젝트 스토리지 서비스.
Google Cloud Storage: 비정형 데이터를 대규모로 저장하기 위한 매니지드 서비스.
Azure Blob Storage: 대량의 비정형 데이터를 저장하기 위한 클라우드 기반 오브젝트 스토리지 솔루션.
CoreWeave AI Object Storage: AI 워크로드에 최적화된 고성능 S3 호환 오브젝트 스토리지 서비스.

자가 호스팅 오브젝트 스토리지 옵션에 대해서는 CORS 구성과 엔터프라이즈 대안을 포함한 자세한 설정 방법을 보려면 베어메탈 가이드 오브젝트 스토리지 섹션을 참고하십시오.

MinIO Open Source는 활성 개발 및 사전 컴파일된 바이너리 없이 유지 관리 모드에 있습니다. 프로덕션 배포의 경우, W&B는 매니지드 오브젝트 스토리지 서비스 또는 엔터프라이즈급 S3 호환 솔루션 사용을 권장합니다.

전체 요구 사항은 레퍼런스 아키텍처 오브젝트 스토리지 섹션을 참고하십시오. Helm values에서 오브젝트 스토리지를 구성하는 방법에 대한 자세한 내용은 오브젝트 스토리지 구성 섹션을 참고하세요.

네트워킹 요구 사항

네트워크로 구성된 배포 환경에서는 설치 및 실행 시간 둘 다 동안 다음 엔드포인트로의 아웃바운드 트래픽(egress)이 필요합니다:

배포 구성에 따라 추가 컨테이너 레지스트리가 필요할 수 있습니다:

Weave 온라인 평가를 위해 Bufstream 및 etcd를 배포할 때는 https://gcr.io가 필요합니다.

에어갭(air-gapped) 배포에 대해 알아보려면 에어갭 인스턴스를 위한 Kubernetes operator를 참조하세요. 학습 인프라와 실험을 추적하는 각 시스템은 W&B 및 오브젝트 스토리지에 대한 접근 권한이 필요합니다. 로드 밸런서 및 인그레스 컨트롤러 옵션과 구성 예시는 참조 아키텍처 로드 밸런서 섹션을 참조하세요.

SSL/TLS 요구 사항

W&B는 클라이언트와 서버 간의 보안 통신을 위해 유효한 서명 SSL/TLS 인증서를 요구합니다. SSL/TLS 종료(termination)는 반드시 인그레스/로드 밸런서에서 이루어져야 합니다. W&B Server 애플리케이션은 SSL 또는 TLS 연결을 종료하지 않습니다. 중요: W&B는 자체 서명 인증서 및 커스텀 CA(인증 기관)를 지원하지 않습니다. 자체 서명 인증서를 사용하면 사용자에게 문제가 발생하므로 지원되지 않습니다. 가능하다면 Let’s Encrypt와 같은 서비스를 사용하여 로드 밸런서에 신뢰할 수 있는 인증서를 제공하는 것이 좋습니다. Caddy 및 Cloudflare와 같은 서비스는 SSL을 대신 관리해 줍니다. 보안 정책상 신뢰할 수 있는 내부 네트워크 내에서도 SSL 통신이 필요한 경우, Istio 및 sidecar 컨테이너와 같은 도구의 사용을 고려하십시오.

에어갭 환경에서의 설치

에어갭 환경에서 W&B Kubernetes Operator를 설치하는 방법은 Kubernetes를 사용해 에어갭 환경에 W&B 배포하기 튜토리얼을 참고하세요.

OpenShift Kubernetes clusters

W&B는 클라우드, 온프레미스, 에어갭 환경의 OpenShift Kubernetes 클러스터에 대한 배포를 지원합니다.

W&B는 공식 W&B Helm 차트를 사용해 설치할 것을 권장합니다.

비특권 사용자로 컨테이너 실행

기본적으로 컨테이너는 $UID가 999인 사용자로 실행됩니다. 오케스트레이터가 컨테이너를 non-root 사용자로 실행하도록 요구하는 경우 $UID >= 100000 및 $GID 0을 지정하십시오.

파일 시스템 권한이 올바르게 동작하려면 W&B는 루트 그룹($GID=0)으로 시작해야 합니다.

각 W&B 구성 요소에 대해 security context를 구성하십시오. 예를 들어 API 구성 요소를 구성하려면 다음과 같이 합니다:

api:
  install: true
  image:
    repository: wandb/megabinary
    tag: 0.74.1
  pod:
    securityContext:
      fsGroup: 10001
      fsGroupChangePolicy: Always
      runAsGroup: 0
      runAsNonRoot: true
      runAsUser: 10001
      seccompProfile:
        type: RuntimeDefault
  container:
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
      privileged: false
      readOnlyRootFilesystem: false

필요한 경우 app 또는 console과 같은 다른 컴포넌트에도 사용자 정의 보안 컨텍스트를 구성하세요. 자세한 내용은 사용자 정의 보안 컨텍스트를 참조하세요.

W&B Server 애플리케이션 배포

Helm을 사용하는 W&B Kubernetes Operator는 클라우드, 온프레미스, 에어갭 환경을 포함한 모든 W&B Self-Managed 배포에 대해 권장되는 설치 방법입니다.

이 섹션에서는 W&B Kubernetes Operator를 배포하는 다양한 방법을 설명합니다:

Helm CLI: Helm 명령을 사용한 직접 배포
Helm Terraform Module: 코드형 인프라(IaC)를 통한 배포
W&B Cloud Terraform Modules: AWS, Google Cloud, Azure용 전체 인프라 + 애플리케이션 배포

배포별 추가 고려 사항은 다음을 참조하세요:

데이터 센터/베어 메탈 환경: 온프레미스에서 W&B Platform 배포
외부 네트워크와 분리된 환경: 에어갭 인스턴스를 위한 Kubernetes Operator

Helm CLI로 W&B 배포

W&B는 W&B Kubernetes operator를 Kubernetes 클러스터에 배포하기 위한 Helm 차트를 제공합니다. 이 방법을 사용하면 Helm CLI 또는 ArgoCD 같은 지속적 전달 도구로 W&B Server를 배포할 수 있습니다. 위에서 언급한 요구 사항이 모두 충족되었는지 확인하십시오. Helm CLI로 W&B Kubernetes Operator를 설치하려면 다음 단계를 따르십시오:

W&B Helm 저장소를 추가합니다. W&B Helm 차트는 W&B Helm 저장소에서 사용할 수 있습니다:
```
helm repo add wandb https://charts.wandb.ai
helm repo update
```

Kubernetes 클러스터에 Operator를 설치합니다:

helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace

W&B Server 설치를 트리거하기 위해 W&B operator 커스텀 리소스를 구성합니다. W&B 배포 구성이 포함된 operator.yaml 파일을 생성합니다. 사용 가능한 모든 옵션은 Configuration Reference를 참조하십시오. 최소 구성 예시는 다음과 같습니다:

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://&lt;HOST_URI&gt;
      license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
      bucket:
        &lt;details depend on the provider&gt;
      mysql:
        &lt;redacted&gt;
    ingress:
      annotations:
        &lt;redacted&gt;

사용자 정의 구성을 사용해 Operator를 시작하여 W&B Server 애플리케이션을 설치, 구성, 관리하도록 합니다:
```
kubectl apply -f operator.yaml
```
배포가 완료될 때까지 기다립니다. 몇 분 정도 소요됩니다.
웹 UI에서 설치를 확인하려면 먼저 첫 번째 관리자 사용자 계정을 생성한 다음 Verify the installation에 설명된 확인 단계를 따르십시오.

Helm Terraform Module을 사용하여 W&B 배포

이 방법은 Terraform의 인프라스트럭처-애즈-코드 접근 방식을 활용해 일관성과 재현성을 보장하면서, 특정 요구 사항에 맞춘 커스터마이즈된 배포를 가능하게 합니다. 공식 W&B Helm 기반 Terraform Module은 여기에 있습니다. 다음 코드는 시작점으로 사용할 수 있으며, 프로덕션 환경 수준 배포에 필요한 모든 구성 옵션을 포함합니다.

module "wandb" {
  source  = "wandb/wandb/helm"

  spec = {
    values = {
      global = {
        host    = "https://<HOST_URI>"
        license = "eyJhbGnUzaH...j9ZieKQ2x5GGfw"

        bucket = {
          <details depend on the provider>
        }

        mysql = {
          <redacted>
        }
      }

      ingress = {
        annotations = {
          "a" = "b"
          "x" = "y"
        }
      }
    }
  }
}

구성 옵션 자체는 Configuration Reference에 설명된 것과 동일하지만, 구문은 HashiCorp Configuration Language(HCL)를 따라야 합니다. Terraform 모듈은 W&B 사용자 정의 리소스 정의(CRD)를 생성합니다. Weights & Biases에서 고객용 “Dedicated Cloud” 설치를 배포하기 위해 Helm Terraform 모듈을 실제로 어떻게 사용하는지 확인하려면 다음 링크를 참고하십시오:

W&B Cloud Terraform 모듈을 사용해 W&B 배포하기

W&B는 AWS, Google Cloud, Azure용 Terraform 모듈 세트를 제공합니다. 이 모듈들은 Kubernetes 클러스터, 로드 밸런서, MySQL 데이터베이스 등 전체 인프라와 W&B Server 애플리케이션까지 함께 배포합니다. W&B Kubernetes Operator에는 아래 버전의 공식 W&B 클라우드용 Terraform 모듈이 이미 미리 포함되어 있습니다:

Terraform Registry	Source Code	Version
AWS	https://github.com/wandb/terraform-aws-wandb	v4.0.0+
Azure	https://github.com/wandb/terraform-azurerm-wandb	v2.0.0+
Google Cloud	https://github.com/wandb/terraform-google-wandb	v2.0.0+

이 통합으로 인해 W&B Kubernetes Operator는 최소한의 설정만으로도 바로 사용할 수 있으며, 클라우드 환경에서 W&B Server를 배포하고 관리할 수 있는 간편한 경로를 제공합니다. 이 모듈들을 사용하는 방법에 대한 자세한 내용은 문서의 Self-Managed 설치 섹션을 참고하세요.

설치 확인

설치를 검증하려면 W&B는 W&B CLI 사용을 권장합니다. verify 명령은 모든 구성 요소와 구성을 검증하는 여러 테스트를 실행합니다.

이 단계는 브라우저를 사용해 첫 번째 관리자 사용자 계정을 생성했다고 가정합니다.

다음 단계를 따라 설치를 검증하세요:

W&B CLI를 설치합니다:

pip install wandb

W&B에 로그인하기:

wandb login --host=https://YOUR_DNS_DOMAIN

예를 들어:

wandb login --host=https://wandb.company-name.com

설치를 확인하세요:

wandb verify

설치가 성공적으로 완료되고 W&B 배포가 정상적으로 동작하면 다음과 같은 출력이 표시됩니다:

Default host selected:  https://wandb.company-name.com
Find detailed logs for this test at: /var/folders/pn/b3g3gnc11_sbsykqkm3tx5rh0000gp/T/tmpdtdjbxua/wandb
Checking if logged in...................................................✅
Checking signed URL upload..............................................✅
Checking ability to send large payloads through proxy...................✅
Checking requests to base url...........................................✅
Checking requests made over signed URLs.................................✅
Checking CORs configuration of the bucket...............................✅
Checking wandb package version is up to date............................✅
Checking logged metrics, saving and downloading a file..................✅
Checking artifact save and download workflows...........................✅

오류가 발생하면 W&B 지원 팀에 문의하세요.

W&B Management Console에 접속하기

W&B Kubernetes operator에는 Management Console이 포함되어 있습니다. ${HOST_URI}/console 위치에 있으며, 예를 들어 https://wandb.company-name.com/console과 같습니다. W&B Management Console에 로그인하는 방법은 두 가지가 있습니다:

옵션 1 (권장)
옵션 2

브라우저에서 ${HOST_URI}/를 열어 W&B 애플리케이션에 로그인합니다. 예: https://wandb.company-name.com/
콘솔에 접속합니다. 오른쪽 상단의 아이콘을 클릭한 다음 System console을 클릭합니다. 관리자 권한이 있는 사용자만 System console 항목을 볼 수 있습니다.

W&B에서는 옵션 1이 작동하지 않을 때에만, 아래 단계들을 사용해 콘솔에 접속할 것을 권장합니다.

브라우저에서 콘솔 애플리케이션을 엽니다. 위에서 설명한 URL을 열면 로그인 화면으로 리디렉션됩니다:
설치 과정에서 생성된 Kubernetes secret에서 비밀번호를 가져옵니다:
```
kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d
```
비밀번호를 복사합니다.
콘솔에 로그인합니다. 복사한 비밀번호를 붙여넣고 Login을 클릭합니다.

W&B Kubernetes operator 업데이트

이 섹션에서는 W&B Kubernetes operator를 업데이트하는 방법을 설명합니다.

W&B Kubernetes operator를 업데이트해도 W&B Server 애플리케이션은 업데이트되지 않습니다.
W&B Kubernetes operator를 사용하지 않는 Helm 차트를 사용 중이라면, 아래의 W&B operator 업데이트 지침을 진행하기 전에 여기의 안내를 먼저 참조하세요.

아래 코드 스니펫을 복사해 터미널에 붙여넣습니다.

먼저, helm repo update로 리포지토리를 업데이트합니다:
```
helm repo update
```

다음으로, helm upgrade로 Helm 차트를 업데이트합니다:

helm upgrade operator wandb/operator -n wandb-cr --reuse-values

W&B Server 애플리케이션 업데이트

W&B Kubernetes operator를 사용하는 경우, 더 이상 W&B Server 애플리케이션을 직접 업데이트할 필요가 없습니다. operator는 W&B 소프트웨어의 새 버전이 릴리스되면 W&B Server 애플리케이션을 자동으로 업데이트합니다.

Self-Managed 인스턴스를 W&B Operator로 마이그레이션

다음 섹션에서는 사용자가 직접 관리하는 W&B Server 설치 환경을 W&B Operator로 관리하도록 마이그레이션하는 방법을 설명합니다. 마이그레이션 절차는 W&B Server를 어떤 방식으로 설치했는지에 따라 달라집니다:

W&B Operator는 W&B Server의 기본이자 권장되는 설치 방법입니다. 질문이 있다면 Customer Support 또는 담당 W&B 팀에 문의하세요.

공식 W&B Cloud Terraform 모듈을 사용했다면, 해당 문서로 이동하여 안내된 단계를 따르세요:
- AWS
- Google Cloud
- Azure
W&B Non-Operator Helm chart를 사용했다면, 여기로 이동하세요.
W&B Non-Operator Helm chart with Terraform를 사용했다면, 여기로 이동하세요.
Kubernetes 리소스를 매니페스트(manifest)로 직접 생성했다면, 여기로 이동하세요.

Operator 기반 AWS Terraform 모듈로 마이그레이션

마이그레이션 프로세스에 대한 자세한 설명은 여기를 참조하세요.

Operator 기반 Google Cloud Terraform 모듈로 마이그레이션

질문이 있거나 도움이 필요하면 Customer Support 또는 담당 W&B 팀에 문의하세요.

Operator 기반 Azure Terraform 모듈로 마이그레이션

문의 사항이 있거나 도움이 필요하시면 고객 지원팀 또는 담당 W&B 팀에 문의하세요.

Operator 기반 Helm 차트로 마이그레이션

다음 단계를 따라 Operator 기반 Helm 차트로 마이그레이션합니다:

현재 W&B 설정을 가져옵니다. W&B가 Operator 기반이 아닌 버전의 Helm 차트로 배포된 경우, 다음과 같이 values를 내보냅니다:
```
helm get values wandb
```
W&B가 Kubernetes 매니페스트로 배포된 경우, 다음과 같이 values를 내보냅니다:
```
kubectl get deployment wandb -o yaml
```
이제 다음 단계에 필요한 모든 설정 값을 확보했습니다.
operator.yaml이라는 파일을 생성합니다. Configuration Reference에 설명된 형식을 따르세요. 1단계에서 가져온 값을 사용합니다.
현재 배포를 파드 0개로 스케일링합니다. 이 단계에서 현재 배포가 중지됩니다.
```
kubectl scale --replicas=0 deployment wandb
```
Helm 차트 저장소를 업데이트합니다:
```
helm repo update
```

새 Helm 차트를 설치합니다:

helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace

새 Helm 차트를 구성하고 W&B 애플리케이션 배포를 트리거합니다. 새 구성을 적용합니다.
```
kubectl apply -f operator.yaml
```
배포가 완료되기까지 몇 분 정도 소요됩니다.
설치를 검증합니다. Verify the installation의 단계를 따라 모든 것이 정상적으로 동작하는지 확인합니다.
이전 설치를 제거합니다. 기존 Helm 차트를 제거하거나 매니페스트로 생성된 리소스를 삭제합니다.

Operator 기반 Terraform Helm 차트로 마이그레이션

다음 단계를 따라 Operator 기반 Helm 차트로 마이그레이션하세요:

Terraform 구성 준비. Terraform 구성에서 이전 배포에 사용하던 Terraform 코드를 여기에 설명된 코드로 교체하세요. 이전과 동일한 변수 값을 설정하세요. .tfvars 파일이 있다면 변경하지 마세요.
Terraform 실행. terraform init, terraform plan, terraform apply를 순서대로 실행하세요.
설치 검증. 설치 검증의 단계를 따라 모든 것이 정상 동작하는지 확인하세요.
이전 설치 제거. 이전 Helm 차트를 제거하거나 매니페스트로 생성된 리소스를 삭제하세요.

W&B Server 구성 참조

이 섹션에서는 W&B Server 애플리케이션의 구성 옵션을 설명합니다. 애플리케이션은 WeightsAndBiases라는 이름의 커스텀 리소스 정의를 통해 구성 값을 전달받습니다. 일부 구성 옵션은 아래 구성에서 제공되며, 일부는 환경 변수로 설정해야 합니다. 문서에는 환경 변수가 기본 및 고급 두 가지 목록으로 정리되어 있습니다. 필요한 구성 옵션이 Helm 차트를 통해 제공되지 않는 경우에만 환경 변수를 사용하십시오.

기본 예시

이 예시는 W&B에 필요한 최소 구성 값 집합을 정의합니다. 보다 현실적인 프로덕션 환경 예시는 완전한 예제를 참고하세요. 이 YAML 파일은 버전, 환경 변수, 데이터베이스와 같은 외부 리소스 및 기타 필요한 설정을 포함하여, W&B 배포의 의도한 상태를 정의합니다.

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://<HOST_URI>
      license: eyJhbGnUzaH...j9ZieKQ2x5GGfw
      bucket:
        <details depend on the provider>
      mysql:
        <redacted>
    ingress:
      annotations:
        <redacted>

사용 가능한 전체 값 목록은 W&B Helm 저장소에서 확인할 수 있습니다. 반드시 재정의해야 하는 값만 변경하세요.

전체 예제

이 예제 구성은 Google Cloud Storage를 사용하여 W&B를 Google Cloud Anthos에 배포합니다.

apiVersion: apps.wandb.com/v1
kind: WeightsAndBiases
metadata:
  labels:
    app.kubernetes.io/name: weightsandbiases
    app.kubernetes.io/instance: wandb
  name: wandb
  namespace: default
spec:
  values:
    global:
      host: https://abc-wandb.sandbox-gcp.wandb.ml
      bucket:
        name: abc-wandb-moving-pipefish
        provider: gcs
      mysql:
        database: wandb_local
        host: 10.218.0.2
        name: wandb_local
        password: 8wtX6cJHizAZvYScjDzZcUarK4zZGjpV
        port: 3306
        user: wandb
      redis:
        host: redis.example.com
        port: 6379
        password: password
      api:
        enabled: true
      glue:
        enabled: true
      executor:
        enabled: true
      license: eyJhbGnUzaHgyQjQyQWhEU3...ZieKQ2x5GGfw
    ingress:
      annotations:
        ingress.gcp.kubernetes.io/pre-shared-cert: abc-wandb-cert-creative-puma
        kubernetes.io/ingress.class: gce
        kubernetes.io/ingress.global-static-ip-name: abc-wandb-operator-address

호스트

 # 프로토콜을 포함한 FQDN을 입력하세요
global:
  # 예시 호스트 이름, 실제 호스트 이름으로 교체하세요
  host: https://wandb.example.com

오브젝트 스토리지(버킷)

AWS

global:
  bucket:
    provider: "s3"
    name: ""
    kmsKey: ""
    region: ""

Google Cloud

global:
  bucket:
    provider: "gcs"
    name: ""

Azure

global:
  bucket:
    provider: "az"
    name: ""
    secretKey: ""

기타 제공자(Minio, Ceph 등) 다른 S3 호환 스토리지 제공자를 사용하는 경우, 버킷 구성을 다음과 같이 설정하세요:

global:
  bucket:
    # 예시 값입니다. 실제 값으로 교체하세요
    provider: s3
    name: storage.example.com
    kmsKey: null
    path: wandb
    region: default
    accessKey: 5WOA500...P5DK7I
    secretKey: HDKYe4Q...JAp1YyjysnX

AWS 외부에 호스팅되는 S3 호환 스토리지의 경우 kmsKey는 null이어야 합니다. 시크릿에서 accessKey와 secretKey를 참조하려면:

global:
  bucket:
    # 예시 값입니다. 실제 값으로 교체하세요
    provider: s3
    name: storage.example.com
    kmsKey: null
    path: wandb
    region: default
    secret:
      secretName: bucket-secret
      accessKeyName: ACCESS_KEY
      secretKeyName: SECRET_KEY

MySQL

global:
   mysql:
     # 예시 값입니다. 실제 값으로 교체하세요
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     password: 8wtX6cJH...ZcUarK4zZGjpV 

시크릿에서 password 값을 참조하려면:

global:
   mysql:
     # 예시 값입니다. 실제 값으로 교체하세요
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     passwordSecret:
       name: database-secret
       passwordKey: MYSQL_WANDB_PASSWORD

라이선스

global:
  # 예시 라이선스입니다. 본인의 라이선스로 교체하세요
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi

Secret에서 license를 참조하려면:

global:
  licenseSecret:
    name: license-secret
    key: CUSTOMER_WANDB_LICENSE

Ingress

Ingress 클래스를 확인하려면 이 FAQ 항목을 참조하세요. TLS 없이

global:
# 중요: Ingress는 YAML에서 'global'과 동일한 레벨에 위치합니다 (하위 항목이 아님)
ingress:
  class: ""

TLS 사용 시 인증서가 포함된 Secret을 생성합니다

kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt

Ingress 구성에서 Secret을 참조하세요

global:
# 중요: Ingress는 YAML에서 'global'과 동일한 레벨에 위치합니다 (하위 항목이 아님)
ingress:
  class: ""
  annotations:
    {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  tls: 
    - secretName: wandb-ingress-tls
      hosts:
        - <HOST_URI>

Nginx를 사용하는 경우 다음 어노테이션을 추가해야 할 수도 있습니다:

ingress:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: 0

사용자 지정 Kubernetes ServiceAccounts

W&B 파드를 실행할 사용자 지정 Kubernetes ServiceAccount를 지정합니다. 다음 스니펫은 배포의 일부로 지정한 이름의 ServiceAccount를 생성합니다:

app:
  serviceAccount:
    name: custom-service-account
    create: true

parquet:
  serviceAccount:
    name: custom-service-account
    create: true

global:
  ...

하위 시스템 “app”과 “parquet”은 지정된 서비스 계정으로 실행됩니다. 나머지 하위 시스템은 기본 서비스 계정으로 실행됩니다. 서비스 계정이 이미 클러스터에 존재하는 경우 create: false로 설정합니다:

app:
  serviceAccount:
    name: custom-service-account
    create: false

parquet:
  serviceAccount:
    name: custom-service-account
    create: false
    
global:
  ...

app, parquet, console 등의 서로 다른 서브시스템별로 서비스 계정을 지정할 수 있습니다:

app:
  serviceAccount:
    name: custom-service-account
    create: true

console:
  serviceAccount:
    name: custom-service-account
    create: true

global:
  ...

서비스 계정은 서브시스템별로 서로 다를 수 있습니다:

app:
  serviceAccount:
    name: custom-service-account
    create: false

console:
  serviceAccount:
    name: another-custom-service-account
    create: true

global:
  ...

외부 Redis

redis:
  install: false

global:
  redis:
    host: ""
    port: 6379
    password: ""
    parameters: {}
    caCert: ""

시크릿에 저장된 password를 참조하려면:

kubectl create secret generic redis-secret --from-literal=redis-password=supersecret

아래 구성에서 이 값을 참조하세요:

redis:
  install: false

global:
  redis:
    host: redis.example
    port: 9001
    auth:
      enabled: true
      secret: redis-secret
      key: redis-password

LDAP

현재 Helm 차트에서는 LDAP 구성 지원이 제한적입니다. LDAP 구성을 위해서는 W&B Support 또는 담당 AISE에 문의하십시오.

global.extraEnv에 환경 변수를 설정하여 LDAP를 구성합니다:

global:
  extraEnv:
    LDAP_ADDRESS: ldaps://ldap.company.example.com
    LDAP_BASE_DN: cn=accounts,dc=company,dc=example,dc=com
    LDAP_USER_BASE_DN: cn=users,cn=accounts,dc=company,dc=example,dc=com
    LDAP_GROUP_BASE_DN: cn=groups,cn=accounts,dc=company,dc=example,dc=com
    LDAP_BIND_DN: uid=ldapbind,cn=sysaccounts,cn=etc,dc=company,dc=example,dc=com
    LDAP_BIND_PW: ********************
    LDAP_ATTRIBUTES: email=mail,name=cn
    LDAP_TLS_ENABLE: "true"
    LDAP_LOGIN: "true"
    LDAP_USER_OBJECT_CLASS: user
    LDAP_GROUP_OBJECT_CLASS: group

OIDC SSO

global: 
  auth:
    sessionLengthHours: 720
    oidc:
      clientId: ""
      secret: ""
      # IdP에서 필요한 경우에만 포함하세요.
      authMethod: ""
      issuer: ""

authMethod는 선택 사항입니다.

SMTP

global:
  email:
    smtp:
      host: ""
      port: 587
      user: ""
      password: ""

환경 변수

global:
  extraEnv:
    GLOBAL_ENV: "example"

사용자 지정 인증 기관

customCACerts는 목록이며 여러 개의 인증서를 포함할 수 있습니다. customCACerts에 지정된 인증 기관은 W&B Server 애플리케이션에만 적용됩니다.

global:
  customCACerts:
  - |
    -----BEGIN CERTIFICATE-----
    MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
    MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
    MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
    SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
    P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
    -----END CERTIFICATE-----
  - |
    -----BEGIN CERTIFICATE-----
    MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
    MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
    MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
    SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
    aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
    -----END CERTIFICATE-----

또한 CA 인증서를 ConfigMap에 저장할 수 있습니다:

global:
  caCertsConfigMap: custom-ca-certs

ConfigMap은 다음과 같은 형태여야 합니다:

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ca-certs
data:
  ca-cert1.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  ca-cert2.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

ConfigMap을 사용하는 경우, ConfigMap의 각 키 이름은 반드시 .crt로 끝나야 합니다(예: my-cert.crt 또는 ca-cert1.crt). 이러한 이름 규칙은 update-ca-certificates가 각 인증서를 인식하여 시스템 CA 저장소에 추가하는 데 필요합니다.

사용자 정의 보안 컨텍스트

각 W&B 컴포넌트는 다음과 같은 형식의 사용자 정의 보안 컨텍스트 구성을 지원합니다:

pod:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1001
    runAsGroup: 0
    fsGroup: 1001
    fsGroupChangePolicy: Always
    seccompProfile:
      type: RuntimeDefault
container:
  securityContext:
    capabilities:
      drop:
        - ALL
    readOnlyRootFilesystem: false
    allowPrivilegeEscalation: false 

runAsGroup:에 사용할 수 있는 유효한 값은 0뿐입니다. 다른 값을 설정하면 오류가 발생합니다.

예를 들어, 애플리케이션 Pod를 구성하려면 설정에 app 섹션을 추가하십시오.

global:
  ...
app:
  pod:
    securityContext:
      runAsNonRoot: true
      runAsUser: 1001
      runAsGroup: 0
      fsGroup: 1001
      fsGroupChangePolicy: Always
      seccompProfile:
        type: RuntimeDefault
  container:
    securityContext:
      capabilities:
        drop:
          - ALL
      readOnlyRootFilesystem: false
      allowPrivilegeEscalation: false 

같은 개념이 console, weave, weave-trace, parquet에도 적용됩니다.

W&B Operator 구성 참조

이 섹션에서는 W&B Kubernetes 오퍼레이터(wandb-controller-manager)에 대한 구성 옵션을 설명합니다. 오퍼레이터는 YAML 파일 형태로 구성을 전달받습니다. 기본적으로 W&B Kubernetes 오퍼레이터는 별도의 구성 파일이 필요하지 않습니다. 필요한 경우에만 구성 파일을 생성하십시오. 예를 들어, 사용자 지정 인증 기관을 지정하거나 에어갭 환경에 배포하는 등의 경우 구성 파일이 필요할 수 있습니다. spec 사용자 정의 항목의 전체 목록은 Helm 저장소에서 확인할 수 있습니다.

사용자 정의 CA

사용자 정의 인증 기관(customCACerts)은 목록 형태이며 여러 개의 인증서를 포함할 수 있습니다. 이렇게 추가된 인증 기관은 W&B Kubernetes operator(wandb-controller-manager)에만 적용됩니다.

customCACerts:
- |
  -----BEGIN CERTIFICATE-----
  MIIBnDCCAUKgAwIBAg.....................fucMwCgYIKoZIzj0EAwIwLDEQ
  MA4GA1UEChMHSG9tZU.....................tZUxhYiBSb290IENBMB4XDTI0
  MDQwMTA4MjgzMFoXDT.....................oNWYggsMo8O+0mWLYMAoGCCqG
  SM49BAMCA0gAMEUCIQ.....................hwuJgyQRaqMI149div72V2QIg
  P5GD+5I+02yEp58Cwxd5Bj2CvyQwTjTO4hiVl1Xd0M0=
  -----END CERTIFICATE-----
- |
  -----BEGIN CERTIFICATE-----
  MIIBxTCCAWugAwIB.......................qaJcwCgYIKoZIzj0EAwIwLDEQ
  MA4GA1UEChMHSG9t.......................tZUxhYiBSb290IENBMB4XDTI0
  MDQwMTA4MjgzMVoX.......................UK+moK4nZYvpNpqfvz/7m5wKU
  SAAwRQIhAIzXZMW4.......................E8UFqsCcILdXjAiA7iTluM0IU
  aIgJYVqKxXt25blH/VyBRzvNhViesfkNUQ==
  -----END CERTIFICATE-----

CA 인증서는 또한 ConfigMap에 저장할 수도 있습니다:

caCertsConfigMap: custom-ca-certs

ConfigMap은 아래와 같아야 합니다:

apiVersion: v1
kind: ConfigMap
metadata:
  name: custom-ca-certs
data:
  ca-cert1.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  ca-cert2.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----

ConfigMap의 각 키 이름은 반드시 .crt로 끝나야 합니다(예: my-cert.crt 또는 ca-cert1.crt). 이 명명 규칙은 update-ca-certificates가 각 인증서를 파싱해 시스템 CA 저장소에 추가하는 데 필요합니다.

FAQ (자주 묻는 질문)

각 pod의 목적/역할은 무엇인가요?

wandb-app: GraphQL API와 프론트엔드 애플리케이션을 포함하는 W&B의 코어입니다. 플랫폼 기능의 대부분을 담당합니다.
wandb-console: /console 경로를 통해 접속할 수 있는 관리 콘솔입니다.
wandb-otel: OpenTelemetry 에이전트로, Kubernetes 계층의 리소스에서 메트릭과 로그를 수집해 관리 콘솔에 표시합니다.
wandb-prometheus: 다양한 구성 요소에서 메트릭을 수집해 관리 콘솔에 표시하는 Prometheus 서버입니다.
wandb-parquet: 데이터베이스 데이터를 Parquet 형식으로 오브젝트 스토리지에 내보내는, wandb-app pod와 분리된 백엔드 마이크로서비스입니다.
wandb-weave: UI에서 쿼리 테이블을 로드하고 여러 핵심 앱 기능을 지원하는 또 다른 백엔드 마이크로서비스입니다.
wandb-weave-trace: LLM 기반 애플리케이션을 추적, 실험, 평가, 배포 및 개선하기 위한 프레임워크입니다. 이 프레임워크는 wandb-app pod를 통해 사용할 수 있습니다.

W&B Operator Console 비밀번호를 확인하는 방법

W&B Kubernetes Operator 관리 콘솔에 접근하기를 참고하세요.

Ingress가 작동하지 않을 때 W&B Operator Console에 액세스하는 방법

Kubernetes 클러스터에 연결할 수 있는 호스트에서 다음 명령을 실행합니다.

kubectl port-forward svc/wandb-console 8082

브라우저에서 https://localhost:8082/로 콘솔에 접속합니다. 비밀번호를 확인하는 방법(옵션 2)은 W&B Kubernetes Operator 관리 콘솔에 액세스하기를 참조하세요.

W&B Server 로그 확인 방법

애플리케이션 파드의 이름은 wandb-app-xxx입니다.

kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

Kubernetes ingress 클래스 식별 방법

클러스터에 설치된 ingress 클래스를 확인하려면 다음을 실행하세요

kubectl get ingressclass

배포 옵션

W&B 구성

모니터링 및 사용량

자료

​W&B Kubernetes Operator

​아키텍처 변경의 이유

​작동 방식

​구성 사양 우선순위 계층

​시작하기 전에

​MySQL 데이터베이스

​Redis

​오브젝트 스토리지

​네트워킹 요구 사항

​SSL/TLS 요구 사항

​에어갭 환경에서의 설치

​OpenShift Kubernetes clusters

​비특권 사용자로 컨테이너 실행

​W&B Server 애플리케이션 배포

​Helm CLI로 W&B 배포

​Helm Terraform Module을 사용하여 W&B 배포

​W&B Cloud Terraform 모듈을 사용해 W&B 배포하기

​설치 확인

​W&B Management Console에 접속하기

​W&B Kubernetes operator 업데이트

​W&B Server 애플리케이션 업데이트

​Self-Managed 인스턴스를 W&B Operator로 마이그레이션

​Operator 기반 AWS Terraform 모듈로 마이그레이션

​Operator 기반 Google Cloud Terraform 모듈로 마이그레이션

​Operator 기반 Azure Terraform 모듈로 마이그레이션

​Operator 기반 Helm 차트로 마이그레이션

​Operator 기반 Terraform Helm 차트로 마이그레이션

​W&B Server 구성 참조

​기본 예시

​전체 예제

​호스트

​오브젝트 스토리지(버킷)

​MySQL

​라이선스

​Ingress

​사용자 지정 Kubernetes ServiceAccounts

​외부 Redis

​LDAP

​OIDC SSO

​SMTP

​환경 변수

​사용자 지정 인증 기관

​사용자 정의 보안 컨텍스트

​W&B Operator 구성 참조

​사용자 정의 CA

​FAQ (자주 묻는 질문)

​각 pod의 목적/역할은 무엇인가요?

​W&B Operator Console 비밀번호를 확인하는 방법

​Ingress가 작동하지 않을 때 W&B Operator Console에 액세스하는 방법

​W&B Server 로그 확인 방법

​Kubernetes ingress 클래스 식별 방법

W&B Kubernetes Operator

아키텍처 변경의 이유

작동 방식

구성 사양 우선순위 계층

시작하기 전에

MySQL 데이터베이스

Redis

오브젝트 스토리지

네트워킹 요구 사항

SSL/TLS 요구 사항

에어갭 환경에서의 설치

OpenShift Kubernetes clusters

비특권 사용자로 컨테이너 실행

W&B Server 애플리케이션 배포

Helm CLI로 W&B 배포

Helm Terraform Module을 사용하여 W&B 배포

W&B Cloud Terraform 모듈을 사용해 W&B 배포하기

설치 확인

W&B Management Console에 접속하기

W&B Kubernetes operator 업데이트

W&B Server 애플리케이션 업데이트

Self-Managed 인스턴스를 W&B Operator로 마이그레이션

Operator 기반 AWS Terraform 모듈로 마이그레이션

Operator 기반 Google Cloud Terraform 모듈로 마이그레이션

Operator 기반 Azure Terraform 모듈로 마이그레이션

Operator 기반 Helm 차트로 마이그레이션

Operator 기반 Terraform Helm 차트로 마이그레이션

W&B Server 구성 참조

기본 예시

전체 예제

호스트

오브젝트 스토리지(버킷)

MySQL

라이선스

Ingress

사용자 지정 Kubernetes ServiceAccounts

외부 Redis

LDAP

OIDC SSO

SMTP

환경 변수

사용자 지정 인증 기관

사용자 정의 보안 컨텍스트

W&B Operator 구성 참조

사용자 정의 CA

FAQ (자주 묻는 질문)

각 pod의 목적/역할은 무엇인가요?

W&B Operator Console 비밀번호를 확인하는 방법

Ingress가 작동하지 않을 때 W&B Operator Console에 액세스하는 방법

W&B Server 로그 확인 방법

Kubernetes ingress 클래스 식별 방법