Dépannage du diagramme de Helm

Diagramme de Helm de Tableau Server - Dépannage

Important : Cette documentation suppose une connaissance de Helm et des diagrammes de Helm. Elle ne cherche pas à fournir d’exemples détaillés et prescriptifs. Elle est destinée aux clients qui maîtrisent à la fois Tableau Server, Helm et les diagrammes de Helm.

Introduction

Cette rubrique vous aide à diagnostiquer et à résoudre les problèmes courants lors du déploiement de Tableau Server sur Kubernetes à l’aide d’un diagramme de Helm. Elle couvre les problèmes d’installation, les problèmes d’exécution et les techniques de débogage.

Étapes de dépannage générales

Lorsque vous rencontrez des problèmes avec Tableau Server dans Kubernetes :

  1. Vérifier l’état et les événements du pod
  2. Examiner les fichiers journaux des conteneurs
  3. Vérifier la disponibilité des ressources
  4. Vérifier les demandes de volume persistant
  5. Vérifier l’état de la version Helm
  6. Examiner la connectivité des services et du réseau

Les pods ne démarrent pas

  1. Vérifiez l’état du pod :

    kubectl get pods -l app.kubernetes.io/instance=tableau-server
    kubectl describe pod <pod-name>
  2. Vérifiez les fichiers journaux :

    kubectl logs <pod-name>
  3. Vérifiez les événements :

    kubectl get events --sort-by='.lastTimestamp'

Problèmes de volume persistant

  1. Vérifiez l’état du PVC :

    kubectl get pvc
    kubectl describe pvc <pvc-name>
  2. Vérifier la classe de stockage :

    kubectl get storageclass

Problèmes liés aux clés produit

  1. Vérifiez que la clé produit est définie :

    kubectl get secret tableau-server-secrets -o 
    jsonpath='{.data.LICENSE_KEY}' | base64 -d
  2. Mettez à jour la clé produit :

    # Edit values.yaml and upgrade
    helm upgrade tableau-server ./helm/tableau-server -f ./helm/tableau-server/values.yaml

Échecs des contrôles d’intégrité

  1. Vérifiez le script de contrôle d’intégrité :

    kubectl exec <pod-name> -- /docker/alive-check
    kubectl exec <pod-name> -- /docker/server-ready-check
  2. Ajustez la durée du contrôle d’intégrité :

    healthChecks:
    liveness:
    initialDelaySeconds: 600 # Increase if server takes longer to start

Problèmes liés au bootstrap multinœuds

  1. Vérifiez le volume de bootstrap :

    kubectl get pvc | grep bootstrap
  2. Vérifiez le fichier de bootstrap :

    kubectl exec <primary-pod> -- ls -la /docker/config/bootstrap
  3. Vérifiez le mode d’accès ReadWriteMany :

    persistence:
    bootstrap:
    accessMode: ReadWriteMany # Required for multi-node

     

  4. Vérifiez la liaison PV/PVC de bootstrap pour la mise en service de l’EFS statique :

    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. En cas d’erreur de montage après la liaison du PVC, vérifiez les erreurs de l’EFS CSI et de l’IAM :

    kubectl describe pod -n default tableau-server-primary-0
    kubectl get events -n default --sort-by='.lastTimestamp'
  6. Erreurs driver name efs.csi.aws.com not found :

    Installez et vérifiez le module complémentaire EKS comme décrit dans Conditions préalables pour Elastic Kubernetes Service (EKS) d’Amazon

  7. Corriger les échecs d’autorisation DescribeMountTargets

    • Méthode préférée :

      aws iam attach-role-policy \
      --role-name <your-node-instance-role> \
      --policy-arn
      arn:aws:iam::aws:policy/AmazonElasticFileSystemClientReadWriteAccess

      Redémarrez ensuite les pods concernés (nœud principal et tous les nœuds worker). Les workers sont sélectionnés par étiquette, ce qui permet de couvrir n’importe quel nombre de répliques.

    • Méthode alternative

      Forcez le montage de l’IP de la cible dans la configuration du PV de bootstrap :

      Définissez persistence.bootstrap.pv.csi.volumeAttributes.mounttargetip (ou PV manuel volumeAttributes.mounttargetip) et réappliquez ou effectuez une mise à niveau.

Ressources supplémentaires