### 前提条件
MCP server を有効にする前に、デプロイメントが次の要件を満たしていることを確認してください。
* **チャート バージョン**: `operator-wandb` `0.42.3` 以降。`mcp-server` サブチャートは `0.42.1` で導入されましたが、次の例で使用する Datadog フィールドと `privacy` フィールドはその後に追加されました。
* **Weave Traces が有効**: MCP server は、トレース用ツールと `WF_TRACE_SERVER_URL` のデフォルト値のために Weave Traces に依存します。`weave-trace.install: true` を設定してください。Weave Traces が有効になっていない場合、Helm のレンダリングは `mcp-server requires weave-trace.install=true` というエラーで失敗します。
* **アクセス可能な ingress**: `global.host` は、すでに名前解決されて W\&B ingress にルーティングされている必要があります。MCP pod は `global.host` から `WANDB_BASE_URL` を読み取り、`
### サブチャートを有効にする
`mcp-server` サブチャートを有効にすると、operator がクラスター内に MCP server をデプロイし、既存の W\&B ingress に `/mcp` ルートを追加します。既存の `WeightsAndBiases` カスタムリソース (CR) の `spec.values` ブロックに、すでに設定している `global`、`ingress`、その他のオーバーライドとあわせて、以下を追加します。Datadog ブロックは任意ですが、クラスター内で Datadog Agent DaemonSet がすでに pod のログとトレースを収集している場合は、追加することを推奨します。
```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 server を確認する
pod が `Running` になるまで待ってから、クラスター内および ingress 経由でヘルスエンドポイントを確認します。
```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 server が正常に稼働したら、Bearer token に W\&B APIキーを指定して `https://
### トラブルシューティング
| 症状 | 原因と対処方法 |
| ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `helm render` が `mcp-server requires weave-trace.install=true` で失敗する | `spec.values` に `weave-trace.install: true` を追加してください。MCP server はトレースツールのために Weave Traces に依存しています。 |
| `wandb-mcp-server` pod が `Pending` のままで、`Insufficient cpu` または `Insufficient memory` が表示される | ノードの容量を増やすか、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 を使用してロードバランサーサービスを提供できます。
ロードバランサー設定の詳しい例については、[リファレンスアーキテクチャのネットワーク セクション](/ja/platform/hosting/self-managed/ref-arch#networking)を参照してください。
#### 永続ストレージ
Kubernetes クラスターで、永続ボリューム用の StorageClass が設定されていることを確認してください。W\&B コンポーネントでは、キャッシュや一時データの保存に永続ストレージが必要になる場合があります。
一般的なオンプレミス向けストレージオプションには、次のものがあります:
* NFS ベースのストレージクラス
* Ceph/Rook ストレージ
* ローカル永続ボリューム
* NetApp や Pure Storage などのエンタープライズ向けストレージソリューション
#### DNS と証明書の管理
オンプレミス環境にデプロイする場合は、次のタスクを完了してください:
* 内部 DNS レコードを設定して、W\&B のホスト名を指すようにします。
* 社内の認証局 (CA) から SSL/TLS 証明書を発行します。
* 自己署名証明書を使用する場合は、operator が CA 証明書を信頼するように設定します。
証明書の設定の詳細については、[SSL/TLS 要件](/ja/platform/hosting/self-managed/requirements#ssl-tls)を参照してください。
#### OpenShift デプロイ
W\&B は、OpenShift Kubernetes clusters へのデプロイを全面的にサポートしています。OpenShift ではセキュリティポリシーがより厳格なため、デプロイ時に追加のセキュリティコンテキスト設定が必要です。
OpenShift 固有の設定の詳細については、[OpenShift Kubernetes clusters](#openshift-kubernetes-clusters) を参照してください。エアギャップ 環境での OpenShift の例については、[エアギャップ Kubernetes へのデプロイ](/ja/platform/hosting/self-managed/on-premises-deployments/kubernetes-airgapped#openshift-configuration) を参照してください。
#### オンプレミスおよび S3 互換向けのオブジェクトストレージ
オブジェクトストレージのバケットをプロビジョニングしたら、W\&B カスタムリソース で設定します ([オブジェクトストレージのプロビジョニング](/ja/platform/hosting/data-security/secure-storage-connector)を参照) 。
**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 Management Console にアクセスする
W\&B Kubernetes operator には管理コンソールが付属しており、デプロイメントのステータスの確認、コンポーネントのメトリクスの表示、operator レベルの Settings の調整を行えます。URL は `${HOST_URI}/console` です。たとえば `https://wandb.company-name.com/console` です。
管理コンソールにログインする方法は 2 つあります。
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 アプリケーションを自動的に更新します。
## セルフマネージド インスタンスから W\&B Operator へ移行する
このセクションでは、W\&B Server を自分で管理する構成から、W\&B Operator による管理へ移行する方法を説明します。移行すると、operator がリコンシリエーションと W\&B Server のアップグレードを自動的に処理するため、アプリケーションの manifest の変更や Helm のアップグレードを調整する必要がなくなります。移行プロセスは、W\&B Server をどのようにインストールしたかによって異なります。
### Operator ベースの AWS Terraform Modules への移行
移行手順の詳細については、[operator-wandb チャートのドキュメント](https://github.com/wandb/helm-charts/tree/main/charts/operator-wandb)を参照してください。
### Operator ベースの Google Cloud Terraform Modules への移行
ご不明な点やサポートが必要な場合は、[Customer Support](mailto:support@wandb.com) または担当のW\&Bチームまでお問い合わせください。
### Operator ベースの Azure Terraform Modules への移行
ご不明な点やサポートが必要な場合は、[Customer Support](mailto:support@wandb.com) または担当の W\&B チームまでお問い合わせください。
### Operator ベースの Helm チャートに移行する
Operator ベースの Helm チャートに移行するには、次の step に従います。
1. 現在の W\&B 設定を取得します。W\&B が Operator ベースではないバージョンの Helm チャートでデプロイされている場合は、次のように values をエクスポートします。
```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. 現在のデプロイを 0 pod にスケールします。この step で現在のデプロイを停止します。
```shell theme={null}
kubectl scale --replicas=0 deployment wandb
```
4. Helm チャートのリポジトリを更新します。
```shell theme={null}
helm repo update
```
5. 新しい Helm チャートをインストールします。
```shell theme={null}
helm upgrade --install operator wandb/operator -n wandb-cr --create-namespace
```
6. 新しい Helm チャートを設定し、W\&B アプリケーションのデプロイをトリガーします。新しい設定を適用します。
```shell theme={null}
kubectl apply -f operator.yaml
```
デプロイの完了には数分かかります。
7. インストールを確認する。[インストールを確認する](#verify-the-installation) の手順に従って、すべてが正しく動作することを確認します。
8. 古いインストールを削除します。古い Helm チャートをアンインストールするか、マニフェストを使用して作成したリソースを削除します。
### Operator ベースの Terraform Helm チャート に移行する
次の手順に従って、Operator ベースの Helm チャート に移行します。
1. Terraform 設定を準備します。Terraform 設定内の古いデプロイの Terraform コードを、[Deploy W\&B with Helm Terraform module](#deploy-wb-with-helm-terraform-module) に記載されているコードに置き換えます。変数は以前と同じものを設定します。`.tfvars` file がある場合は変更しないでください。
2. Terraform run を実行します。`terraform init`、`terraform plan`、`terraform apply` を実行します。
3. インストールを確認します。[Verify the installation](#verify-the-installation) の手順に従って、すべてが正しく動作することを確認します。
4. 古いインストールを削除します。古い Helm チャート をアンインストールするか、マニフェスト で作成したリソースを削除します。
## W\&B Server の設定リファレンス
このセクションは、`WeightsAndBiases` Custom Resource で設定する設定オプションのリファレンスです。`operator.yaml` ファイルを作成または更新する際に、特定のサブシステム (たとえば、MySQL、Redis、ingress、OIDC) の YAML スキーマを確認するために使用してください。
このセクションでは、W\&B Server アプリケーションの設定オプションについて説明します。アプリケーションは、[WeightsAndBiases](#how-it-works) という名前の Custom Resource Definition として設定を受け取ります。一部の設定オプションは以下の設定で公開されていますが、環境変数として設定する必要があるものもあります。
このドキュメントには、環境変数の一覧が 2 つあります。[basic](/ja/platform/hosting/env-vars/) と [advanced](/ja/platform/hosting/iam/advanced_env_vars/) です。必要な設定オプションが Helm チャートで公開されていない場合にのみ、環境変数を使用してください。
### 基本例
この例では、W\&B に必要な最小限の値を定義します。より実際の本番環境に近い例については、[完全な例](#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 repository](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 チャートでの LDAP 設定サポートには制限があります。LDAP の設定については、W\&B サポートまたは担当の AISE にお問い合わせください。
LDAP を設定するには、`global.extraEnv` で環境変数を設定します:
```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 パスワードを含む Secret 名とキー（匿名バインドを使用しない場合）
bindPW:
# メールアドレス用の LDAP 属性とグループ ID 属性名を、カンマ区切りの文字列値として指定します。
attributes:
# LDAP グループ許可リスト
groupAllowList:
# LDAP TLS を有効化
tls: false
```
**TLS あり**
LDAP TLS 証明書の設定では、証明書の内容を含む ConfigMap を事前に作成しておく必要があります。
ConfigMap を作成するには、次の command を使用します。
```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 パスワードを含む Secret 名とキー（匿名バインドを使用しない場合）
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` のみです。それ以外の値はエラーになります。
たとえば、アプリケーション pod を設定するには、設定に `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
```
### ホスト
```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
```
### Ingress
[Kubernetes ingress class を確認する方法](#how-to-identify-the-kubernetes-ingress-class)を参照してください。
**TLS なし**
```yaml theme={null}
global:
# 重要: Ingress は 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
```
Ingress 設定でシークレットを参照する
```yaml theme={null}
global:
# 重要: Ingress は YAML 内で 'global' と同じレベルにあります（子要素ではありません）
ingress:
class: ""
annotations:
{}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
tls:
- secretName: wandb-ingress-tls
hosts:
-
### カスタム Kubernetes サービスアカウント
W\&B Pod の実行に使用するカスタム 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:
...
```
### 外部 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 に設定ファイルは必要ありません。必要な場合にのみ、設定ファイルを作成してください。たとえば、カスタム認証局を指定する場合や、エアギャップ環境にデプロイする場合などに、設定ファイルが必要になることがあります。
spec のカスタマイズ項目の完全な一覧は、[Helm repository](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
### 各 pod の目的と役割
W\&B Server のデプロイメントには、次の pod が含まれます。
* **`wandb-app`**: GraphQL API とフロントエンドアプリケーションを含む、W\&B の中核です。W\&B プラットフォームの機能の大部分を担っています。
* **`wandb-console`**: `/console` からアクセスする管理コンソールです。
* **`wandb-otel`**: OpenTelemetry エージェントです。Kubernetes レイヤーのリソースからメトリクスとログを収集し、管理コンソールに表示します。
* **`wandb-prometheus`**: Prometheus サーバーです。さまざまなコンポーネントからメトリクスを収集し、管理コンソールに表示します。
* **`wandb-parquet`**: `wandb-app` pod とは別のバックエンドマイクロサービスで、データベースのデータを Parquet 形式でオブジェクトストレージにエクスポートします。
* **`wandb-weave`**: もう 1 つのバックエンドマイクロサービスで、UI でクエリテーブルを読み込み、さまざまなコアアプリ機能をサポートします。
* **`wandb-weave-trace`**: LLM ベースのアプリケーションをトラッキングし、実験、評価、デプロイ、改善を行うためのフレームワークです。このフレームワークには `wandb-app` pod 経由でアクセスします。
### W\&B Operator Console のパスワードを取得する方法
[W\&B 管理コンソールへのアクセス](#access-the-wb-management-console)を参照してください。
### Ingress が機能しない場合に 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 のログを表示する方法
アプリケーション Pod の名前は **wandb-app-xxx** です。
```console theme={null}
kubectl get pods
kubectl logs wandb-XXXXX-XXXXX
```
### Kubernetes の ingress クラスを確認する方法
次を実行すると、クラスターにインストールされている ingress クラスを確認できます
```console theme={null}
kubectl get ingressclass
```