Résoudre les problèmes multiclusters

{version_1.0.1 d

Cette section décrit les problèmes courants liés à Cloud Service Mesh et explique comment les résoudre. Si vous avez besoin d'une aide supplémentaire, consultez la page Obtenir de l'aide.

Secrets manquants

Cette section ne s'applique qu'au plan de contrôle interne au cluster et au plan de contrôle géré avec la mise en œuvre Istiod.

Cloud Service Mesh s'appuie sur un fichier kubeconfig intégré au secret Kubernetes pour une détection appropriée des points de terminaison distants. Sans les secrets, les utilisateurs verront toujours les requêtes d'appel des pods dans le cluster local lors de l'équilibrage de charge intercluster.

Vérifiez que le secret a été créé en exécutant la commande suivante dans chaque cluster :

kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system

Vérifiez le résultat attendu :

NAME                                   TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s

Pour résoudre ce problème, supprimez tous les secrets distants et exécutez à nouveau la commande create-mesh.

Serveur d'API inaccessible

Cette section ne s'applique qu'au plan de contrôle et aux ressources gérées dans le cluster (implémentation Istiod).

Le plan de contrôle de Cloud Service Mesh doit atteindre le serveur d'API du cluster distant. Les situations suivantes peuvent rendre le cluster distant inaccessible :

  • Le cluster distant est supprimé.
  • Le cluster distant est un cluster privé pour lequel l'accès mondial n'est pas activé.
  • Le cluster distant est un cluster privé pour lequel le réseau autorisé maître est activé, mais l'adresse IP du plan de contrôle de Cloud Service Mesh n'a pas été correctement autorisée à l'aide de la liste d'autorisation.

Étant donné qu'un serveur d'API est inaccessible, Istiod affiche des messages d'erreur dans le journal. Les utilisateurs verront toujours les requêtes appeler le pod local lors de l'équilibrage de charge interclusters.

Dans l'interface de l'explorateur de journaux, définissez la requête resource.type sur istio_control_plane.

Vérifiez s'il existe des erreurs de secret non valide.

Pour résoudre ce problème, corrigez le problème de joignabilité du serveur d'API sous-jacent. Ensuite, supprimez tous les secrets distants de chaque cluster, puis réexécutez la commande create-mesh.

Règle de pare-feu manquante

Sans la règle de pare-feu appropriée, les utilisateurs rencontreront un délai de 10 secondes suivi d'un délai avant expiration lors de l'équilibrage de charge interclusters.

Pour résoudre ce problème, suivez la procédure décrite dans la section Créer une règle de pare-feu.