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

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

クラスター要件

• 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 チャート - 概要
• Tableau Server Helm チャート - 展開
• Tableau Server Helm チャート - トラブルシューティング
• Helm ドキュメント
• Tableau Server ドキュメント