K8S Nginx Ingress retourne une erreur de manière aléatoire 502 sur la charge
nous utilisons un NGinx (1.15.8.1) en tant que contrôleur d'entrée sur notre groupe K8S (V.1.17), géré par RANCHER (2.5.7).
Cela a bien fonctionné jusqu'à présent jusqu'à présent, mais nous configurons maintenant une podage d'API personnalisée pouvant être accessible en externe via une entrée.
Maintenant, faire des tests de charge de l'API en effectuant une demande de tir chaque seconde à l'API renvoie au hasard "502 Bad Gateway" toutes les demandes. Cependant pas périodiquement.
<html>
<head><title>502 Bad Gateway</title></head>
<body>
<center><h1>502 Bad Gateway</h1></center>
<hr><center>openresty/1.15.8.1</center>
</body>
</html>
Le journal respectif sur le contrôleur d'entrée:
2021/04/11 11:02:48 [error] 25430#25430: *55805583 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx, server: xxx, request: "POST /api/v1/xxx HTTP/2.0", upstream: "http://xxx/api/v1/xxx", Host: "xxx"
Nous avons exécuté le même conteneur sur un environnement non k8s en tant que conteneur Docker, où nous n'avions jamais connu cette question auparavant, alors au moment où je suppose que cela ne pose pas de problème de la mise en œuvre du conteneur/de l'API.
Mes pensées étaient:
1- La définition de service qui résoudra l'API POD ne peut pas acheminer le trafic vers une pod et répond donc avec un 502
-> J'ai changé l'entrée pour aller directement à la charge de travail pour avoir testé pour comprendre si c'est le problème. Je reçois les mêmes erreurs alors, alors la définition de service semble ne pas être le problème
2- Timeout dans la ressource d'entrée (B/C La post répond avec la latence) pourrait entraîner l'échec du routage
-> Je fixe les délais d'attente pour
nginx.ingress.kubernetes.io/proxy-connect-timeout: 1d
nginx.ingress.kubernetes.io/proxy-read-timeout: 1d
nginx.ingress.kubernetes.io/proxy-send-timeout: 1d
mais courut dans la même erreur à nouveau. donc cela semble ne pas être le problème non plus
3- Erreur lors du conteneur API (très improbable) qui envoie des erreurs de dos
-> Vérification des journaux du conteneur révèle que la demande manquante (qui a renvoyé le 502 ou quelque chose de similaire qui est ensuite évaluée sur le niveau d'entrée comme 502) n'a jamais été reçu par le conteneur API. De plus, cela n'a aucun sens du tout à partir d'une perspective de routage de la circulation.
4- En fin de dernière étape, j'ai échoué dans deux conteneurs et tout fonctionne parfaitement.
Résumé: Avec les résultats ci-dessus, je résumez que la définition de 1-service ne peut pas être le problème (test 1) 2- Les délais d'ingression ne peuvent pas être le problème 3- L'API elle-même ne peut pas être le problème.
Penser à Test 4 Il pointe dans une direction que la disponibilité du conteneur dans les pods pourrait être un problème en termes que l'API dépose des demandes (entraînant une 502) lorsque le conteneur est dans un état spécifique (cela expliquerait pourquoi cela fonctionne avec 2 Les conteneurs à l'échelle) OR Le routage de la circulation est de côté quelque part sur le chemin.
Actuellement, je n'ai aucune autre idée où aller d'ici. Toute allusion est appréciée.
si vous utilisez le proxy inverse inverse Nginx, c'est peut-être la cause. Essayez d'enregistrer configmap pour proxy-next-upstream Paramètres et étendez-le pour gérer le http_502 Cas.
[.____] activez également le retry-non-idempotent Si la demande à 502 est Post, verrouillage, patch, si elle est sûre pour votre application.
Mon devinez: lorsque le backend POD atteint sa limite de charge (ou son recyclage de POD), il "rejette" la nouvelle demande et le proxy inverse Nginx est plus sensible avec ce rejet. Sans Nginx-Ingress, K8S manipulant l'équilibrage de la charge et il peut tout gérer mieux, faire la queue au lieu de rejeter.