Kubernetes Ingress (GCE) gibt 502 Fehler zurück

Ihr Backend k8s-be-32396--5fc40252fadea594 wird als "UNHEALTHY" angezeigt.

Ingress wird Traffic nicht weiterleiten, wenn das Backend UNHEALTHY ist, dies führt zum 502 Fehler, den Sie sehen.

Es wird als UNGESUNDIG markiert, da es die Integritätsprüfung nicht besteht. Sie können die Einstellung für die Integritätsprüfung für k8s-be-32396--5fc40252fadea594 überprüfen, um zu sehen, ob sie für Ihren Pod geeignet sind URI oder Port, der keine 200-Antwort zurückgibt. Sie finden diese Einstellung unter Compute Engine & gt; Gesundheitschecks.

Wenn sie korrekt sind, dann gibt es viele Schritte zwischen Ihrem Browser und dem Container, die den Datenverkehr möglicherweise falsch übergeben. Sie könnten kubectl exec -it PODID -- bash (oder asche, wenn Sie Alpine verwenden) versuchen und dann versuchen, localhost zu curlen, um zu sehen, ob Der Container antwortet wie erwartet, wenn dies der Fall ist und die Integritätsprüfungen ebenfalls korrekt konfiguriert sind, würde dies das Problem wahrscheinlich auf Ihren Dienst eingrenzen. Sie könnten dann versuchen, den Dienst von einem NodePort-Typ in einen LoadBalancer zu ändern Die Service-IP direkt von Ihrem Browser funktioniert.

Das Problem ist in der Tat ein Gesundheitscheck und schien "zufällig" für meine Apps zu sein, wo ich namensbasierte virtuelle Hosts verwendete, um Proxy-Anfragen von Ingress über Domains auf zwei separate Backend-Dienste umzukehren. Beide wurden mit Lets Encrypt und kube-lego gesichert. Meine Lösung bestand darin, den Pfad für Health-Checks für alle Dienste, die einen Ingress teilen, zu standardisieren und die Konfigurationen readinessProbe und livenessProbe in meiner deployment.yml -Datei zu deklarieren.

Ich habe dieses Problem mit der Google Cloud-Cluster-Knoten-Version 1.7.8 konfrontiert und festgestellt, dass dieses Problem sehr ähnlich zu dem ist, was ich erlebt habe:  * Ссылка

Ich verwende gce und kube-lego , und meine Backend-Service-Statusprüfungen waren auf / und kube-lego auf /healthz . Es scheint, dass unterschiedliche Pfade für Systemdiagnosen mit gce ingress die Ursache sind. Daher ist es möglicherweise sinnvoll, die Backendservices so anzupassen, dass sie dem /healthz -Muster entsprechen, so dass alle dasselbe verwenden (oder ein Kommentator in Github gibt an, dass kube-lego aktualisiert wurde) auf / ).

Ich hatte das gleiche Problem und es blieb bestehen, nachdem ich livenessProbe sowie readinessPorbe aktiviert hatte. Es drehte sich um dies war mit Grundauthentifizierung zu tun. Ich habe grundlegende Berechtigungen zu livenessProbe und readinessPorbe hinzugefügt, aber es stellt sich heraus, dass der GCE HTTP (S) Load Balancer keine Konfigurationsoption dafür hat.

Es scheint ein paar andere Probleme zu geben, z.B. Container-Port auf 8080 und Service-Port auf 80 zu setzen funktionierte nicht mit GKE Ingress Controller (aber ich würde nicht klar angeben, was das Problem war). Und im Großen und Ganzen sieht es für mich so aus, als ob es sehr wenig Sichtbarkeit gäbe und das Ausführen eines eigenen Ingress-Containers ist eine bessere Option in Bezug auf Sichtbarkeit.

Ich wählte Traefik für mein Projekt aus, es funktionierte aus der Box und ich würde es gerne tun Aktivieren Sie Let's Encrypt Integration. Die einzige Änderung, die ich an den Traefik-Manifesten vornehmen musste, bestand darin, das Serviceobjekt so zu optimieren, dass der Zugriff auf die Benutzeroberfläche von außerhalb des Clusters deaktiviert und meine App durch einen externen Lastenausgleich (GCE TCP LB) verfügbar gemacht wurde. Außerdem ist Traefik mehr in Kubernetes heimisch. Ich habe versucht, Heptio Contour, aber etwas funktionierte nicht aus der Box (wird es das nächste Mal geben, wenn die neue Version herauskommt).

Ich hatte das gleiche Problem. Es stellte sich heraus, dass ich einige Minuten warten musste, bevor ich einstieg. Wenn jemand das gleiche tut und alle Schritte wie readinessProbe und linvenessProbe ausführt, dann stelle sicher, dass dein Ingress auf einen Dienst verweist, der entweder NodePort ist, und warte einige Minuten, bis das gelbe Warnsymbol aktiviert wird ein grüner. Überprüfen Sie außerdem den StackDriver, um eine bessere Vorstellung von dem zu bekommen, was vor sich geht. Meine readinessProbe und livenessProbe sind auf /login für die Klasse gce . Also ich denke nicht, dass es auf /healthz sein muss.