메인 콘텐츠로 건너뛰기

​
W&B Kubernetes 에이전트 (Operator)

W&B Kubernetes Operator를 사용하여 Kubernetes에서 W&B 서버 배포의 배포, 관리, 문제 해결 및 확장을 단순화하십시오. 에이전트는 W&B 인스턴스를 위한 스마트 어시스턴트라고 생각하면 됩니다. W&B 서버 아키텍처와 디자인은 AI 개발자 툴 기능을 확장하고 고성능, 더 나은 확장성 및 더 쉬운 관리를 위한 적절한 프리미티브를 제공하기 위해 지속적으로 진화하고 있습니다. 이러한 진화는 컴퓨팅 서비스, 관련 스토리지 및 이들 간의 연결성에 적용됩니다. 다양한 배포 유형에 걸쳐 지속적인 업데이트와 개선을 용이하게 하기 위해 W&B는 Kubernetes 에이전트를 사용합니다.
W&B는 AWS, Google Cloud 및 Azure 퍼블릭 클라우드에서 전용 클라우드 (Dedicated Cloud) 인스턴스를 배포하고 관리하기 위해 에이전트를 사용합니다.
Kubernetes 에이전트에 대한 자세한 내용은 Kubernetes 문서의 Operator 패턴을 참조하십시오.

​
아키텍처 전환 이유

과거에 W&B 애플리케이션은 Kubernetes 클러스터 내의 단일 배포 및 pod 또는 단일 Docker 컨테이너로 배포되었습니다. W&B는 데이터베이스와 오브젝트 스토리지를 외부화할 것을 권장해 왔으며 앞으로도 계속 권장할 것입니다. 데이터베이스와 오브젝트 스토리지를 외부화하면 애플리케이션의 상태가 분리됩니다. 애플리케이션이 성장함에 따라 모놀리식 컨테이너에서 분산 시스템(마이크로서비스)으로 진화해야 할 필요성이 분명해졌습니다. 이 변경은 백엔드 로직 처리를 용이하게 하고 내장된 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).

​
작동 방식

Helm 또는 소스에서 에이전트를 설치할 수 있습니다. 자세한 지침은 charts/operator를 참조하십시오. 설치 프로세스는 controller-manager라는 배포를 생성하고, 단일 spec을 받아 클러스터에 적용하는 weightsandbiases.apps.wandb.com(shortName: wandb)이라는 사용자 정의 리소스 정의를 사용합니다. 
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: weightsandbiases.apps.wandb.com
controller-manager는 사용자 정의 리소스의 spec, 릴리스 채널 및 사용자 정의 설정을 기반으로 charts/operator-wandb를 설치합니다. 설정 사양 계층 구조는 사용자 측에서 최대의 설정 유연성을 제공하며 W&B가 새로운 이미지, 설정, 기능 및 Helm 업데이트를 자동으로 릴리스할 수 있도록 합니다. 설정 옵션은 설정 사양 계층 구조 및 W&B 에이전트 설정 레퍼런스를 참조하십시오. 배포는 서비스당 하나씩 여러 개의 pod로 구성됩니다. 각 pod의 이름 앞에는 wandb-가 붙습니다.

​
설정 사양 계층 구조

설정 사양은 상위 수준의 사양이 하위 수준의 사양을 덮어쓰는 계층적 모델을 따릅니다. 작동 방식은 다음과 같습니다:
  • 릴리스 채널 값 (Release Channel Values): 이 기본 레벨 설정은 배포를 위해 W&B에서 설정한 릴리스 채널을 기반으로 기본값과 설정을 지정합니다.
  • 사용자 입력 값 (User Input Values): 사용자는 시스템 콘솔을 통해 릴리스 채널 spec에서 제공하는 기본 설정을 재정의할 수 있습니다.
  • 사용자 정의 리소스 값 (Custom Resource Values): 사용자로부터 오는 최고 수준의 사양입니다. 여기에 지정된 모든 값은 사용자 입력 및 릴리스 채널 사양을 모두 덮어씁니다. 설정 옵션에 대한 자세한 설명은 설정 레퍼런스를 참조하십시오.
이 계층적 모델은 설정이 유연하고 다양한 요구 사항을 충족하도록 사용자 정의될 수 있도록 보장하는 동시에 업그레이드 및 변경에 대해 관리 가능하고 체계적인 접근 방식을 유지합니다.

​
시작하기 전에

  1. 다음을 포함한 전체 인프라 요구 사항은 참조 아키텍처를 참조하십시오:
  • 소프트웨어 버전 요구 사항 (Kubernetes, MySQL, Redis, Helm)
  • 하드웨어 요구 사항 (CPU 아키텍처, 사이징 권장 사항)
  • 네트워킹, SSL/TLS 및 DNS 요구 사항
  1. 유효한 W&B 서버 라이선스 취득.
  2. W&B Self-Managed를 설정하고 구성하는 자세한 지침은 다음 섹션과 베어메탈 설치 가이드를 참조하십시오. 설치 방법에 따라 추가 소프트웨어를 설치하거나 추가 요구 사항을 충족해야 할 수도 있습니다.

​
MySQL 데이터베이스

W&B requires an external MySQL database. For production, W&B strongly recommends using managed database services: Managed database services provide automated backups, monitoring, high availability, patching, and reduce operational overhead. See the reference architecture for complete MySQL requirements, including sizing recommendations and configuration parameters. For database creation SQL, see the bare-metal guide. For questions about your deployment’s database configuration, contact support or your AISE.

​
Redis

W&B depends on a single-node Redis 7.x deployment used by W&B’s components for job queuing and data caching. For convenience during testing and development of proofs of concept, W&B Self-Managed includes a local Redis deployment that is not appropriate for production deployments. For production deployments, W&B can connect to a Redis instance in the following environments: 외부 Redis 인스턴스를 구성하는 방법에 대한 자세한 내용은 외부 Redis 설정 섹션을 참조하십시오.

​
오브젝트 스토리지

W&B requires object storage with pre-signed URL and CORS support. For production deployments, W&B recommends using managed object storage services:
  • Amazon S3: Object storage service offering industry-leading scalability, data availability, security, and performance.
  • Google Cloud Storage: Managed service for storing unstructured data at scale.
  • Azure Blob Storage: Cloud-based object storage solution for storing massive amounts of unstructured data.
  • CoreWeave AI Object Storage: High-performance, S3-compatible object storage service optimized for AI workloads.
For self-hosted object storage options, see the bare-metal guide object storage section for detailed setup instructions including CORS configuration and enterprise alternatives.
MinIO Open Source is in maintenance mode with no active development or pre-compiled binaries. For production deployments, W&B recommends using managed object storage services or enterprise-grade S3-compatible solutions.
See the reference architecture object storage section for complete requirements. Helm 값에서 오브젝트 스토리지를 구성하는 방법에 대한 자세한 내용은 오브젝트 스토리지 버킷 설정 섹션을 참조하십시오.

​
네트워킹 요구 사항

For a networked deployment, egress to these endpoints is required during both installation and runtime:
Additional container registries may be required depending on your deployment configuration:
  • https://gcr.io is needed when deploying Bufstream and etcd for Weave online evaluations.
To learn about air-gapped deployments, refer to Kubernetes operator for air-gapped instances. Access to W&B and to the object storage is required for the training infrastructure and for each system that tracks the needs of experiments. 로드 밸런서 및 인그레스 컨트롤러 옵션과 설정 예시는 참조 아키텍처 로드 밸런서 섹션을 참조하십시오.

​
SSL/TLS 요구 사항

W&B requires a valid signed SSL/TLS certificate for secure communication between clients and the server. SSL/TLS termination must occur on the ingress/load balancer. The W&B Server application does not terminate SSL or TLS connections. Important: W&B does not support self-signed certificates and custom CAs. Using self-signed certificates will cause challenges for users and is not supported. If possible, using a service like Let’s Encrypt is a great way to provide trusted certificates to your load balancer. Services like Caddy and Cloudflare manage SSL for you. If your security policies require SSL communication within your trusted networks, consider using a tool like Istio and side car containers.

​
에어갭(Air-gapped) 설치

에어갭 환경에서 W&B Kubernetes Operator를 설치하는 방법에 대한 튜토리얼은 Kubernetes를 사용하여 에어갭 환경에 W&B 배포를 참조하십시오.

​
OpenShift Kubernetes 클러스터

W&B는 클라우드, 온프레미스 및 에어갭 환경의 OpenShift Kubernetes 클러스터 배포를 지원합니다.
W&B는 공식 W&B Helm 차트를 사용하여 설치할 것을 권장합니다.

​
비관리자(Un-privileged) 사용자로 컨테이너 실행

기본적으로 컨테이너는 $UID 999를 사용합니다. 오케스트레이터가 루트가 아닌 사용자로 컨테이너를 실행해야 하는 경우 $UID >= 100000 및 $GID 0을 지정하십시오.
파일 시스템 권한이 제대로 작동하려면 W&B가 루트 그룹 ($GID=0)으로 시작되어야 합니다.
각 W&B 구성 요소에 대한 보안 컨텍스트를 구성하십시오. 예를 들어 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 서버 애플리케이션 배포

Helm을 사용한 W&B Kubernetes Operator는 모든 W&B Self-Managed 배포(클라우드, 온프레미스 및 에어갭 환경 포함)에 권장되는 설치 방법입니다.
이 섹션에서는 W&B Kubernetes 에이전트를 배포하는 다양한 방법을 설명합니다:
  • Helm CLI: Helm 코맨드를 사용한 직접 배포
  • Helm Terraform 모듈: Infrastructure-as-code 배포
  • W&B 클라우드 Terraform 모듈: AWS, Google Cloud 및 Azure를 위한 전체 인프라 + 애플리케이션 배포
배포별 고려 사항은 다음을 참조하십시오:

​
Helm CLI로 W&B 배포

W&B는 Kubernetes 클러스터에 W&B Kubernetes 에이전트를 배포하기 위한 Helm 차트를 제공합니다. 이 접근 방식을 사용하면 Helm CLI 또는 ArgoCD와 같은 지속적 배포 툴을 사용하여 W&B 서버를 배포할 수 있습니다. 위에서 언급한 요구 사항이 갖춰져 있는지 확인하십시오. Helm CLI로 W&B Kubernetes Operator를 설치하려면 다음 단계를 따르십시오:
  1. W&B Helm 저장소를 추가합니다. W&B Helm 차트는 W&B Helm 저장소에서 사용할 수 있습니다: 
    helm repo add wandb https://charts.wandb.ai
helm repo update
  2. Kubernetes 클러스터에 에이전트를 설치합니다: 
    helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
  3. W&B 서버 설치를 트리거하도록 W&B 에이전트 사용자 정의 리소스를 설정합니다. W&B 배포 설정이 포함된 operator.yaml이라는 파일을 생성합니다. 모든 가용 옵션은 설정 레퍼런스를 참조하십시오. 다음은 최소 설정 예시입니다: 
    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>
  4. 사용자 정의 설정으로 에이전트를 시작하여 W&B 서버 애플리케이션을 설치, 구성 및 관리할 수 있도록 합니다: 
    kubectl apply -f operator.yaml
    배포가 완료될 때까지 기다립니다. 몇 분 정도 소요됩니다.
  5. 웹 UI를 사용하여 설치를 확인하려면 첫 번째 관리자 사용자 계정을 생성한 다음 설치 확인에 설명된 확인 단계를 따르십시오.

​
Helm Terraform 모듈로 W&B 배포

이 방법은 일관성과 반복성을 위해 Terraform의 infrastructure-as-code 접근 방식을 활용하여 특정 요구 사항에 맞춘 맞춤형 배포를 가능하게 합니다. 공식 W&B Helm 기반 Terraform 모듈은 여기에 있습니다. 다음 코드는 시작점으로 사용할 수 있으며 프로덕션 등급 배포에 필요한 모든 설정 옵션을 포함하고 있습니다. 
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"
        }
      }
    }
  }
}
설정 옵션은 설정 레퍼런스에 설명된 것과 동일하지만 구문은 HCL(HashiCorp Configuration Language)을 따라야 합니다. Terraform 모듈은 W&B 사용자 정의 리소스 정의(CRD)를 생성합니다. W&B가 고객을 위해 “전용 클라우드 (Dedicated Cloud)” 설치를 배포하기 위해 Helm Terraform 모듈을 어떻게 사용하는지 보려면 다음 링크를 참조하십시오:

​
W&B 클라우드 Terraform 모듈로 W&B 배포

W&B는 AWS, Google Cloud 및 Azure를 위한 일련의 Terraform 모듈을 제공합니다. 이 모듈들은 Kubernetes 클러스터, 로드 밸런서, MySQL 데이터베이스 등을 포함한 전체 인프라와 W&B 서버 애플리케이션을 배포합니다. W&B Kubernetes Operator는 이미 다음과 같은 버전의 공식 W&B 클라우드 전용 Terraform 모듈에 포함되어 있습니다:
Terraform Registry소스 코드버전
AWShttps://github.com/wandb/terraform-aws-wandbv4.0.0+
Azurehttps://github.com/wandb/terraform-azurerm-wandbv2.0.0+
Google Cloudhttps://github.com/wandb/terraform-google-wandbv2.0.0+
이 인테그레이션은 최소한의 설정으로 인스턴스에서 W&B Kubernetes Operator를 사용할 준비가 되도록 보장하여 클라우드 환경에서 W&B 서버를 배포하고 관리할 수 있는 간소화된 경로를 제공합니다. 이 모듈을 사용하는 방법에 대한 자세한 설명은 문서의 Self-Managed 설치 섹션을 참조하십시오.

​
설치 확인

To verify the installation, W&B recommends using the W&B CLI. The verify command executes several tests that verify all components and configurations.
This step assumes that the first admin user account is created with the browser.
Follow these steps to verify the installation:
  1. Install the W&B CLI:
pip install wandb
  1. Log in to W&B:
wandb login --host=https://YOUR_DNS_DOMAIN
For example: 
wandb login --host=https://wandb.company-name.com
  1. Verify the installation:
wandb verify
A successful installation and fully working W&B deployment shows the following output: 
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...........................✅
Contact W&B Support if you encounter errors.

​
W&B 관리 콘솔 엑세스

W&B Kubernetes 에이전트에는 관리 콘솔이 함께 제공됩니다. 주소는 ${HOST_URI}/console입니다(예: https://wandb.company-name.com/console). 관리 콘솔에 로그인하는 방법은 두 가지가 있습니다:
  1. 브라우저에서 W&B 애플리케이션을 열고 로그인합니다. ${HOST_URI}/ 주소로 W&B 애플리케이션에 로그인합니다(예: https://wandb.company-name.com/).
  2. 콘솔에 엑세스합니다. 오른쪽 상단의 아이콘을 클릭한 다음 System console을 클릭합니다. 관리자 권한이 있는 사용자만 System console 항목을 볼 수 있습니다.
    시스템 콘솔 엑세스

​
W&B Kubernetes 에이전트 업데이트

이 섹션에서는 W&B Kubernetes 에이전트를 업데이트하는 방법을 설명합니다.
  • W&B Kubernetes 에이전트를 업데이트해도 W&B 서버 애플리케이션은 업데이트되지 않습니다.
  • W&B Kubernetes 에이전트를 사용하지 않는 Helm 차트를 사용하는 경우, W&B 에이전트 업데이트 지침을 따르기 전에 여기의 지침을 참조하십시오.
아래의 코드조각을 터미널에 복사하여 붙여넣으십시오.
  1. 먼저 helm repo update를 사용하여 저장소를 업데이트합니다: 
    helm repo update
  2. 다음으로 helm upgrade를 사용하여 Helm 차트를 업데이트합니다: 
    helm upgrade operator wandb/operator -n wandb-cr --reuse-values

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

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

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

다음 섹션에서는 사용자가 직접 관리하던 W&B 서버 설치를 W&B 에이전트가 관리하도록 마이그레이션하는 방법을 설명합니다. 마이그레이션 프로세스는 W&B 서버를 어떻게 설치했느냐에 따라 달라집니다:
W&B 에이전트는 W&B 서버를 위한 기본이자 권장되는 설치 방법입니다. 궁금한 점이 있으면 고객 지원 또는 W&B 팀에 문의하십시오.

​
에이전트 기반 AWS Terraform 모듈로 마이그레이션

마이그레이션 프로세스에 대한 자세한 설명은 여기에서 계속하십시오.

​
에이전트 기반 Google Cloud Terraform 모듈로 마이그레이션

질문이 있거나 도움이 필요한 경우 고객 지원 또는 W&B 팀에 문의하십시오.

​
에이전트 기반 Azure Terraform 모듈로 마이그레이션

질문이 있거나 도움이 필요한 경우 고객 지원 또는 W&B 팀에 문의하십시오.

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

에이전트 기반 Helm 차트로 마이그레이션하려면 다음 단계를 따르십시오:
  1. 현재 W&B 설정을 가져옵니다. 에이전트 기반이 아닌 버전의 Helm 차트로 W&B가 배포된 경우 다음과 같이 값을 내보냅니다: 
    helm get values wandb
    Kubernetes manifest로 W&B가 배포된 경우 다음과 같이 값을 내보냅니다: 
    kubectl get deployment wandb -o yaml
    이제 다음 단계에 필요한 모든 설정 값을 확보했습니다.
  2. operator.yaml이라는 파일을 생성합니다. 설정 레퍼런스에 설명된 형식을 따릅니다. 1단계의 값을 사용합니다.
  3. 현재 배포의 pod 수를 0으로 확장합니다. 이 단계는 현재 배포를 중지합니다. 
    kubectl scale --replicas=0 deployment wandb
  4. Helm 차트 저장소를 업데이트합니다: 
    helm repo update
  5. 새 Helm 차트를 설치합니다: 
    helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
  6. 새 Helm 차트를 구성하고 W&B 애플리케이션 배포를 트리거합니다. 새 설정을 적용합니다. 
    kubectl apply -f operator.yaml
    배포가 완료되는 데 몇 분 정도 걸립니다.
  7. 설치를 확인합니다. 설치 확인의 단계를 따라 모든 것이 작동하는지 확인하십시오.
  8. 이전 설치를 제거합니다. 이전 Helm 차트를 제거하거나 manifest로 생성된 리소스를 삭제합니다.

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

에이전트 기반 Helm 차트로 마이그레이션하려면 다음 단계를 따르십시오:
  1. Terraform 설정을 준비합니다. Terraform 설정에서 이전 배포의 Terraform 코드를 여기에 설명된 코드로 교체합니다. 이전과 동일한 변수를 설정합니다. .tfvars 파일이 있는 경우 변경하지 마십시오.
  2. Terraform을 실행합니다. terraform init, plan 및 apply를 실행합니다.
  3. 설치를 확인합니다. 설치 확인의 단계를 따라 모든 것이 작동하는지 확인하십시오.
  4. 이전 설치를 제거합니다. 이전 Helm 차트를 제거하거나 manifest로 생성된 리소스를 삭제합니다.

​
W&B 서버 설정 레퍼런스

이 섹션에서는 W&B 서버 애플리케이션의 설정 옵션을 설명합니다. 애플리케이션은 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를 사용하여 Google Cloud Anthos에 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://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

​
호스트 (Host)

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

​
오브젝트 스토리지 (bucket)

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이어야 합니다. secret에서 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
secret에서 password를 참조하려면: 
global:
   mysql:
     # 예시 값, 실제 값으로 교체하십시오
     host: db.example.com
     port: 3306
     database: wandb_local
     user: wandb
     passwordSecret:
       name: database-secret
       passwordKey: MYSQL_WANDB_PASSWORD

​
라이선스 (License)

global:
  # 예시 라이선스, 실제 값으로 교체하십시오
  license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi
secret에서 license를 참조하려면: 
global:
  licenseSecret:
    name: license-secret
    key: CUSTOMER_WANDB_LICENSE

​
인그레스 (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
인그레스 설정에서 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 pod를 실행하기 위해 사용자 정의 Kubernetes 서비스 계정을 지정하십시오. 다음 코드조각은 지정된 이름으로 배포의 일부로 서비스 계정을 생성합니다: 
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: ""
secret에서 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 지원팀 또는 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"

​
사용자 정의 인증 기관 (Custom CA)

customCACerts는 리스트 형태이며 여러 개의 인증서를 가질 수 있습니다. customCACerts에 지정된 인증 기관은 W&B 서버 애플리케이션에만 적용됩니다. 
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 에이전트 설정 레퍼런스

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

​
사용자 정의 CA

사용자 정의 인증 기관(customCACerts)은 리스트 형태이며 여러 개의 인증서를 가질 수 있습니다. 이 인증 기관들은 추가될 때 W&B Kubernetes 에이전트(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: 관리 콘솔에 표시하기 위해 Kubernetes 레이어의 리소스에서 메트릭과 로그를 수집하는 OpenTelemetry 에이전트입니다.
  • wandb-prometheus: 관리 콘솔에 표시하기 위해 다양한 구성 요소에서 메트릭을 캡처하는 Prometheus 서버입니다.
  • wandb-parquet: wandb-app pod와 분리된 백엔드 마이크로서비스로, 데이터베이스 데이터를 Parquet 형식으로 오브젝트 스토리지에 내보냅니다.
  • wandb-weave: UI에서 쿼리 테이블을 로드하고 다양한 핵심 앱 기능을 지원하는 또 다른 백엔드 마이크로서비스입니다.
  • wandb-weave-trace: LLM 기반 애플리케이션의 추적, 실험, 평가, 배포 및 개선을 위한 프레임워크입니다. 이 프레임워크는 wandb-app pod를 통해 엑세스됩니다.

​
W&B 에이전트 콘솔 비밀번호를 어떻게 얻나요?

W&B Kubernetes 에이전트 관리 콘솔 엑세스를 참조하십시오.

​
인그레스가 작동하지 않을 때 W&B 에이전트 콘솔에 어떻게 엑세스하나요?

Kubernetes 클러스터에 도달할 수 있는 호스트에서 다음 코맨드를 실행하십시오: 
kubectl port-forward svc/wandb-console 8082
브라우저에서 https://localhost:8082/ console로 콘솔에 엑세스합니다. 비밀번호를 얻는 방법은 W&B Kubernetes 에이전트 관리 콘솔 엑세스를 참조하십시오 (옵션 2).

​
W&B 서버 로그는 어떻게 보나요?

애플리케이션 pod의 이름은 wandb-app-xxx입니다. 
kubectl get pods
kubectl logs wandb-XXXXX-XXXXX

​
Kubernetes 인그레스 클래스를 어떻게 확인하나요?

다음 명령을 실행하여 클러스터에 설치된 인그레스 클래스를 확인할 수 있습니다. 
kubectl get ingressclass