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

# Tableau Server Helm チャート - トラブルシューティング

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

## はじめに

このトピックでは、Helm チャートを使用して Kubernetes 上に Tableau Server を展開する際の一般的な問題を診断して解決する方法について説明します。インストールの問題、ランタイムの問題、デバッグ手法について説明します。

## 一般的なトラブルシューティングのステップ

Kubernetes の Tableau Server で問題が発生した場合:

1. ポッドのステータスとイベントの確認
2. コンテナのログの確認
3. リソースの可用性の確認
4. 永続ボリューム要求を確認する
5. Helm リリースのステータスの確認
6. サービスとネットワークの接続の確認

## Pod が起動しない

1. ポッドのステータスの確認
    
    kubectl get pods -l app.kubernetes.io/instance=tableau-server  
    kubectl describe pod <pod-name>
2. ログの確認:
    
    kubectl logs <pod-name>
3. イベントの確認:
    
    kubectl get events --sort-by='.lastTimestamp'

## 永続ボリュームに関する問題

1. PVC ステータスの確認:
    
    kubectl get pvc  
    kubectl describe pvc <pvc-name>
2. ストレージ クラスの確認:
    
    kubectl get storageclass

## ライセンス キーに関する問題

1. ライセンス キーが設定されていることの確認:
    
    kubectl get secret tableau-server-secrets -o 
    jsonpath='{.data.LICENSE\_KEY}' | base64 -d
2. ライセンス キーの更新:
    
    \# Edit values.yaml and upgrade  
    helm upgrade tableau-server ./helm/tableau-server -f ./helm/tableau-server/values.yaml

## ヘルスチェックの失敗

1. ヘルス チェック スクリプトの確認:
    
    kubectl exec <pod-name> -- /docker/alive-check  
    kubectl exec <pod-name> -- /docker/server-ready-check
2. ヘルス チェックのタイミングの調整:
    
    healthChecks:  
    liveness:  
    initialDelaySeconds: 600  # Increase if server takes longer to start

## マルチノードのブートストラップに関する問題

1. ブートストラップ ボリュームの確認:
    
    kubectl get pvc | grep bootstrap
2. bootstrap ファイルの確認:
    
    kubectl exec <primary-pod> -- ls -la /docker/config/bootstrap
3. ReadWriteMany アクセス モードの確認:
    
    persistence:  
    bootstrap:  
    accessMode: ReadWriteMany  # Required for multi-node
4. EFS 静的プロビジョニングの bootstrap PV/PVC バインディングの確認:
    
    kubectl get pv tableau-bootstrap-pv  
    kubectl get pvc -n default tableau-server-bootstrap  
    kubectl describe pv tableau-bootstrap-pv  
    kubectl describe pvc -n default tableau-server-bootstrap
5. PVC がバインドされた後にマウントが失敗した場合は、EFS CSI/IAM のエラーを確認します。
    
    kubectl describe pod -n default tableau-server-primary-0  
    kubectl get events -n default --sort-by='.lastTimestamp'
6. `driver name efs.csi.aws.com not found` エラー:
    
    [Amazon Elastic Kubernetes Service (EKS) の前提条件](https://help.tableau.com/current/server/ja-jp/server-helm-prerequisites.htm#EKS-Prereq-storageclass)の説明に従って、EKS アドオンをインストールして検証します。
7. `DescribeMountTargets` 認証エラーの修正
    
    - 推奨される方法:
        
        aws iam attach-role-policy \\  
        \--role-name <your-node-instance-role> \\  
        \--policy-arn  
        arn:aws:iam::aws:policy/AmazonElasticFileSystemClientReadWriteAccess
        
        次に、影響を受けるポッド (プライマリ ノードおよびすべてのワーカー ノード) を再起動します。ワーカーはラベルによって選択されるため、レプリカ数に関係なく対応できます。
    - 別の方法
        
        bootstrap PV 構成でターゲット IP を強制的にマウントする
        
        `persistence.bootstrap.pv.csi.volumeAttributes.mounttargetip` (または手動 PV `volumeAttributes.mounttargetip`) を設定し、再適用/アップグレードします。

## その他のリソース

- [Tableau Server ドキュメント](https://help.tableau.com/current/server-linux/ja-jp/)
- [Tableau Server ログのリファレンス](https://help.tableau.com/current/server-linux/ja-jp/logs.htm)
- [Kubernetes のトラブルシューティング](https://kubernetes.io/docs/tasks/debug/)
- [Helm のトラブルシューティング](https://helm.sh/docs/faq/troubleshooting/)
- [Helm ドキュメント](https://helm.sh/docs/)