---
schema_version: "1"
id: 4952c5559e21666ede76bb7f98c16d02f2ee082a834c0bf2b0dcccac4a81fba7
title: Helm チャートの前提条件
collection: tableau
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/tableau/current/ja-jp/server-linux/server-helm-prerequisites.md
canonical_url: https://help.tableau.com/current/server-linux/ja-jp/server-helm-prerequisites.htm
source_site: help.tableau.com
content_type: documentation
content_hash: 52c269f2c893930c8aef05bcaa92c6e2a378511bbc3636b19695f23e122c5eac
description: "重要: このドキュメントは、Helm と Helm チャートに関する知識があることを前提としており、詳細で規範的な例を提供するものではありません。これは、Tableau Server、Helm、Helm チャートのすべてに精通しているお客様向けに設計されています。"
---
[メイン コンテンツに進む](#main-content)

# Tableau Server Helm チャート - 前提条件

**重要**: このドキュメントは、Helm と Helm チャートに関する知識があることを前提としており、詳細で規範的な例を提供するものではありません。これは、Tableau Server、Helm、Helm チャートのすべてに精通しているお客様向けに設計されています。

このトピックでは、Tableau Server の展開に Helm チャートを使用するために必要な前提条件について説明します。

## Helm チャートのダウンロードと配布

Helm チャートは、コンテナ内の Tableau Server のセットアップ ツール (`tableau-server-container-setup-tool-<version>.tar.gz`) の一部として提供され、[Tableau Server のダウンロード](http://tableau.com/ja-jp/support/releases/server/latest) ページからダウンロードできます。

抽出後、必要な Helm チャート ファイルは `helm/tableau` ディレクトリに格納されます。

## 必要なツール

- Kubernetes クラスターにアクセスするように構成された `kubectl` CLI
- `helm` CLI version 3.x 以降
- Kubernetes クラスター (1.19+) へのアクセス

## クラスター要件

- 16GB の RAM と 4 つの CPU コア (8 コアを推奨) を備えたノードが少なくとも 1 つあること。
- 動的 PersistentVolume のプロビジョニングのために StorageClass が構成されていること。
- LoadBalancer サービスまたは Ingress リソースを作成する機能。

## 必須情報

開始する前に、次のものがそろっていることを確認してください。

- Tableau Server **プロダクト キー**
- **初期アカウントの TSM 管理者 `username` および** `**password**`
- アクセス用の Tableau Server **ホスト名**

## Amazon Elastic Kubernetes Service (EKS) の前提条件

### `efs-bootstrap` StorageClass

デフォルトでは、`efs-bootstrap` は EKS で作成されません。マルチノードで bootstrap を共有する場合は、Helm をインストールする前にこの StorageClass を作成してください。

マルチノード展開の場合、ポッドをスケジュールするには、bootstrap ストレージがプロビジョニング可能になっている必要があります。`efs-bootstrap` StorageClass で EFS ボリュームが動的にプロビジョニングされない場合は、次のいずれかを実行する必要があります。

- 静的ブートストラップ PV を事前に作成し、`tableau-server-bootstrap` にバインドします。
    
    または
- `persistence.bootstrap.createPV: true` を設定し、有効な `valid persistence.bootstrap.pv.csi.volumeHandle` (実際の EFS ID、fs-...) を指定します。

これを行わないと、ポッドはバインドされていない PVC で \[保留中\] 状態のままになります。

1. クラスターに EFS CSI ドライバーがインストールされていることを確認します。
    
    kubectl get csidriver efs.csi.aws.com
    
    `CSIDriver` オブジェクトは、EKS マネージド アドオンがインストールされていなくても存在する場合があります。アドオンを明示的に確認してください。
    
    `ResourceNotFoundException` エラー (アドオンなし) が発生した場合、または後で `driver name efs.csi.aws.com not found in the list of registered CSI drivers` などのマウント エラーでポッドが失敗した場合は、EKS アドオンをインストールし、ステータスが ACTIVE になるまで待ってから、ノード プラグイン ポッドを確認します。
    
    この作業が必要になるのは、マルチノード bootstrap で EFS をバックエンドとするボリューム (ReadWriteMany) が使用されているためです。追加のノードに EFS CSI ノード プラグインがなければ、bootstrap PVC をバインドできても、マウントは失敗し、ポッドは `Init/Pending` 状態のままになります。
    
    EFS がマウントに失敗し、次のエラーが表示される場合:
    
    is not authorized to perform: elasticfilesystem:DescribeMountTargets
    
    または
    
    Failed to resolve "fs-....efs.<region>.amazonaws.com"
    
    次のいずれかの修復方法を使用してください。
    
    - **EKS ノードロールの IAM 修正** (推奨): EFS および EC2 に読み取りアクセス許可を付与して、マウント ターゲットと AZ 検出が機能するようにします。ノード グループからノード インスタンスのロール名を解決します。
        
        aws eks list-nodegroups --cluster-name <cluster-name>  
        aws eks describe-nodegroup \\  
        \--cluster-name <cluster-name> \\  
        \--nodegroup-name <nodegroup-name> \\  
        \--query "nodegroup.nodeRole" \\  
        \--output text
    - `attach-role-policy` で、**IAM \*\*ロール名\*\*** (ARN の最後のセグメント) を使用します。
        
        aws iam attach-role-policy \\  
        \--role-name <your-node-instance-role> \\  
        \--policy-arn arn:aws:iam::aws:policy/AmazonElasticFileSystemClientReadWriteAccess
        
        aws iam attach-role-policy \\  
        \--role-name <your-node-instance-role> \\  
        \--policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
        
        - 一般的に必要となるパーミッション
            
            - elasticfilesystem:DescribeMountTargets, 
                elasticfilesystem:DescribeFileSystems
            - `ec2:DescribeAvailabilityZones` (`DescribeAvailabilityZones` がマウント エラーに表示されるときにしばしば必要になります)
    - **ターゲット IP の明示的なマウント**: 環境で DNS/検出が制限されている場合は、ブートストラップ PV CSI ボリュームの属性に `mounttargetip` を設定します。
        
        - Helm の値 (`createPV: true` パス):
            
            persistence:  
            bootstrap:  
            pv:  
            csi:  
            volumeAttributes:  
            mounttargetip: "10.x.x.x"
        - 手動の PV パス
            
            spec:  
            csi:  
            driver: efs.csi.aws.com  
            volumeHandle: fs-xxxxxxxx  
            volumeAttributes:  
            mounttargetip: 10.x.x.x
2. `efs-bootstrap` StorageClass の作成 (例):
    
    apiVersion: storage.k8s.io/v1  
    kind: StorageClass
    metadata:  
    name: efs-bootstrap  
    provisioner: efs.csi.aws.com  
    reclaimPolicy: Retain  
    volumeBindingMode: Immediate  
    allowVolumeExpansion: true
3. bootstrap プロビジョニング パスを 1 つ選択してください (必須)。

- **動的な EFS プロビジョニング パス**
    
    アクセス ポイント用に構成された EFS CSI 動的 StorageClass (たとえば、`provisioningMode: efs-ap, fileSystemId`、およびプラットフォーム標準に従った permissions/basePath パラメーター) を使用します。
- **静的 PV パス**:
    
    `tableau-bootstrap-pv` と `csi.driver: efs.csi.aws.com` を使用して、手動で `csi.volumeHandle: fs-...` を作成します。
    
    次に、以下を設定します。
    
    - `persistence.bootstrap.createPV: false`
    - `persistence.bootstrap.volumeName: tableau-bootstrap-pv`
- **Helm によって作成された静的 PV パス:**
    
    セット:
    
    - `persistence.bootstrap.createPV: true`
    - `persistence.bootstrap.pv.csi.volumeHandle: fs-...`

## EKS 以外の前提条件

### `ReadWriteMany` StorageClass

EKS でホストされていないクラスター (または EFS を使用していない場合)、マルチノードの bootstrap 共有における重要な要件は、bootstrap ボリュームの `ReadWriteMany (RWX)` アクセス モードをサポートする StorageClass を提供することです。これが必要なのは、Pod のスケジュールが可能になる前に bootstrap ストレージをプロビジョニングできる必要があるためです。

Kubernetes 向けの一般的なセルフホスト型 RWX ストレージ バックエンドは次のとおりです。

- NFS (最も一般的で、テストが最も簡単)
- CephFS
- Longhorn (インストールされている場合)
- GlusterFS
- NetApp/その他のエンタープライズ ストレージ

選択したバックエンドに対応する CSI ドライバーがインストールされていることを確認する必要があります。

カスタム RWX StorageClass を使用するように Tableau Server を構成するには、Helm の値 (例: `values-multinode.yaml`) を更新し、`persistence.bootstrap.storageClass` を StorageClass の名前に設定します。

persistence:
  # ... other persistence settings ...

  # Bootstrap volume (required for multi-node)
  bootstrap:
    enabled: true
    storageClass: "my-rwx-storage" # <--- Replace with your StorageClass name
    accessMode: ReadWriteMany
    size: 1Gi
    createPV: false

## その他のリソース

- [Tableau Server Helm チャート - 概要](https://help.tableau.com/current/server-linux/ja-jp/server-in-container_helm-chart.htm)
- [Tableau Server Helm チャート - 展開](https://help.tableau.com/current/server-linux/ja-jp/server-helm-deploy.htm)
- [Tableau Server Helm チャート - トラブルシューティング](https://help.tableau.com/current/server-linux/ja-jp/server-helm-troubleshooting.htm)
- [Helm ドキュメント](https://helm.sh/docs/)
- [Tableau Server ドキュメント](https://help.tableau.com/current/server-linux/ja-jp/)