J'essaie de diagnostiquer ce problème depuis plusieurs jours et j'ai une idée assez précise de ce qui se passe, mais je ne sais toujours pas pourquoi.
Le symptôme est que les demandes adressées à différents services sont accompagnées d'une connexion réseau TCP défaillante ( EHOSTUNREACH , ECONNREFUSED , Connection reset by peer , No route to host , Connection refused , Connection timed out etc.) d'autres pods. J'ai parcouru les journaux en détail à propos d'un incident et, pour une raison quelconque, aucune demande n'a été envoyée en aval à l'un des pods du ReplicaSet qui soutient le service pendant 9 secondes.
Je n'ai pas trouvé de signes évidents expliquant l'arrêt ou la reprise du trafic vers Pods. J'aurais besoin d'aide pour cela, je ne sais pas vraiment où chercher ni quoi essayer.
Il y a quelques autres éléments qui pourraient être pertinents :
- Les demandes de sondes d'état de préparation ont été traitées avec succès toutes les secondes - ce sont les seules demandes qui ont atteint les pods.
- La résolution DNS semble fonctionner car certains Pods se sont connectés sans pouvoir se connecter à l'IP résolue du service.
- Les journaux des clusters montrent
io.k8s.core.v1.endpoints.updateLes appels d'API autour de la panne, mais les IP de nœuds étaient enaddresses(pasnotReadyAddresses) liste - Le problème semble se produire plus souvent lorsque des pods sont détruits (ou créés) lors d'un déploiement, d'une mise à l'échelle automatique ou d'une préemption du nœud, mais il s'est également produit avec un nombre stable de répliques.
- Nous exécutons Kubernetes 1.15 et 1.16 sur GKE, malheureusement pas en mode VPC (alias IP) car les clusters ont été créés il y a quelques années.
- Nous n'avons pas Istio ni aucun autre maillage de services en cours d'exécution, mais je suis très tenté maintenant.
Merci d'avance pour toute suggestion !
0 votes
Est-il possible de fournir une description détaillée de votre configuration afin que le problème puisse être reproduit sur un autre cluster GKE de test ? Est-ce que cela se produit à la fois sur les clusters GKE 1.15 et 1.16 ?
0 votes
@mario Je ne suis pas sûr qu'il soit possible de partager une reproduction simple car il est difficile de reproduire de manière fiable même avec les clusters et les services actuels. Cela se produit sur les deux versions. A ce stade, je cherchais juste des causes possibles à explorer, c'est-à-dire pourquoi un service n'enverrait pas de trafic à des pods sains et comment le diagnostiquer.
1 votes
Bonjour @dain, je pense que dans une telle situation, il est judicieux de contacter Support GCP . S'il s'agit d'un problème difficile, voire impossible, à reproduire sur un autre groupe de test GKE, il sera difficile de trouver une aide appropriée ici.
0 votes
Merci @mario, j'essaie maintenant de passer à de nouveaux clusters natifs de VPC pour voir si cela résout le problème. Même si ce n'est pas le cas, je peux au moins commencer à échantillonner le trafic réseau avec des journaux de flux et j'espère comprendre le problème.
0 votes
@dain Avez-vous résolu ce problème ? Est-ce que le cluster VPC-native aide ? Rencontrez-vous toujours ce problème ? Quelles sont les étapes à suivre pour le reproduire ?
0 votes
@PjoterS n'a pas encore réussi à résoudre complètement le problème. Je ne pense pas que VPC-native ait fait une grande différence, mais augmenter les temps et les essais sur les sondes a beaucoup aidé. Je pense que Kubernetes, pour une raison quelconque, pense que tous les pods d'un service sont incapables de servir une requête et bloque simplement la connexion. Je ne sais pas comment répliquer, cela se produit trop rarement pour en établir la cause. Nous allons bientôt ajouter quelques instruments supplémentaires, et nous ferons un rapport si nous avons de nouvelles découvertes.