Graphique Helm de Tableau Server - Résolution des problèmes


Important : cette documentation présuppose une connaissance de Helm et des graphiques de Helm et ne prétend pas fournir des exemples détaillés et prescriptifs. Elle s’adresse aux clients qui connaissent à la fois Tableau Server, Helm et les graphiques 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 graphique Helm. Il couvre les problèmes d’installation, les problèmes d’exécution et les techniques de débogage.

Étapes générales de résolution des problèmes

En cas de 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 revendications de volume persistant
  5. Vérifier l’état de la version de Helm
  6. Examiner la connectivité des services et du réseau

Les pods ne démarrent pas

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

    kubectl get pods -l app.kubernetes.io/instance=tableau-server
    kubectl describe pod <pod-name>

  2. Vérifier les fichiers journaux :

    kubectl logs <pod-name>

  3. Vérifier les événements :

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

Problèmes de volume persistant

  1. Vérifier 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. Mettre à 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érifier le script de contrôle d’intégrité :

    kubectl exec <pod-name> -- /docker/alive-check
    kubectl exec <pod-name> -- /docker/server-ready-check

  2. Ajuster la durée du contrôle d’intégrité :

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

Problèmes de bootstrap multi-nœud

  1. Vérifier le volume bootstrap :

    kubectl get pvc | grep bootstrap

  2. Vérifier le fichier bootstrap :

    kubectl exec <primary-pod> -- ls -la /docker/config/bootstrap

  3. Vérifier le mode d’accès ReadWriteMany :

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

     

  4. Vérifier la liaison PV/PVC de bootstrap pour le provisionnement statique EFS :

    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. Si le montage échoue après la liaison du PVC, vérifier les erreurs CSI/IAM EFS :

    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 Amazon Elastic Kubernetes Service (EKS)

  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 afin de couvrir tout nombre de réplicas.

    • Méthode alternative

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

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

Ressources supplémentaires

Retour en haut
Merci de vos commentaires !Avis correctement envoyé. Merci