--- schema_version: "1" id: 72f2966d8f0276e352c5533232bf47b8d21b5d2b2c9f332f966f21e9a266c0e7 title: Helm 차트 필수 요건 collection: tableau version: current locale: ko-kr portal_url: https://docs.salesforce.com/tableau/current/ko-kr/server-linux/server-helm-prerequisites.md canonical_url: https://help.tableau.com/current/server-linux/ko-kr/server-helm-prerequisites.htm source_site: help.tableau.com content_type: documentation content_hash: 9b739ef81e33bb80608f5f0b9e724f2b01d4816584e41cb0459e1562e1ab766a description: "중요: 이 설명서에서는 Helm 및 Helm 차트에 대한 지식이 있다고 가정하며 상세한 설명적 예를 제공하지 않습니다" --- [주요 콘텐츠로 건너뛰기](#main-content) # Tableau Server Helm 차트 - 필수 요건 **중요**: 이 설명서에서는 Helm 및 Helm 차트에 대한 지식이 있다고 가정하며 상세한 설명적 예를 제공하지 않습니다. 설명서는 Tableau Server와 Helm 및 Helm 차트에 익숙한 고객을 대상으로 작성되었습니다. 이 항목에서는 Helm 차트를 사용하여 Tableau Server 배포하는 데 필요한 필수 요건에 대해 설명합니다. ## Helm 차트 다운로드 및 배포 Helm 차트는 Tableau Server 컨테이너 설정 도구(`tableau-server-container-setup-tool-.tar.gz`)의 일부로 제공되며, [Tableau Server 다운로드](http://tableau.com/ko-kr/support/releases/server/latest) 페이지에서 다운로드할 수 있습니다. 추출 후 필요한 Helm 차트 파일은 `helm/tableau` 디렉터리에 위치합니다. ## 필요한 도구 - `kubectl` Kubernetes 클러스터에 액세스하도록 구성된 CLI - `helm` CLI 버전 3.x 이상 - Kubernetes 클러스터 액세스(1.19 이상) ## 클러스터 요구 사항 - 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..amazonaws.com" 다음 수정 단계 중 하나를 사용하십시오. - **EKS 노드 역할에 대한 IAM 수정**(기본 설정): 마운트 대상 및 AZ 검색이 작동하도록 EFS 및 EC2에 읽기 권한을 부여합니다. 노드 그룹에서 노드 인스턴스 역할 이름을 확인합니다. aws eks list-nodegroups --cluster-name aws eks describe-nodegroup \\ \--cluster-name \\ \--nodegroup-name \\ \--query "nodegroup.nodeRole" \\ \--output text - `attach-role-policy`의 **IAM \*\*역할 이름\*\* 사용**(ARN의 마지막 세그먼트): aws iam attach-role-policy \\ \--role-name \\ \--policy-arn arn:aws:iam::aws:policy/AmazonElasticFileSystemClientReadWriteAccess aws iam attach-role-policy \\ \--role-name \\ \--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 차트 - 개요](https://help.tableau.com/current/server-linux/ko-kr/server-in-container_helm-chart.htm) - [Tableau Server Helm 차트 - 배포](https://help.tableau.com/current/server-linux/ko-kr/server-helm-deploy.htm) - [Tableau Server Helm 차트 - 문제 해결](https://help.tableau.com/current/server-linux/ko-kr/server-helm-troubleshooting.htm) - [Herm 설명서](https://helm.sh/docs/) - [Tableau Server 설명서](https://help.tableau.com/current/server-linux/ko-kr/)