중요: 이 설명서에서는 Helm 및 Helm 차트에 대한 지식이 있다고 가정하며 상세한 설명적 예를 제공하지 않습니다. 설명서는 Tableau Server와 Helm 및 Helm 차트에 익숙한 고객을 대상으로 작성되었습니다.

이 항목에서는 Helm 차트를 사용하여 Tableau Server 배포하는 데 필요한 필수 요건에 대해 설명합니다.

클러스터 요구 사항

• 16GB RAM 및 4개의 CPU 코어가 있는 하나 이상의 노드(8개 코어 권장)
• 동적 PersistentVolume 프로비저닝을 위해 구성된 StorageClass
• LoadBalancer 서비스 또는 Ingress 리소스를 만들 수 있는 기능

필요한 정보

시작하기 전에 다음을 준비하십시오.

• Tableau Server의 라이선스 키
• 초기 계정을 위한 TSM 관리자의 username 및 password
• 액세스를 위한 Tableau Server 호스트 이름

Amazon EKS(Elastic Kubernetes Service) 필수 요건

efs-bootstrap StorageClass

기본적으로 efs-bootstrap은 EKS에서 만들지 않습니다. 다중 노드 부트스트랩 공유의 경우 Helm 설치 전에 만들어야 합니다.

다중 노드 배포의 경우 포드 일정을 예약하려면 먼저 부트스트랩 저장소를 프로비저닝해야 합니다. 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

   EKS에서 관리하는 부가기능이 설치되어 있지 않은 경우에도 CSIDriver 개체가 존재할 수 있습니다. 부가기능이 있는지 명시적으로 확인합니다.

   ResourceNotFoundException 오류(부가기능 없음)가 발생하거나, 이후 포드가 driver name efs.csi.aws.com not found in the list of registered CSI drivers 등의 마운트 오류로 실패하는 경우, EKS 부가기능을 설치하고 상태가 ACTIVE가 될 때까지 기다린 후 노드 플러그인 포드를 확인하십시오.

   다중 노드 부트스트랩은 EFS 지원 볼륨(ReadWriteMany)을 사용하기 때문에 이 작업이 필요합니다. 추가 노드에 EFS CSI 노드 플러그인이 없으면 부트스트랩 PVC는 바인딩될 수 있지만 마운트가 실패하고 포드가 Init/Pending 상태로 유지됩니다.

   다음 오류와 함께 EFS 마운트가 실패합니다.

   is not authorized to perform: elasticfilesystem:DescribeMountTargets

   또는

   Failed to resolve "fs-....efs.<region>.amazonaws.com"

   다음 수정 단계 중 하나를 사용하십시오.

   • EKS 노드 역할에 대한 IAM 수정(기본 설정): 마운트 대상 및 AZ 검색이 작동하도록 EFS 및 EC2에 읽기 권한을 부여합니다. 노드 그룹에서 노드 인스턴스 역할 이름을 확인합니다.

     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을 설정합니다.

     • 키 값(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. 부트스트랩 프로비저닝 경로 하나를 선택합니다(필수).

• 동적 EFS 프로비저닝 경로:

  액세스 지점으로 구성된 EFS CSI의 동적 StorageClass를 사용합니다(예: provisioningMode: efs-ap, fileSystemId, 사용 중인 플랫폼 표준에 따라 permissions/basePath 매개 변수 사용).

• 정적 PV 경로:

  csi.driver: efs.csi.aws.com 및 csi.volumeHandle: fs-...를 사용하여 수동으로 tableau-bootstrap-pv를 만듭니다.

  그리고 다음을 설정합니다.

  • 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를 사용하지 않는 경우) 다중 노드 부트스트랩 공유에 대한 중요한 요구 사항은 부트스트랩 볼륨에 대해 ReadWriteMany (RWX) 액세스 모드를 지원하는 StorageClass를 제공하는 것입니다. 포드 일정을 예약하려면 먼저 부트스트랩 저장소를 프로비저닝할 수 있어야 하기 때문에 이 작업이 필요합니다.

자체 호스팅되는 일반적인 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 차트 - 문제 해결
• Herm 설명서
• Tableau Server 설명서