Dépannage du cluster High Availability

Ce tableau répertorie les symptômes courants du cluster et leurs résolutions.
Symptôme
Résolution
La connectivité SSH échoue entre le poste de travail Windows et un nœud Ubuntu.
Corrigez les informations d’identification SSH ou la configuration réseau afin que le poste de travail puisse atteindre chaque nœud.
L’accès à l’interface utilisateur Web est bloqué, car le cluster et le projet déployé utilisent des ports différents.
Alignez le port MoteurDePrésentationWeb du projet sur le port Web configuré du cluster, 80 par défaut pour HTTP ou 443 pour HTTPS.
La base de données cesse d’accepter les écritures.
Ce problème se produit lorsque deux des trois nœuds présentent une défaillance et que la base de données perd le quorum.
Restaurez au moins un nœud défaillant pour rétablir le quorum et reprendre les écritures.
Les données persistantes sont manquantes après la désinstallation du cluster.
La désinstallation du cluster retire le stockage persistant.
Récupérez les données uniquement à partir d’une sauvegarde créée avant la désinstallation.
Le tableau de bord du cluster affiche un état qui semble obsolète ou inattendu.
Actualisez le tableau de bord.
Si l’état semble toujours erroné, vérifiez Diagnostics et les journaux exportés pour confirmer l’état réel du pod et du nœud.
Le déploiement d’un projet volumineux qui dépasse la limite de mémoire de l’exécution entraîne le signalement d’un déploiement réussi dans Studio, mais l’exécution s’arrête immédiatement avec peu d’informations consignées dans le journal.
  1. Pour sauvegarder les valeurs Helm actuelles et l’historique des révisions, exécutez :
    helm get values ftoptix -n ftoptix > pre-change-values-backup.yaml && helm history ftoptix -n ftoptix
  2. Pour confirmer que la RAM du nœud peut prendre en charge la nouvelle limite de mémoire, exécutez :
    kubectl describe node <node-name> | grep -A2 "Capacity:"
  3. Pour appliquer le remplacement, exécutez :
    helm upgrade ftoptix <chart-path> -n ftoptix --reuse-values --set resources.runtime.requests.memory=<value> --set resources.runtime.limits.memory=<value>
  4. Pour vérifier que les pods ont bien pris en compte la nouvelle limite et qu’ils fonctionnent correctement, exécutez :
    kubectl rollout status statefulset/ftoptix-core-ha-runtime -n ftoptix
                      kubectl get pods -n ftoptix
                      kubectl describe pod ftoptix-core-ha-runtime-0 -n ftoptix | grep -A2 "Limits:"
  5. Pour confirmer la modification, déployez à nouveau le projet, vérifiez que l’exécution atteint l’état En cours d’exécution ou Actif et que l’interface utilisateur Web est accessible.
Kubernetes renvoie 401 Unauthorized, la récupération de l’identité d’exécution échoue, l’environnement d’exécution passe en mode démo, l’autorisation d’Update Server échoue par intermittence, ou les pods d’exécution ne sont pas restaurés comme prévu.
Ces symptômes résultent généralement d’un décalage d’horloge entre les nœuds du cluster.
Configurez tous les nœuds pour qu’ils utilisent les mêmes sources NTP approuvées, restaurez la synchronisation temporelle, confirmez que les horloges ne diffèrent pas de plus de 1 seconde et relancez l’opération ayant échoué.
Ne poursuivez pas le provisionnement si l’horloge d’un nœud n’est pas synchronisée ou présente un écart d’au moins 5 secondes.
Fournir une réponse
Vous avez des questions ou des commentaires sur cette documentation ? Veuillez envoyer vos commentaires ici.
Normal