### 사전 요구 사항
MCP 서버를 활성화하기 전에 배포가 다음 요구 사항을 충족하는지 확인하세요:
* **Chart version**: `operator-wandb` `0.42.3` 이상. `mcp-server` 서브차트는 `0.42.1`에서 도입되었지만, 다음 예시에서 사용하는 Datadog 및 개인정보 보호 필드는 그 이후에 추가되었습니다.
* **Weave Traces enabled**: MCP 서버는 트레이스 도구와 `WF_TRACE_SERVER_URL` 기본값에 Weave Traces를 사용합니다. `weave-trace.install: true`로 설정하세요. Weave Traces가 활성화되어 있지 않으면 Helm 렌더링이 `mcp-server requires weave-trace.install=true` 오류와 함께 실패합니다.
* **Reachable ingress**: `global.host`는 이미 DNS 해석이 가능해야 하며 W\&B 인그레스로 라우팅되어야 합니다. MCP 파드는 `global.host`에서 `WANDB_BASE_URL`을 읽고, `
### 서브차트 활성화
`mcp-server` 서브차트를 활성화하면 operator가 클러스터 내 MCP 서버를 배포하고, 기존 W\&B 인그레스를 `/mcp` 경로로 확장합니다. 기존 `WeightsAndBiases` 커스텀 리소스(CR)의 `spec.values` 블록에, 기존에 설정한 `global`, `ingress` 및 기타 오버라이드와 함께 다음 내용을 추가하세요. Datadog 블록은 선택 사항이지만, 클러스터에서 Datadog Agent DaemonSet이 이미 파드 로그와 트레이스를 수집하고 있는 경우에는 사용하는 것을 권장합니다.
```yaml theme={null}
spec:
values:
weave-trace:
install: true
mcp-server:
install: true
image:
repository: us-docker.pkg.dev/wandb-production/public/wandb/mcp-server
tag: "0.3.3"
datadog:
enabled: true
mode: "agent"
service: "wandb-mcp-server-
### MCP 서버 확인
파드가 `Running` 상태가 될 때까지 기다린 다음, 클러스터 내부와 인그레스를 통해 상태 확인 Endpoint를 점검하세요:
```bash theme={null}
kubectl get pod -l app.kubernetes.io/component=mcp-server
kubectl port-forward svc/wandb-mcp-server 8080:8080
curl -s http://localhost:8080/mcp/health
curl -s "https://
### 클라이언트 연결
MCP 서버가 정상 상태가 되면 W\&B API 키를 Bearer 토큰으로 사용하도록 MCP 클라이언트에서 `https://
### 문제 해결
| 증상 | 원인 및 해결 방법 |
| --------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `helm render`가 `mcp-server requires weave-trace.install=true` 오류와 함께 실패함 | `spec.values`에 `weave-trace.install: true`를 추가하세요. MCP 서버는 트레이스 도구에 Weave Traces를 사용합니다. |
| `wandb-mcp-server` 파드가 `Insufficient cpu` 또는 `Insufficient memory`와 함께 `Pending` 상태에 머묾 | 노드 용량을 늘리거나 CR에서 `mcp-server.resources.requests` 값을 낮추세요. 기본값은 `500m` CPU와 `1Gi` 메모리입니다. |
| `curl https://
## 환경별 고려 사항
Kubernetes는 온프레미스에서 실행하든 클라우드에서 실행하든 동일합니다. 주요 차이는 이름 지정 방식과 관리형 서비스(예: MySQL과 RDS, 또는 S3와 온프레미스 객체 저장소)에 있습니다. 이 섹션에서는 환경에 따라 달라지는 고려 사항을 다룹니다.
### 온프레미스 및 베어메탈
온프레미스 또는 베어메탈 Kubernetes에 배포할 때는 다음 사항에 유의하세요.
#### 로드 밸런서 설정
온프레미스 Kubernetes 클러스터는 일반적으로 로드 밸런서를 수동으로 설정해야 합니다. 옵션은 다음과 같습니다.
* **외부 로드 밸런서**: F5 또는 HAProxy와 같은 기존 하드웨어 또는 소프트웨어 로드 밸런서를 설정합니다.
* **Nginx Ingress Controller**: NodePort 또는 호스트 네트워킹을 사용해 nginx-ingress-controller를 배포합니다.
* **MetalLB**: 베어메탈 Kubernetes 클러스터에서는 MetalLB가 로드 밸런서 서비스를 제공합니다.
자세한 로드 밸런서 설정 예시는 [레퍼런스 아키텍처의 networking 섹션](/ko/platform/hosting/self-managed/ref-arch#networking)을 참조하세요.
#### 영구 저장소
Kubernetes 클러스터에 영구 볼륨용 StorageClass가 구성되어 있는지 확인하세요. W\&B 컴포넌트는 캐싱 및 임시 데이터 저장을 위해 영구 저장소가 필요할 수 있습니다.
일반적인 온프레미스 저장소 옵션에는 다음이 포함됩니다:
* NFS 기반 저장소 클래스
* Ceph/Rook 저장소
* 로컬 영구 볼륨
* NetApp 또는 Pure Storage와 같은 엔터프라이즈 저장소 솔루션
#### DNS 및 인증서 관리
온프레미스 배포의 경우, 다음 작업을 완료하세요:
* W\&B 호스트명을 가리키도록 내부 DNS 레코드를 설정합니다.
* 내부 Certificate Authority(CA)에서 SSL/TLS 인증서를 발급받습니다.
* 자체 서명 인증서를 사용하는 경우 Operator가 CA 인증서를 신뢰하도록 설정합니다.
인증서 설정에 대한 자세한 내용은 [SSL/TLS 요구 사항](/ko/platform/hosting/self-managed/requirements#ssl-tls)을 참조하세요.
#### OpenShift 배포
W\&B는 OpenShift Kubernetes 클러스터에 배포하는 것을 완벽하게 지원합니다. OpenShift 배포에는 OpenShift의 더 엄격한 보안 정책으로 인해 추가적인 보안 컨텍스트 설정이 필요합니다.
OpenShift 관련 설정 세부 정보는 [OpenShift Kubernetes 클러스터](#openshift-kubernetes-clusters)를 참조하세요. 에어갭 환경에서의 OpenShift 예시는 [Air-Gapped Kubernetes에 배포](/ko/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped#openshift-configuration)를 참조하세요.
#### 온프레미스 및 S3 호환 환경용 객체 저장소
객체 저장소 버킷을 프로비저닝한 후([객체 저장소 프로비저닝](/ko/platform/hosting/data-security/secure-storage-connector) 참조), W\&B Custom Resource에 이를 구성하세요.
**AWS S3 (온프레미스)**
온프레미스 AWS S3(Outposts 또는 호환 스토리지 사용)의 경우:
```yaml theme={null}
bucket:
kmsKey:
### Terraform을 사용한 퍼블릭 클라우드
AWS, Google Cloud 또는 Azure에서 인프라와 애플리케이션을 전체 배포하려면 [퍼블릭 클라우드에서 Terraform으로 배포](#deploy-with-terraform-on-public-cloud)를 참조하세요.
## Terraform으로 퍼블릭 클라우드에 배포하기
### 기타 배포 옵션
모든 설정을 동일한 파일에 추가하면 여러 배포 옵션을 조합할 수 있습니다. 각 Terraform 모듈은 표준 옵션 및 권장 배포 섹션에 나와 있는 최소 설정과 함께 조합할 수 있는 여러 옵션을 제공합니다.
사용 가능한 옵션의 전체 목록은 사용 중인 클라우드 제공업체의 모듈 문서를 참고하세요:
* [AWS 모듈 문서](https://registry.terraform.io/modules/wandb/wandb/aws/latest)
* [Google Cloud 모듈 문서](https://registry.terraform.io/modules/wandb/wandb/google/latest)
* [Azure 모듈 문서](https://registry.terraform.io/modules/wandb/wandb/azurerm/latest)
## W\&B 관리 콘솔에 액세스
W\&B Kubernetes Operator에는 배포 상태를 검토하고, 구성 요소 메트릭을 확인하고, operator 수준 설정을 조정할 수 있는 관리 콘솔이 함께 제공됩니다. 관리 콘솔은 `${HOST_URI}/console`에 있으며, 예를 들어 `https://wandb.company-name.com/console`입니다.
관리 콘솔에 로그인하는 방법은 두 가지입니다.
2. 설치 시 생성된 Kubernetes secret에서 비밀번호를 조회합니다.
```shell theme={null}
kubectl get secret wandb-password -o jsonpath='{.data.password}' | base64 -d
```
비밀번호를 복사합니다.
3. 콘솔에 로그인합니다. 복사한 비밀번호를 붙여넣은 다음 **Login**을 클릭합니다.
## W\&B Kubernetes Operator 업데이트
이 섹션에서는 W\&B Kubernetes Operator 자체를 업데이트하는 방법을 설명합니다. 버그 수정과 새로운 리컨실리에이션 기능을 적용하려면 Operator를 주기적으로 업데이트하세요.
## W\&B Server 애플리케이션 업데이트
W\&B Kubernetes Operator를 사용하는 경우에는 더 이상 W\&B Server 애플리케이션을 직접 업데이트할 필요가 없습니다.
W\&B의 새 소프트웨어 버전이 릴리스되면 Operator가 W\&B Server 애플리케이션을 자동으로 업데이트합니다.
## Self-Managed 인스턴스를 W\&B Operator로 마이그레이션하기
다음 섹션에서는 직접 관리하는 W\&B Server 설치를 W\&B Operator를 사용해 관리하는 방식으로 마이그레이션하는 방법을 설명합니다. 마이그레이션하면 operator가 reconciliation과 W\&B Server 업그레이드를 자동으로 처리하므로 더 이상 애플리케이션의 매니페스트 변경이나 Helm 업그레이드를 직접 조율할 필요가 없습니다. 마이그레이션 절차는 W\&B Server를 설치한 방식에 따라 달라집니다:
### Operator 기반 AWS Terraform 모듈로 이전
이전 절차에 대한 자세한 설명은 [operator-wandb 차트 문서](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb)를 참조하세요.
### Operator 기반 Google Cloud Terraform 모듈로 마이그레이션
질문이 있거나 도움이 필요하면 [Customer Support](mailto:support@wandb.com) 또는 담당 W\&B 팀에 문의하세요.
### Operator 기반 Azure Terraform 모듈로 마이그레이션
질문이 있거나 도움이 필요하면 [Customer Support](mailto:support@wandb.com) 또는 담당 W\&B 팀에 문의하세요.
### Operator 기반 Helm chart로 마이그레이션
다음 step에 따라 Operator 기반 Helm chart로 마이그레이션하세요:
1. 현재 W\&B 설정을 조회합니다. W\&B를 Operator 기반이 아닌 버전의 Helm chart로 배포한 경우, 다음과 같이 값을 내보냅니다:
```shell theme={null}
helm get values wandb
```
W\&B를 Kubernetes 매니페스트로 배포한 경우, 다음과 같이 값을 내보냅니다:
```shell theme={null}
kubectl get deployment wandb -o yaml
```
이제 다음 step에 필요한 모든 설정 값을 확보했습니다.
2. `operator.yaml`이라는 파일을 생성합니다. [설정 레퍼런스](#configuration-reference-for-wb-operator)에 설명된 형식을 따르세요. step 1의 값을 사용합니다.
3. 현재 deployment를 파드 0개로 스케일합니다. 이렇게 하면 현재 deployment가 중지됩니다.
```shell theme={null}
kubectl scale --replicas=0 deployment wandb
```
4. Helm chart 리포지토리를 업데이트합니다:
```shell theme={null}
helm repo update
```
5. 새 Helm chart를 설치합니다:
```shell theme={null}
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
```
6. 새 Helm chart를 설정하고 W\&B 애플리케이션 배포를 트리거합니다. 새 설정을 적용합니다.
```shell theme={null}
kubectl apply -f operator.yaml
```
배포가 완료되기까지 몇 분 정도 걸립니다.
7. 설치를 확인합니다. [설치 확인](#verify-the-installation)의 step에 따라 모든 것이 제대로 작동하는지 확인하세요.
8. 이전 설치를 제거합니다. 이전 Helm chart를 제거하거나 매니페스트로 생성한 리소스를 삭제합니다.
### Operator 기반 Terraform Helm chart로 마이그레이션
다음 단계에 따라 Operator 기반 Helm chart로 마이그레이션하세요:
1. Terraform 설정을 준비합니다. Terraform 설정에서 기존 배포에 사용하던 Terraform 코드를 [Helm Terraform 모듈로 W\&B 배포](#deploy-wb-with-helm-terraform-module)에 설명된 코드로 바꾸세요. 변수는 이전과 동일하게 설정하세요. `.tfvars` 파일이 있다면 변경하지 마세요.
2. Terraform을 실행합니다. `terraform init`, `terraform plan`, `terraform apply`를 실행하세요.
3. 설치를 확인합니다. [설치 확인](#verify-the-installation)의 단계를 따라 모든 것이 정상적으로 작동하는지 확인하세요.
4. 기존 설치를 제거합니다. 기존 Helm chart를 제거하거나 매니페스트로 생성한 리소스를 삭제하세요.
## W\&B Server 설정 레퍼런스
이 섹션은 `WeightsAndBiases` 커스텀 리소스에서 설정하는 구성 옵션의 레퍼런스입니다. `operator.yaml` 파일을 작성하거나 업데이트할 때 특정 하위 시스템(예: MySQL, Redis, 인그레스 또는 OIDC)의 YAML 스키마를 찾아보는 데 사용하세요.
이 섹션에서는 W\&B Server 애플리케이션의 설정 옵션을 설명합니다. 이 애플리케이션은 [WeightsAndBiases](#how-it-works)라는 이름의 커스텀 리소스 정의로 설정을 전달받습니다. 일부 설정 옵션은 아래 설정에서 제공되며, 일부는 환경 변수로 설정해야 합니다.
문서에는 환경 변수 목록이 두 가지 있습니다: [basic](/ko/platform/hosting/env-vars/) 및 [advanced](/ko/platform/hosting/iam/advanced_env_vars/). 필요한 설정 옵션이 Helm chart를 통해 제공되지 않는 경우에만 환경 변수를 사용하세요.
### 기본 예제
이 예제는 W\&B에 필요한 최소한의 값 집합을 정의합니다. 더 현실적인 프로덕션 예제는 [Complete example](#complete-example)을 참조하세요.
이 YAML 파일은 버전, 환경 변수, 데이터베이스와 같은 외부 리소스, 기타 필요한 설정을 포함한 W\&B 배포의 목표 상태를 정의합니다.
```yaml theme={null}
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://
mysql:
ingress:
annotations:
```
[W\&B Helm 저장소](https://github.com/wandb/helm-charts/blob/main/charts/operator-wandb/values.yaml)에서 전체 설정값을 확인하세요. **재정의가 필요한 값만 변경하세요**.
```
Nginx의 경우 다음 어노테이션을 추가해야 할 수 있습니다.
```yaml theme={null}
ingress:
annotations:
nginx.ingress.kubernetes.io/proxy-body-size: 0
```
현재 Helm chart에서는 LDAP 설정 지원이 제한적입니다. LDAP 설정에 도움이 필요하면 W\&B 지원팀 또는 AISE에 문의하세요.
`global.extraEnv`에서 환경 변수를 설정해 LDAP를 구성하세요:
```yaml theme={null}
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
```
이 레거시 방식은 더 이상 권장되지 않습니다. 이 섹션은 레퍼런스용으로 제공됩니다.
**TLS 없음**
```yaml theme={null}
global:
ldap:
enabled: true
# "ldap://" 또는 "ldaps://"를 포함한 LDAP 서버 주소
host:
# 사용자를 찾는 데 사용할 LDAP 검색 기준
baseDN:
# 바인드에 사용할 LDAP 사용자(익명 바인드를 사용하지 않는 경우)
bindDN:
# 바인드에 사용할 LDAP 비밀번호가 포함된 시크릿 이름 및 키(익명 바인드를 사용하지 않는 경우)
bindPW:
# 이메일용 LDAP 속성과 그룹 ID 속성 이름을 쉼표로 구분한 문자열 값
attributes:
# LDAP 그룹 허용 목록
groupAllowList:
# LDAP TLS 활성화
tls: false
```
**TLS 사용**
LDAP TLS 인증서 설정을 사용하려면 인증서 내용이 포함된 ConfigMap을 미리 생성해야 합니다.
ConfigMap을 생성하려면 다음 명령어를 사용할 수 있습니다.
```console theme={null}
kubectl create configmap ldap-tls-cert --from-file=certificate.crt
```
그리고 다음 예시와 같이 YAML에서 ConfigMap을 사용합니다.
```yaml theme={null}
global:
ldap:
enabled: true
# "ldap://" 또는 "ldaps://"를 포함한 LDAP 서버 주소
host:
# 사용자를 찾는 데 사용할 LDAP 검색 기준
baseDN:
# 바인드에 사용할 LDAP 사용자(익명 바인드를 사용하지 않는 경우)
bindDN:
# 바인드에 사용할 LDAP 비밀번호가 포함된 시크릿 이름 및 키(익명 바인드를 사용하지 않는 경우)
bindPW:
# 이메일용 LDAP 속성과 그룹 ID 속성 이름을 쉼표로 구분한 문자열 값
attributes:
# LDAP 그룹 허용 목록
groupAllowList:
# LDAP TLS 활성화
tls: true
# LDAP 서버용 CA 인증서가 포함된 ConfigMap 이름 및 키
tlsCert:
configMap:
name: "ldap-tls-cert"
key: "certificate.crt"
```
ConfigMap을 사용하는 경우 ConfigMap의 각 키는 `.crt`로 끝나야 합니다(예: `my-cert.crt` 또는 `ca-cert1.crt`). `update-ca-certificates`가 각 인증서를 파싱해 시스템 CA 저장소에 추가하려면 이 명명 규칙을 따라야 합니다.
`runAsGroup:`에 유효한 값은 `0`뿐입니다. 그 외의 값은 모두 오류입니다.
예를 들어 애플리케이션 파드를 설정하려면 설정에 `app` 섹션을 추가하세요:
```yaml theme={null}
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`에도 적용됩니다.
ConfigMap의 각 키는 반드시 `.crt`로 끝나야 합니다(예: `my-cert.crt` 또는 `ca-cert1.crt`). `update-ca-certificates`가 각 인증서를 인식해 시스템 CA 저장소에 추가하려면 이 명명 규칙을 따라야 합니다.
### 전체 예제
이 예제 설정은 Google Cloud Storage를 사용해 W\&B를 Google Cloud Anthos에 배포합니다:
```yaml theme={null}
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
```yaml theme={null}
# 프로토콜과 함께 FQDN을 제공하세요
global:
# 예시 호스트 이름입니다. 실제 호스트 이름으로 교체하세요
host: https://wandb.example.com
```
### 객체 저장소 (버킷)
**AWS**
```yaml theme={null}
global:
bucket:
provider: "s3"
name: ""
kmsKey: ""
region: ""
```
**Google Cloud**
```yaml theme={null}
global:
bucket:
provider: "gcs"
name: ""
```
**Azure**
```yaml theme={null}
global:
bucket:
provider: "az"
name: ""
secretKey: ""
```
**기타 제공업체(Minio, Ceph 및 기타 S3 호환 저장소)**
다른 S3 호환 제공업체의 경우 버킷 설정을 다음과 같이 지정합니다:
```yaml theme={null}
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`를 참조하려면:
```yaml theme={null}
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
```yaml theme={null}
global:
mysql:
# 예시 값입니다. 실제 값으로 교체하세요.
host: db.example.com
port: 3306
database: wandb_local
user: wandb
password: 8wtX6cJH...ZcUarK4zZGjpV
```
시크릿의 `password`를 참조하려면:
```yaml theme={null}
global:
mysql:
# 예시 값입니다. 실제 값으로 교체하세요.
host: db.example.com
port: 3306
database: wandb_local
user: wandb
passwordSecret:
name: database-secret
passwordKey: MYSQL_WANDB_PASSWORD
```
### 라이선스
```yaml theme={null}
global:
# 예시 라이선스입니다. 본인의 라이선스로 교체하세요.
license: eyJhbGnUzaHgyQjQy...VFnPS_KETXg1hi
```
시크릿의 `license`를 참조하려면:
```yaml theme={null}
global:
licenseSecret:
name: license-secret
key: CUSTOMER_WANDB_LICENSE
```
### 인그레스
[Kubernetes 인그레스 클래스를 파악하는 방법](#how-to-identify-the-kubernetes-ingress-class)을 참조하세요.
**TLS 없이**
```yaml theme={null}
global:
# 중요: 인그레스는 YAML에서 'global'과 동일한 수준에 있습니다 (하위 항목이 아님)
ingress:
class: ""
```
**TLS 사용 시**
인증서가 포함된 시크릿을 생성합니다
```console theme={null}
kubectl create secret tls wandb-ingress-tls --key wandb-ingress-tls.key --cert wandb-ingress-tls.crt
```
인그레스 설정에서 시크릿 참조하기
```yaml theme={null}
global:
# 중요: 인그레스는 YAML에서 'global'과 동일한 수준에 있습니다 (하위 항목이 아님)
ingress:
class: ""
annotations:
{}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
tls:
- secretName: wandb-ingress-tls
hosts:
-
### 맞춤형 Kubernetes 서비스 계정
W\&B 파드를 실행할 맞춤형 Kubernetes 서비스 계정을 지정합니다.
다음 스니펫은 배포 시 지정한 이름으로 서비스 계정을 생성합니다.
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: true
parquet:
serviceAccount:
name: custom-service-account
create: true
global:
...
```
서브시스템 "app" 및 "parquet"는 지정된 서비스 계정으로 실행됩니다. 다른 서브시스템은 기본 서비스 계정으로 실행됩니다.
서비스 계정이 클러스터에 이미 존재하는 경우 `create: false`로 설정합니다:
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: false
parquet:
serviceAccount:
name: custom-service-account
create: false
global:
...
```
app, parquet, console 등 여러 서브시스템에 서비스 계정을 지정할 수 있습니다:
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: true
console:
serviceAccount:
name: custom-service-account
create: true
global:
...
```
각 서브시스템의 서비스 계정은 서로 다를 수 있습니다:
```yaml theme={null}
app:
serviceAccount:
name: custom-service-account
create: false
console:
serviceAccount:
name: another-custom-service-account
create: true
global:
...
```
### External Redis
```yaml theme={null}
redis:
install: false
global:
redis:
host: ""
port: 6379
password: ""
parameters: {}
caCert: ""
```
시크릿의 `password`를 참조하려면:
```console theme={null}
kubectl create secret generic redis-secret --from-literal=redis-password=supersecret
```
다음 설정에서 이를 참조하세요:
```yaml theme={null}
redis:
install: false
global:
redis:
host: redis.example
port: 9001
auth:
enabled: true
secret: redis-secret
key: redis-password
```
### LDAP
### OIDC SSO
```yaml theme={null}
global:
auth:
sessionLengthHours: 720
oidc:
clientId: ""
secret: ""
# IdP에서 필요한 경우에만 포함하세요.
authMethod: ""
issuer: ""
```
`authMethod`는 선택 사항입니다.
### SMTP
```yaml theme={null}
global:
email:
smtp:
host: ""
port: 587
user: ""
password: ""
```
### 환경 변수
```yaml theme={null}
global:
extraEnv:
GLOBAL_ENV: "example"
```
`customCACerts`는 목록이므로 여러 인증서를 지정할 수 있습니다. `customCACerts`에 지정한 인증 기관은 W\&B Server 애플리케이션에만 적용됩니다.
```yaml theme={null}
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 certificates는 ConfigMap에 저장할 수도 있습니다:
```yaml theme={null}
global:
caCertsConfigMap: custom-ca-certs
```
ConfigMap은 다음과 같은 형식이어야 합니다:
```yaml theme={null}
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-ca-certs
data:
ca-cert1.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ca-cert2.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
### 맞춤형 보안 컨텍스트
각 W\&B 구성 요소는 다음 형식의 맞춤형 보안 컨텍스트 설정을 지원합니다:
```yaml theme={null}
pod:
securityContext:
runAsNonRoot: true
runAsUser: 1001
runAsGroup: 0
fsGroup: 1001
fsGroupChangePolicy: Always
seccompProfile:
type: RuntimeDefault
container:
securityContext:
capabilities:
drop:
- ALL
readOnlyRootFilesystem: false
allowPrivilegeEscalation: false
```
## W\&B Operator용 설정 레퍼런스
이 섹션에서는 W\&B Kubernetes Operator(`wandb-controller-manager`)의 설정 옵션을 설명합니다. Operator는 YAML 파일 형식으로 설정을 전달받습니다.
기본적으로 W\&B Kubernetes Operator에는 설정 파일이 필요하지 않습니다. 필요한 경우에만 설정 파일을 만드세요. 예를 들어, 사용자 지정 인증 기관(CA)을 지정하거나 에어갭 환경에 배포해야 하는 경우 설정 파일이 필요할 수 있습니다.
spec 사용자 지정의 전체 목록은 [Helm 저장소](https://github.com/wandb/helm-charts/blob/main/charts/operator/values.yaml)에서 확인하세요.
### 맞춤형 CA
맞춤형 인증 기관(`customCACerts`)은 여러 인증서를 포함할 수 있는 목록입니다. 이렇게 추가한 인증 기관은 W\&B Kubernetes Operator(`wandb-controller-manager`)에만 적용됩니다.
```yaml theme={null}
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 certificates를 ConfigMap에도 저장할 수 있습니다:
```yaml theme={null}
caCertsConfigMap: custom-ca-certs
```
ConfigMap은 다음과 같아야 합니다:
```yaml theme={null}
apiVersion: v1
kind: ConfigMap
metadata:
name: custom-ca-certs
data:
ca-cert1.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
ca-cert2.crt: |
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
## FAQ
### 각 파드의 목적과 역할
W\&B Server 배포에는 다음 파드가 포함됩니다.
* **`wandb-app`**: GraphQL API와 프런트엔드 애플리케이션을 포함한 W\&B의 핵심입니다. W\&B 플랫폼의 대부분의 기능을 담당합니다.
* **`wandb-console`**: `/console`을 통해 접속하는 관리 콘솔입니다.
* **`wandb-otel`**: Kubernetes 계층의 리소스에서 메트릭과 로그를 수집해 관리 콘솔에 표시하는 OpenTelemetry 에이전트입니다.
* **`wandb-prometheus`**: 다양한 컴포넌트에서 메트릭을 수집해 관리 콘솔에 표시하는 Prometheus 서버입니다.
* **`wandb-parquet`**: 데이터베이스 데이터를 Parquet 형식으로 객체 저장소에 내보내는, `wandb-app` 파드와 분리된 백엔드 마이크로서비스입니다.
* **`wandb-weave`**: UI에서 쿼리 테이블을 로드하고 앱의 다양한 핵심 기능을 지원하는 또 다른 백엔드 마이크로서비스입니다.
* **`wandb-weave-trace`**: LLM 기반 애플리케이션을 추적, 실험, 평가, 배포 및 개선하기 위한 프레임워크입니다. 이 프레임워크는 `wandb-app` 파드를 통해 액세스합니다.
### W\&B Operator Console 비밀번호를 조회하는 방법
[W\&B 관리 콘솔에 접속하기](#access-the-wb-management-console)를 참조하세요.
### 인그레스가 작동하지 않을 때 W\&B Operator Console에 접속하는 방법
Kubernetes 클러스터에 접속할 수 있는 호스트에서 다음 명령어를 실행합니다:
```console theme={null}
kubectl port-forward svc/wandb-console 8082
```
브라우저에서 `https://localhost:8082/` 콘솔에 접속합니다.
비밀번호를 확인하는 방법(옵션 2)은 [W\&B 관리 콘솔에 액세스하기](#access-the-wb-management-console)를 참조하세요.
### W\&B Server 로그를 확인하는 방법
애플리케이션 파드 이름은 **wandb-app-xxx**입니다.
```console theme={null}
kubectl get pods
kubectl logs wandb-XXXXX-XXXXX
```
### Kubernetes 인그레스 클래스를 파악하는 방법
다음을 실행하면 클러스터에 설치된 인그레스 클래스를 확인할 수 있습니다.
```console theme={null}
kubectl get ingressclass
```