--- schema_version: "1" id: ded10641523305d96532319c847dd49aa1a15537f03dbef85471816c14e5f664 title: Förutsättning för Helm-diagram collection: tableau version: next locale: sv-se portal_url: https://docs.salesforce.com/tableau/next/sv-se/server/server-helm-prerequisites.md canonical_url: https://help.tableau.com/v0.0/server/sv-se/server-helm-prerequisites.htm source_site: help.tableau.com content_type: documentation content_hash: 0003f89a1e7b2bd24216cbfa5189812c47eda9cc5ba01a0a6aa9c2ee22b3183b description: "Viktigt: Den här dokumentationen förutsätter kunskap om Helm och Helm-diagram och tillhandahåller inte detaljerade, normativa exempel" --- [Hoppa till huvudinnehåll](#main-content) # Helm-diagram för Tableau Server – förutsättningar **Viktigt**: Den här dokumentationen förutsätter kunskap om Helm och Helm-diagram och tillhandahåller inte detaljerade, normativa exempel. Den är utformad för kunder som är bekanta med både Tableau Server, Helm och Helm-diagram. I det här avsnittet förklarar vi de förutsättningar som krävs för att använda ett Helm-diagram för att driftsätta Tableau Server. ## Nedladdning och driftsättning av Helm-diagram Helm-diagrammen levereras som en del av Tableau Server i ett konfigurationsverktyg för behållare (`tableau-server-container-setup-tool-.tar.gz`) och kan laddas ner från [nedladdningssidan för Tableau Server](http://tableau.com/sv-se/support/releases/server/latest). Efter extraheringen finns de nödvändiga Helm-diagramfilerna i katalogen `helm/tableau`. ## Verktyg som krävs - `kubectl`\-kommandoradsgränssnitt konfigurerat för att komma åt ditt Kubernetes-kluster - `helm`\-kommandoradsgränssnitt version 3.x eller senare - Åtkomst till ett Kubernetes-kluster (1.19+) ## Klusterkrav - Minst en nod med 16 GB RAM och 4 processorkärnor (8 kärnor rekommenderas). - StorageClass konfigurerad för dynamisk PersistentVolume-provisionering. - Möjlighet att skapa LoadBalancer-tjänster eller Ingress-resurser. ## Information som krävs Kontrollera att du har följande innan du börjar: - Din **licensnyckel för Tableau Server** - **TSM-administratörens `username` och** `**password**` för det första kontot - Tableau Server-**värdnamnet** för åtkomst ## Förutsättningar för Amazon Elastic Kubernetes Service (EKS) ### `efs-bootstrap` StorageClass Som standard skapas inte `efs-bootstrap` i EKS. För startdelning med flera noder skapar du den innan Helm-installationen. För driftsättning med flera noder måste startlagring kunna etableras innan datacenter kan schemaläggas. Om din `efs-bootstrap` StorageClass inte etablerar EFS-volymer dynamiskt måste du antingen: - skapa en statisk start-PV i förväg och binda den till `tableau-server-bootstrap` eller - ange `persistence.bootstrap.createPV: true` och ange `valid persistence.bootstrap.pv.csi.volumeHandle` (verkligt EFS-ID, fs- ...). Om detta inte görs förblir datacentren i ett väntande tillstånd med obundna PVC:er. 1. Kontrollera att EFS CSI-drivrutinen är installerad i klustret. kubectl get csidriver efs.csi.aws.com Ett `CSIDriver`\-objekt kan finnas även när det EKS-hanterade tillägget inte är installerat. Bekräfta tillägget. Om du får ett felmeddelande (inget tillägg) eller om datacenter senare misslyckas med monteringsfel, till exempel `driver name efs.csi.aws.com not found in the list of registered CSI drivers`, installerar du EKS-tillägget och väntar tills statusen `ResourceNotFoundException` är AKTIV och verifierar därefter nodens plugin-datacenter. Detta är nödvändigt eftersom flernodsstart använder en EFS-stödd volym (ReadWriteMany). Utan plugin-programmet för EFS CSI-noder på ytterligare noder kan start-PVC:er binda men monteringar misslyckas och datacenter förblir i tillståndet `Init/Pending`. Om EFS-monteringar misslyckas med: is not authorized to perform: elasticfilesystem:DescribeMountTargets eller Failed to resolve "fs-....efs..amazonaws.com" ska du tillämpa någon av följande åtgärder: - **IAM-korrigering för EKS-nodroll** (rekommenderas): Bevilja EFS- och EC2-läsbehörigheter så att monteringsmålet och AZ-identifieringsarbetet fungerar. Lös nodinstansrollnamnet från nodgruppen: aws eks list-nodegroups --cluster-name aws eks describe-nodegroup \\ \--cluster-name \\ \--nodegroup-name \\ \--query "nodegroup.nodeRole" \\ \--output text - **Använd IAM-\*\*rollnamnet\*\*** (sista segmentet i ARN) i `attach-role-policy`: 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 - Typiska behörigheter: - elasticfilesystem:DescribeMountTargets, elasticfilesystem:DescribeFileSystems - `ec2:DescribeAvailabilityZones` (behövs ofta när `DescribeAvailabilityZones` visas i monteringsfel) - **Montera mål-IP**: Ange `mounttargetip` på CSI-volymattributen för start-PV:n när DNS/identifiering är begränsad i din miljö. - Helm-värden (sökvägen `createPV: true`): persistence: bootstrap: pv: csi: volumeAttributes: mounttargetip: "10.x.x.x" - Manuell PV-sökväg spec: csi: driver: efs.csi.aws.com volumeHandle: fs-xxxxxxxx volumeAttributes: mounttargetip: 10.x.x.x 2. Skapa `efs-bootstrap` StorageClass (exempel): apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: efs-bootstrap provisioner: efs.csi.aws.com reclaimPolicy: Retain volumeBindingMode: Immediate allowVolumeExpansion: true 3. Välj en startsökväg för provisionering (obligatoriskt): - **Dynamisk EFS-provisioneringsväg**: Använd en dynamisk EFS CSI StorageClass som konfigurerats för åtkomstpunkter (till exempel `provisioningMode: efs-ap, fileSystemId` och behörigheter/basePath-parametrar enligt din plattformsstandard). - **Statisk PV-väg**: Skapa `tableau-bootstrap-pv` manuellt med `csi.driver: efs.csi.aws.com` och `csi.volumeHandle: fs-...` Ställ sedan in följande: - `persistence.bootstrap.createPV: false` - `persistence.bootstrap.volumeName: tableau-bootstrap-pv` - **Helm-skapad statisk PV-sökväg**: Ange följande: - `persistence.bootstrap.createPV: true` - `persistence.bootstrap.pv.csi.volumeHandle: fs-...` ## Förutsättning för icke-EKS ### `ReadWriteMany` StorageClass För kluster som inte finns på EKS (eller om de inte använder EFS) är det kritiska kravet för startdelning med flera noder att tillhandahålla en StorageClass som stöder åtkomstläget `ReadWriteMany (RWX)` för startvolymen. Detta krävs eftersom startlagring måste kunna etableras innan datacenter kan schemaläggas. Vanliga lokalt installerade RWX-lagringsservrar för Kubernetes: - NFS (vanligast, lättast att testa) - CephFS - Longhorn (om installerad) - GlusterFS - NetApp/annan företagslagring Du måste se till att motsvarande CSI-drivrutin för den valda servern är installerad. Om du vill konfigurera Tableau Server till att använda din anpassade RWX StorageClass uppdaterar du dina Helm-värden (t.ex. `values-multinode.yaml`) så att de anges till namnet `persistence.bootstrap.storageClass` på din 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 ## Ytterligare resurser - [Helm-diagram för Tableau Server – översikt](https://help.tableau.com/v0.0/server/sv-se/server-in-container_helm-chart.htm) - [Helm-diagram för Tableau Server – driftsättning](https://help.tableau.com/v0.0/server/sv-se/server-helm-deploy.htm) - [Helm-diagram för Tableau Server – felsökning](https://help.tableau.com/v0.0/server/sv-se/server-helm-troubleshooting.htm) - [Helm-dokumentation](https://helm.sh/docs/) - [Tableau Server-dokumentation](https://help.tableau.com/current/server-linux/sv-se/)